# Patterns

**Status:** Draft
**Version:** 0.2.0-draft
**Phase:** The Bedrock Phase

## Overview

This document catalogs structural and conceptual patterns that the standard has identified as recurring across engineering disciplines.

---

## 1. Structure Carries Meaning

**Pattern:** The arrangement and relationship between components conveys information that the individual components do not.

**Engineering Manifestations:**
- Engineering drawings (arrangement of lines encodes spatial relationships)
- Specifications (ordering and interconnection of requirements)
- Network topology (node relationships define system behavior)
- Source code (function ordering and module structure convey design intent)

**Standard Implication:** The dependency tree is itself an act of communication. The ordering of OE-0000 through OE-0011 carries meaning about conceptual priority.

---

## 2. Examples Are Bridges

**Pattern:** Examples serve as structural transportation from unfamiliar concepts to familiar understanding.

**Standard Implication:** Every example in the standard must serve a specific bridging function. Examples are load-bearing, not decorative. For the editorial treatment of examples, see `reference/editorial-principles.md` (Self-Fading Example).

---

## 3. The Pre-Discipline Principle

**Pattern:** Before engineering disciplines specialized, shared principles existed that apply universally across all modern disciplines.

**Evidence:** Observation, measurement, constraint-based decision-making, and knowledge transmission exist in every engineering discipline. These principles predate formal discipline boundaries.

**Standard Implication:** Open Engineer seeks principles that apply across discipline boundaries. Discipline-specific content belongs in implementations, not in the core standard.