second draft of openengineer spec

CHARTER.md

@@ -0,0 +1,23 @@
+# Open Engineer Charter
+
+**The authoritative charter is `spec/oe-0000-charter.md`.**
+
+This file provides a brief summary for repository navigation.
+
+## Purpose
+
+Open Engineer is an open standard for preserving engineering context.
+
+## Quick Navigation
+
+| Resource | Location | Purpose |
+|---|---|---|
+| Charter | `spec/oe-0000-charter.md` | Purpose, scope, governance, status lifecycle, versioning |
+| Specification | `spec/` | OE-0000 through OE-0011 |
+| Editorial Rules | `reference/editorial-principles.md` | **Sole authoritative source** for all editorial principles |
+| Engineering Laws | `laws/engineering-laws.md` | Binding constraints on all content |
+| Communication Principles | `laws/communication-principles.md` | Communication style (subordinate to editorial principles and laws) |
+| Vocabulary Index | `reference/vocabulary.md` | Quick-access term index |
+| Patterns | `reference/patterns.md` | Structural and conceptual patterns |
+| Roadmap | `ROADMAP.md` | Current phase and planned work |
+| Contributing | `CONTRIBUTING.md` | How to contribute |

CONTRIBUTING.md

@@ -0,0 +1,35 @@
+# Contributing to Open Engineer
+
+## Current Phase: The Bedrock Phase
+
+Contributions follow a strict workflow. All editorial rules are defined in `reference/editorial-principles.md`. This document does not duplicate them.
+
+## How to Contribute
+
+### 1. Read the Dependency Tree
+
+The specification is linear (OE-0000 through OE-0011). Do not skip ahead. Do not jump between documents without understanding the dependency chain. See `ROADMAP.md` for the full tree.
+
+### 2. Follow the Editorial Gate
+
+All proposed additions must pass the four-question framework and, for refinements, the five-question RC2 gate. See `reference/editorial-principles.md` for the complete rules.
+
+### 3. Apply the Enduring Concept Test
+
+Every new term must pass the test defined in `reference/editorial-principles.md` (Section 5) and Law 5 (`laws/engineering-laws.md`).
+
+### 4. Check for Duplication
+
+Before proposing anything, verify it does not already exist under a different name in OE-0002 (Core Vocabulary) or elsewhere in the specification.
+
+## Workflow
+
+Observe -> Draft -> Review -> Accept -> Freeze (RC) -> Reference
+
+See OE-0000 for the document status lifecycle and OE-0011 for the full change workflow.
+
+## Key Constraints
+
+- Do not redefine earlier layers in the dependency tree — only extend them.
+- Do not duplicate editorial rules — reference `reference/editorial-principles.md`.
+- Do not introduce technology-anchored terms — use enduring concepts (Law 5).

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) Open Engineer Project
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -0,0 +1,31 @@
+# Open Engineer
+
+**An open standard for preserving engineering context.**
+
+Open Engineer does not seek to tell engineers what to think. It seeks to preserve how engineers arrive at understanding.
+
+## What Is Open Engineer?
+
+An open standard that applies to any discipline in which practitioners make decisions under constraints, observe outcomes, and transmit results to subsequent practitioners.
+
+## Repository Structure
+
+| Directory | Responsibility |
+|---|---|
+| `spec/` | Defines the standard (OE-0000 through OE-0011) |
+| `reference/` | Explains and indexes (vocabulary, patterns, editorial principles) |
+| `examples/` | Illustrates core concepts through worked examples |
+| `laws/` | Binding constraints on all content |
+| `rfc/` | Proposals for changes to the standard |
+
+The spec defines. The reference explains. The examples illustrate. The laws constrain. No overlap.
+
+## Entry Points
+
+- **New to the project?** Start with `spec/oe-0000-charter.md`
+- **Contributing?** Read `CONTRIBUTING.md`, then `reference/editorial-principles.md`
+- **Looking up a term?** Check `reference/vocabulary.md`
+
+## License
+
+See `LICENSE`.

ROADMAP.md

@@ -0,0 +1,69 @@
+# Roadmap
+
+## Current Phase: The Bedrock Phase
+
+Every sentence accepted during this phase is intended to support everything built above it. The specification leads. Everything else follows.
+
+---
+
+## RC2 Objective
+
+Reduce ambiguity without reducing meaning.
+
+RC2 is compression, not expansion. Every refinement should either eliminate ambiguity or strengthen traceability.
+
+---
+
+## RC2 Exit Criteria
+
+RC2 is complete when:
+
+1. Every top-level directory has exactly one responsibility.
+2. Every canonical term has one definition (in OE-0002).
+3. Every definition survives the Enduring Concept test (Law 5).
+4. Every example passes the Self-Fading Example principle.
+5. Every implementation derives from a specification rather than inventing one.
+6. An independent reviewer can reconstruct the architecture without speaking to the project authors.
+
+---
+
+## Specification Dependency Tree
+
+```
+Charter (OE-0000)
+  -> Foundation (OE-0001)
+    -> Core Vocabulary (OE-0002)
+      -> Engineering Context (OE-0003)
+        -> Observation (OE-0004)
+          -> Survey (OE-0005)
+            -> Understanding (OE-0006)
+              -> Verification (OE-0007)
+                -> Decisions (OE-0008)
+                  -> Stewardship (OE-0009)
+                    -> Inheritance (OE-0010)
+                      -> Evolution (OE-0011)
+```
+
+Nothing later may redefine an earlier layer. Only extend it.
+
+## Change Workflow
+
+```
+Observe -> Draft -> Review -> Accept -> Freeze (RC) -> Reference
+```
+
+Document status lifecycle: Draft -> Proposed -> RC -> Accepted -> Deprecated (defined in OE-0000).
+
+---
+
+## Future Phases
+
+- **Implementation Phase** — Interchange formats, context record tooling, presentation layers
+- **Integration Phase** — Context record systems for specific engineering domains
+- **Community Phase** — Open contributions, discipline-specific extensions
+
+---
+
+## Constitutional Gap
+
+OE-0011 acknowledges a gap: the standard defines the change workflow for technical content but not for its own governance (laws, editorial principles, status criteria). This will be addressed in a future amendment.

examples/antikythera.md

@@ -0,0 +1,24 @@
+# Example: Antikythera Mechanism
+
+**Status:** Draft
+**Phase:** The Bedrock Phase
+
+## What This Example Demonstrates
+
+Thread integrity failure (OE-0001). The cost of lost context (OE-0003).
+
+## The Observation
+
+The Antikythera mechanism, built circa 100-200 BCE, contained over 30 gears and could predict astronomical positions and eclipses. The engineering knowledge required to design and build it was lost. Comparable complexity in geared mechanisms did not reappear for over a millennium.
+
+## Engineering Translation
+
+When the thread breaks — when the reasoning, constraints, and verification behind an engineering artifact are no longer accessible — the accumulated understanding is lost. Recovery requires re-derivation from first principles, which is costly, slow, and may produce different (not necessarily better) results.
+
+## Context Record Gap
+
+The Antikythera mechanism is a case where no context record was preserved (or none has survived). What remains is the artifact itself, not the reasoning that produced it. Modern analysis can reverse-engineer function, but the engineering context — why these specific gear ratios, why this arrangement, what alternatives were considered — is largely irrecoverable.
+
+## Self-Fading Assessment
+
+This example transports the reader from the abstract concept of "thread integrity" to a concrete historical case where thread failure had measurable consequences. Once the reader understands that lost context equals lost engineering time, the example has served its purpose.

examples/bridge-survey.md

@@ -0,0 +1,31 @@
+# Example: Bridge Engineering
+
+**Status:** Draft
+**Phase:** The Bedrock Phase
+
+## What This Example Demonstrates
+
+Engineering context preservation (OE-0003), the context record structure, and verification.
+
+## The Observation
+
+A bridge designed without a preserved context record — one that records only the final design but not the reasoning, alternatives, constraints, and verification — creates risk for future engineers who must maintain, modify, or load-rate the bridge.
+
+## Context Record Applied
+
+A well-preserved bridge engineering context record would contain:
+
+| Field | Example Content |
+|---|---|
+| **Decision** | Use a truss design with a 40m span |
+| **Observation** | Site survey showed 40m crossing required; bedrock at 12m depth |
+| **Alternatives** | Cable-stayed (rejected: higher maintenance cost), arch (rejected: insufficient abutment capacity) |
+| **Constraints** | Maximum load 40 tonnes; environmental: tidal zone; economic: prefabrication required |
+| **Reasoning** | Truss allows prefabrication, meets load requirements, and can be erected in tidal window |
+| **Verification** | Load testing to 1.5x design load; finite element analysis corroborated by physical test |
+| **Lineage** | Builds on standard truss design from [prior project reference] |
+| **Assumptions** | Steel grade S355 available; corrosion protection maintains for 50-year design life |
+
+## Self-Fading Assessment
+
+This example transports the reader from the abstract context record structure (OE-0003) to a concrete instance. Once the reader understands how each field maps to a real engineering decision, the example has served its purpose.

examples/clockwork.md

@@ -0,0 +1,24 @@
+# Example: Clockwork
+
+**Status:** Draft
+**Phase:** The Bedrock Phase
+
+## What This Example Demonstrates
+
+Structure carries meaning (OE-0001). Observation-verification loop (OE-0007).
+
+## The Observation
+
+A clock is not a collection of gears. It is a specific arrangement of gears that produces the measurement of time. Each component has no inherent relationship to time — the relationship emerges only through precise arrangement.
+
+## Engineering Translation
+
+System behavior is a property of arrangement, not of components. This principle is observable across engineering: the same transistors can produce a amplifier or a logic gate depending on arrangement; the same structural members can produce a frame or a truss depending on connection patterns.
+
+## The Verification Loop
+
+Clockwork also demonstrates the verification loop: a clock's design is a model (understanding). The test is whether it keeps accurate time (verification against reality). If it does not, the engineer returns to observation (where is the error?) and refines the model (spiral re-evaluation).
+
+## Self-Fading Assessment
+
+This example transports the reader from the abstract principle of emergent behavior to a concrete, familiar mechanism. Once the reader grasps that arrangement creates function, the example has served its purpose.

examples/weaving.md

@@ -0,0 +1,26 @@
+# Example: Weaving
+
+**Status:** Draft
+**Phase:** The Bedrock Phase
+
+## What This Example Demonstrates
+
+Structure carries meaning (OE-0001). The thread as a model of continuity (OE-0001).
+
+## The Observation
+
+A woven fabric's properties — strength, flexibility, pattern — emerge not from individual threads but from their specific arrangement. Remove one thread or alter one relationship, and the fabric's properties change.
+
+## Engineering Translation
+
+System properties emerge from component relationships. This is not unique to weaving — it is observable in bridge trusses, circuit boards, network topology, and source code. The pattern is universal: arrangement conveys information that the components alone do not.
+
+## Thread Continuity
+
+Weaving also demonstrates a concrete property of the thread model: continuity. Each thread in a woven fabric is continuous. If a thread breaks, the fabric weakens. If many threads break, the fabric fails. Thread continuity is necessary for structural integrity.
+
+This maps to engineering knowledge: continuity of understanding is necessary for the integrity of accumulated engineering knowledge. When the continuity breaks — when context is lost between generations — the fabric of engineering understanding degrades.
+
+## Self-Fading Assessment
+
+This example transports the reader from the unfamiliar (why does arrangement matter?) to the familiar (a woven fabric's strength depends on how threads are arranged, not on the threads alone). Once that understanding is reached, the example has served its purpose.

laws/communication-principles.md

@@ -0,0 +1,27 @@
+# Communication Principles
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Phase:** The Bedrock Phase
+
+## Overview
+
+These principles govern how Open Engineer communicates. They are subordinate to the Engineering Laws (`laws/engineering-laws.md`) and the Editorial Principles (`reference/editorial-principles.md`). Where this document conflicts with either, those documents take precedence.
+
+---
+
+## 1. Structure Is Content
+
+The arrangement of information conveys meaning. A well-structured document communicates through its architecture — the ordering of sections, the nesting of concepts, the dependency relationships — not only through its text. The dependency tree itself is an act of communication.
+
+---
+
+## 2. Universality of Language
+
+Open Engineer communicates in engineering language. When it draws from a domain outside engineering, it translates the observation into engineering terms (see `reference/editorial-principles.md`, Translation). The standard must be accessible to any engineer regardless of their cultural or philosophical background.
+
+---
+
+## 3. Precision Over Rhetoric
+
+Specification documents use declarative, testable statements. Rhetorical techniques — negation lists, emphatic repetition, appeals to intuition — are not prohibited in examples or presentation layers, but they have no place in specification definitions. A definition must be testable, not evocative.

laws/engineering-laws.md

@@ -0,0 +1,72 @@
+# Engineering Laws
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Phase:** The Bedrock Phase
+
+## Overview
+
+These are the laws of the Open Engineer standard — binding constraints on all content, structure, and process. All specification documents, RFCs, reference materials, and implementations must comply with these laws.
+
+---
+
+## Law 1: Universal Observation
+
+Open Engineer recognizes observations wherever they arise. It translates enduring observations into engineering principles without adopting the surrounding ideology.
+
+No tradition is diminished. No tradition is elevated above another. Multiple traditions are acknowledged as independent observers of reality.
+
+For the editorial implementation of this law, see `reference/editorial-principles.md` (Translation).
+
+---
+
+## Law 2: Bedrock Immutability
+
+Reality does not change because an engineer's model of it changes. The standard must always distinguish between reality and the current understanding of reality. Understanding is provisional and evolves; the bedrock it rests on does not.
+
+---
+
+## Law 3: Dependency Integrity
+
+Nothing later in the specification may redefine an earlier layer. Only extend it.
+
+A document may build on a lower-level document, but it may not alter the lower-level document's definitions or principles. This preserves the integrity of the dependency tree.
+
+---
+
+## Law 4: Thread Integrity
+
+Knowledge continuity is maintained by deliberate action, not by default. The standard's primary structural obligation is to preserve the conditions under which the thread remains intact — meaning that a subsequent practitioner can reconstruct the reasoning behind a prior decision without direct access to the original decision-maker.
+
+---
+
+## Law 5: Enduring Concepts
+
+When defining a standard, name the enduring concept rather than the technology that currently expresses it.
+
+Technologies are temporary expressions. Concepts endure. A standard anchored to technologies ages as those technologies age. A standard anchored to concepts remains stable as technologies change.
+
+### The Enduring Concept Test
+
+When introducing a term into the standard, apply this test:
+
+If the technology currently used to express this concept disappeared tomorrow, would this definition still be correct?
+
+If the answer is no, the definition names the technology, not the concept. Redefine it.
+
+### Example
+
+| Technology-Anchored | Enduring Concept |
+|---|---|
+| Git repository | Version-controlled collection |
+| Markdown document | Human-readable specification |
+| HTML page | Presentation layer |
+| AI system | Reasoning system |
+
+---
+
+## Law 6: Compression Over Expansion
+
+Every refinement should reduce the number of concepts required to explain the system.
+
+If a revision requires more concepts to explain the same territory, it is expansion, not refinement. The standard's concepts should become fewer and more precise over time, not more numerous.

reference/editorial-principles.md

@@ -0,0 +1,97 @@
+# Editorial Principles
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Phase:** The Bedrock Phase
+
+## Overview
+
+This is the **sole authoritative source** for editorial rules governing all content in the Open Engineer standard. Specification documents, RFCs, reference materials, and root documents must follow these principles. They must not duplicate them.
+
+All editorial rules are subject to the Engineering Laws defined in `laws/engineering-laws.md`.
+
+---
+
+## 1. Translation
+
+Open Engineer extracts observations from any domain and converts them into precise engineering language. It does not import the surrounding ideology, framework, or tradition.
+
+### What This Means
+
+Identify the specific observation that has engineering value. Translate that observation into engineering language. Discard the surrounding ideology.
+
+### Why This Matters
+
+This keeps Open Engineer universal. No tradition is diminished. No tradition is elevated. Multiple traditions are acknowledged as independent observers of reality. (See Law 1: Universal Observation.)
+
+### Examples
+
+| Source Domain | Observation | Engineering Translation |
+|---|---|---|
+| Multiple traditions | Attachment to preferred solutions distorts judgment | Commit to evidence over attachment to prior conclusions |
+| Multiple traditions | Distinguish controllable from uncontrollable factors | Separate controllable design variables from environmental constraints |
+| Multiple traditions | Inheriting an artifact means inheriting obligations | Engineering artifacts carry maintenance and extension responsibilities |
+| Multiple traditions | Claims must survive testing | Understanding is provisional until verified against reality |
+
+---
+
+## 2. Single Responsibility
+
+Every document must have exactly one primary responsibility.
+
+A document that defines observation does not define verification. It references verification. A document that defines stewardship does not define inheritance. It references inheritance.
+
+This is how the standard remains readable and avoids the duplication that leads to divergence.
+
+---
+
+## 3. The Four-Question Framework
+
+Every proposed addition to the standard must answer four questions:
+
+1. **Observation?** — What was observed that prompted this?
+2. **Engineering Principle?** — What engineering principle does this express?
+3. **Reasoning?** — What connects the observation to the principle?
+4. **Relationship to Existing Concepts?** — How does this relate to what already exists?
+
+Nothing enters the standard without surviving these four layers.
+
+---
+
+## 4. The Five-Question RC2 Refinement Gate
+
+Every proposed refinement to existing content must additionally answer:
+
+5. **Is it an enduring concept?** — Would this hold if current technologies disappeared?
+6. **Does it already exist elsewhere?** — Does another document or term already cover this?
+7. **Does it reduce ambiguity?** — Does this revision make something more precise?
+8. **Can it survive technology change?** — Is it anchored to a concept or a technology?
+9. **Does it strengthen rather than expand?** — Does this reduce the number of concepts required, or add one?
+
+If any answer is "no," the refinement is not ready. It may be a valid idea, but it is not yet bedrock.
+
+---
+
+## 5. Enduring Concept Test
+
+When introducing a new term or revising an existing definition, apply this test (see Law 5):
+
+**If the technology currently used to express this concept disappeared tomorrow, would this definition still be correct?**
+
+If no: the definition names the technology, not the concept. Redefine it.
+
+This test applies to all documents, including this one.
+
+---
+
+## 6. Self-Fading Example
+
+Examples serve as structural transportation — they carry the reader from the unfamiliar to the familiar (see OE-0001, Examples Are Bridges). An effective example becomes unnecessary once the reader has crossed that bridge. The example should fade from the reader's consciousness, leaving only the understanding it transported.
+
+An example that draws more attention to itself than to the concept it illustrates has failed.
+
+---
+
+## 7. No Duplication
+
+No editorial rule, principle, or framework exists in more than one authoritative location. If a concept is defined in one document, all other documents reference it. This prevents silent divergence when one copy is updated and others are not.

reference/patterns.md

@@ -0,0 +1,41 @@
+# 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.

reference/vocabulary.md

@@ -0,0 +1,28 @@
+# Vocabulary Reference
+
+**Version:** 0.2.0-draft
+**Source:** OE-0002 (Core Vocabulary)
+**Authoritative source for all terms:** OE-0002
+
+This document provides a quick-access index. For full definitions, consult OE-0002 and the source specification documents.
+
+## Core Terms
+
+| Term | Short Definition | Source |
+|---|---|---|
+| Bedrock | Reality, which does not change regardless of an engineer's model of it | OE-0001 |
+| The Thread | The model of knowledge continuity; has defined, testable properties | OE-0001 |
+| Engineering Context | The structured record of reasoning behind an engineering decision | OE-0003 |
+| Observation | A verifiable encounter with reality (direct or corroborated) | OE-0004 |
+| Direct Observation | Measurement or experiment conducted by the practitioner or team | OE-0004 |
+| Corroborated Observation | An outside observation independently confirmed by engineering evidence | OE-0004 |
+| Survey | Structured assessment of the current state of understanding on a topic | OE-0005 |
+| Understanding | A contextualized model of reality derived from observation and survey | OE-0006 |
+| Verification | The process of testing understanding against reality | OE-0007 |
+| Decision | A choice preserved as a structured context record | OE-0008 |
+| Stewardship | The obligation to maintain and improve knowledge for future practitioners (transmit discipline) | OE-0009 |
+| Inheritance | The act of receiving and engaging with inherited knowledge (receive discipline) | OE-0010 |
+| Spiral Re-evaluation | Returning to previously examined questions with deeper understanding | OE-0001 |
+| Translation | Converting observations into engineering language without importing ideology | OE-0001, editorial-principles.md |
+| Evolution | Disciplined, verified extension of the standard's body of knowledge | OE-0011 |
+| Enduring Concept | A concept named by its function, not by current technology | engineering-laws.md |

rfc/rfc-0000.md

@@ -0,0 +1,20 @@
+# RFC-0000: Purpose
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC establishes the purpose of the RFC process within Open Engineer and the framework by which all subsequent RFCs are evaluated.
+
+## Motivation
+
+Before any individual RFC is accepted, the project must agree on what an RFC is for and what it must accomplish.
+
+## Proposal
+
+The purpose of an RFC is to propose, justify, and specify a change to the standard. Every RFC must pass the editorial gate defined in `reference/editorial-principles.md`, which includes the four-question framework (Section 3).
+
+## Scope
+
+This RFC defines the meta-framework for all subsequent RFCs. It is the root of the RFC tree.

rfc/rfc-0001.md

@@ -0,0 +1,28 @@
+# RFC-0001: Observation First
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC formalizes the principle that observation must precede all other engineering activity within the standard.
+
+## Motivation
+
+Without a formal commitment to observation-first methodology, the standard risks accepting principles based on authority, tradition, or aesthetic preference rather than verified reality.
+
+## Observation
+
+Throughout the development of Open Engineer, the most robust principles have emerged from verifiable encounters with reality, either direct or corroborated (see OE-0004 for the taxonomy).
+
+## Engineering Principle
+
+Observe first. Recognize patterns. Translate into engineering language. Verify against reality. Preserve the resulting understanding.
+
+## Reasoning
+
+Observation anchors the standard to reality. Without it, the standard becomes theory — potentially interesting, but not engineering.
+
+## Relationship to Existing Concepts
+
+This RFC underpins the dependency chain beginning at OE-0004. It is implemented through the editorial Translation principle (`reference/editorial-principles.md`, Section 1).

rfc/rfc-0002.md

@@ -0,0 +1,28 @@
+# RFC-0002: Thought Drift
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC defines "thought drift" — the accumulation of redundant or contradictory concepts under different names — and establishes countermeasures.
+
+## Motivation
+
+Continued ideation without structure leads to duplicates under different names. Thought drift erodes clarity and creates the ambiguity that a standard cannot tolerate.
+
+## Observation
+
+During development, the project observed that unconstrained ideation produced concepts that, upon review, were redundant with existing definitions under different names.
+
+## Engineering Principle
+
+No new concept may be added without first verifying it does not duplicate or contradict an existing concept. OE-0002 (Core Vocabulary) is the authoritative check.
+
+## Reasoning
+
+A standard requires one definition per term and one home per concept. Allowing drift creates ambiguity, which creates confusion, which undermines trust.
+
+## Relationship to Existing Concepts
+
+Thought drift is countered by Single Responsibility (`reference/editorial-principles.md`, Section 2), the RC2 Refinement Gate (Section 4), and Law 6 (Compression Over Expansion).

rfc/rfc-0003.md

@@ -0,0 +1,28 @@
+# RFC-0003: Engineering Context
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC proposes that "preserving engineering context" be the defining purpose of the standard, and establishes the minimum required structure for a context record.
+
+## Motivation
+
+When engineers lose the reasoning behind decisions, they re-derive understanding from first principles. This is wasteful and error-prone. The most valuable thing a standard can preserve is not the final artifact, but the context that produced it.
+
+## Observation
+
+Engineers across all disciplines report that inherited systems without context records require significantly more effort to maintain, modify, or extend than systems with preserved reasoning.
+
+## Engineering Principle
+
+Open Engineer is an open standard for preserving engineering context. The context record — a structured document with defined required fields — is the unit of preservation.
+
+## Reasoning
+
+Context preservation is the thread made concrete. The minimum required fields (defined in OE-0003) give the standard an implementable artifact: a practitioner can produce a context record, and a subsequent practitioner can evaluate whether it meets the completeness criterion.
+
+## Relationship to Existing Concepts
+
+Engineering context is defined in OE-0003. Context records are the output of the decision process (OE-0008).

rfc/rfc-0004.md

@@ -0,0 +1,28 @@
+# RFC-0004: Vocabulary
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC formalizes Open Engineer's core vocabulary as a defined, versioned glossary with one authoritative location.
+
+## Motivation
+
+Engineers across disciplines share an informal conceptual vocabulary. Without formal definitions, terms are used inconsistently, leading to ambiguity. A standard requires precise, non-redundant terminology.
+
+## Observation
+
+During development, the same concept was sometimes described with different words in different documents, creating the potential for silent divergence.
+
+## Engineering Principle
+
+Every canonical term has one definition, located in one authoritative document (OE-0002). All other documents reference OE-0002; they do not redefine terms.
+
+## Reasoning
+
+A shared vocabulary is the foundation of a shared standard. Formal definitions eliminate ambiguity and create a reliable foundation for all subsequent work.
+
+## Relationship to Existing Concepts
+
+Vocabulary is defined in OE-0002. Term consistency is enforced by the No Duplication editorial principle (`reference/editorial-principles.md`, Section 7) and the Enduring Concept test (Section 5).

rfc/rfc-0005.md

@@ -0,0 +1,28 @@
+# RFC-0005: Stewardship
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC proposes stewardship — the obligation to maintain and improve engineering knowledge for future practitioners — as the governing principle for the standard.
+
+## Motivation
+
+Knowledge governed by ownership is hoarded, restricted, or lost when the owner departs. Knowledge governed by stewardship is maintained, extended, and transmitted.
+
+## Observation
+
+The most durable knowledge systems — open-source software, professional engineering bodies, craft guilds — are governed by stewardship rather than ownership.
+
+## Engineering Principle
+
+Standard documents are stewarded, not owned. Contributions are evaluated on value to future practitioners, not contributor status.
+
+## Reasoning
+
+Stewardship aligns with the standard's purpose: preserving engineering context across generations. Stewardship creates an obligation to preserve and improve. It includes the obligation to identify and flag context that has become obsolete or incorrect.
+
+## Relationship to Existing Concepts
+
+Stewardship is defined in OE-0009. It is the transmit discipline, paired with inheritance (OE-0010, the receive discipline).

rfc/rfc-0006.md

@@ -0,0 +1,28 @@
+# RFC-0006: Inheritance
+
+**Status:** Proposed
+**Phase:** The Bedrock Phase
+
+## Abstract
+
+This RFC formalizes inheritance — the act of receiving and engaging with engineering knowledge from prior work — and distinguishes it from stewardship and from the thread.
+
+## Motivation
+
+Engineering knowledge is not created anew each generation. Without a formal concept of inheritance, the standard lacks a mechanism for describing how knowledge flows through time.
+
+## Observation
+
+The most enduring engineering traditions explicitly value knowledge transmission. When that transmission breaks down, knowledge is lost and must be re-derived at great cost.
+
+## Engineering Principle
+
+Inheritance is the receive discipline: the responsibility to actively understand what has been passed down, not merely to possess it. It is distinguished from stewardship (the transmit discipline) and from the thread (the channel model itself).
+
+## Reasoning
+
+Inheritance is the temporal dimension of engineering context. Context preservation (RFC-0003) is meaningless without a mechanism for passing preserved context forward. The distinction between stewardship (transmit) and inheritance (receive) is necessary because they face different failure modes: stewardship fails through neglect; inheritance fails through passivity.
+
+## Relationship to Existing Concepts
+
+Inheritance is defined in OE-0010. It depends on stewardship (OE-0009). It is measured by thread integrity (OE-0001).

spec/oe-0000-charter.md

@@ -0,0 +1,64 @@
+# OE-0000: Charter
+
+**Status:** Draft
+**Phase:** The Bedrock Phase
+**Version:** 0.2.0-draft
+
+## Purpose
+
+Open Engineer is an open standard for preserving engineering context.
+
+Open Engineer does not seek to tell engineers what to think. It seeks to preserve how engineers arrive at understanding.
+
+## Domain of Applicability
+
+This standard applies to any discipline in which practitioners make decisions under constraints, observe outcomes, and transmit the results of those decisions to subsequent practitioners. This includes but is not limited to:
+
+- Civil, mechanical, electrical, chemical, and aerospace engineering
+- Software and systems engineering
+- Biomedical and environmental engineering
+- Industrial design and manufacturing engineering
+
+The standard does not require that all disciplines use identical methods. It requires that context preservation follow a common structural framework, regardless of discipline-specific content.
+
+## Nature of the Standard
+
+Open Engineer is a standard.
+
+Not a philosophy. Not a documentation system. Not a project. Not a presentation layer.
+
+Philosophy, documentation systems, projects, and presentation layers become implementations. The standard comes first.
+
+## Scope
+
+Open Engineer remains grounded in engineering while recognizing that valuable observations about decision-making and knowledge continuity have emerged from many domains throughout human history. It is open. It respects every discipline. It welcomes observations from every domain and every generation. It remains anchored to reality through observation, verification, and stewardship.
+
+## Governance Authority
+
+The Engineering Laws (see `laws/engineering-laws.md`) govern all content in this standard. All editorial rules are defined in `reference/editorial-principles.md`. Specification documents may reference but must not duplicate them.
+
+## Document Status Lifecycle
+
+| Status | Definition |
+|---|---|
+| **Draft** | Under active development. Content may change without formal process. |
+| **Proposed** | Submitted for review. Content is stable pending review outcome. |
+| **RC** (Release Candidate) | Reviewed and accepted. Frozen unless a subsequent RFC explicitly supcedes it. |
+| **Accepted** | Part of the canonical standard. Changes require RFC. |
+| **Deprecated** | Superseded by a later document. Retained for historical traceability. |
+
+Advancement from Draft to Proposed requires completion of the editorial gate defined in `reference/editorial-principles.md`. Advancement from Proposed to RC requires successful independent review. Advancement from RC to Accepted requires no outstanding objections.
+
+## Versioning
+
+Each specification document carries an independent version number following the pattern `MAJOR.MINOR.PATCH-status`. The overall standard version is the highest version number of any Accepted document.
+
+## Conformance Basis
+
+Compliance with Open Engineer means that an engineering context record contains the minimum required fields defined in OE-0003 (Engineering Context), follows the editorial principles defined in `reference/editorial-principles.md`, and respects the dependency integrity defined in OE-0011 (Evolution).
+
+Detailed conformance testing criteria will be defined during the Implementation Phase.
+
+## Dependency
+
+This is the root document. All other specification documents extend from this charter.

spec/oe-0001-foundation.md

@@ -0,0 +1,69 @@
+# OE-0001: Foundation
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0000 (Charter)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+This document establishes the foundational concepts upon which all subsequent specification documents are built.
+
+## Bedrock
+
+Reality remains fixed. Understanding grows around it.
+
+Reality — the physical world, the constraints of materials and physics, the behavior of systems under load — does not change because an engineer's model of it changes. Every engineering model, specification, or theory is a layer of understanding built on top of that reality. The bedrock is always there regardless of how understanding evolves around it.
+
+The standard must always distinguish between reality and the current understanding of reality. Confusing the two leads to the reification of models — treating an approximation as if it were the thing it approximates.
+
+## The Thread
+
+Knowledge continuity is the channel through which engineering understanding passes between practitioners over time.
+
+**Properties of the thread:**
+
+- It is maintained by deliberate action, not by default. When practitioners stop maintaining it, it degrades.
+- It carries understanding, not just information. A procedure manual preserves information. A well-documented decision record preserves understanding.
+- Its integrity is measurable by whether a subsequent practitioner can reconstruct the reasoning behind a prior decision without direct access to the original decision-maker.
+- It breaks when context is lost — when the reasoning, alternatives, and constraints behind a decision are no longer accessible.
+
+The thread is not a metaphor for continuity. It is a model of continuity with defined properties. The model is testable: given a preserved engineering context record, can a practitioner unfamiliar with the original decision reconstruct the reasoning? If yes, the thread is intact. If no, the thread has broken.
+
+## Spiral Re-evaluation
+
+Spiral re-evaluation is the process of returning to previously examined questions with additional experience or evidence, producing progressively deeper understanding.
+
+Spiral re-evaluation differs from iteration in that each pass deepens understanding rather than merely repeating a process. It differs from repetition in that new experience or evidence is incorporated at each pass. The spiral metaphor captures the dual nature of the process: it returns to the same questions (circular) but at a deeper level of understanding (vertical progression).
+
+## Structure Carries Meaning
+
+The arrangement and relationship between components conveys information that the individual components do not. An engineering drawing is not a collection of lines — it is a specific arrangement of lines that encodes precise spatial relationships. A specification is not a list of statements — it is an ordered, interconnected structure in which position and dependency carry meaning.
+
+This principle has consequences for the standard itself: the ordering of the specification documents is part of their meaning.
+
+## Examples Are Bridges
+
+Examples serve as structural transportation, carrying the reader from unfamiliar concepts to familiar understanding. Examples are load-bearing elements of the standard, not decorative additions. Every example must serve a specific bridging function.
+
+For the editorial treatment of examples, including the Self-Fading Example principle, see `reference/editorial-principles.md`.
+
+## Editorial Principles
+
+The authoritative editorial principles governing all content in this standard are defined in `reference/editorial-principles.md`. This document does not duplicate them. All specification documents reference rather than reproduce them.
+
+## Process
+
+The foundational process that Open Engineer follows:
+
+1. Observe first.
+2. Recognize patterns.
+3. Translate into engineering language.
+4. Verify against reality.
+5. Preserve the resulting understanding.
+
+This process allows Open Engineer to learn from a bridge builder in ancient Rome, a modern aerospace engineer, an Indigenous weaving tradition, a machinist, a philosopher, or a software architect — without becoming a historical, cultural, or philosophical anthology.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0002-core-vocabulary.md

@@ -0,0 +1,78 @@
+# OE-0002: Core Vocabulary
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0001 (Foundation)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Engineers across disciplines share a conceptual vocabulary. Open Engineer documents that vocabulary's grammar — the precise definitions, relationships, and boundaries of terms that carry specific meaning within this standard.
+
+All terms defined here must be used consistently across all specification documents, RFCs, and reference materials. The authoritative editorial rules governing terminology are defined in `reference/editorial-principles.md` (see: Enduring Concept Test, Single Responsibility).
+
+## Terms
+
+### Bedrock
+
+Reality — the physical world, the constraints of materials and physics, the behavior of systems under load — which does not change regardless of an engineer's model of it. (Source: OE-0001)
+
+### The Thread
+
+The model of knowledge continuity through which engineering understanding passes between practitioners over time. The thread has defined properties: it requires deliberate maintenance, carries understanding rather than just information, has measurable integrity, and breaks when context is lost. (Source: OE-0001)
+
+### Engineering Context
+
+The structured record of the reasoning behind an engineering decision, including the observations, alternatives, constraints, and verification that produced it. The minimum required structure is defined in OE-0003. (Source: OE-0003)
+
+### Observation
+
+A verifiable encounter with reality, either direct (through measurement or experiment) or corroborated (independently confirmed by multiple traditions or domains). See OE-0004 for the full taxonomy. (Source: OE-0004)
+
+### Corroborated Observation
+
+An observation reported by a source outside direct engineering practice that has been independently confirmed by engineering evidence or by independent confirmation across multiple traditions. (Source: OE-0004)
+
+### Survey
+
+A structured assessment of the current state of engineering understanding on a specific topic, aggregating observations, identifying patterns, and flagging gaps. (Source: OE-0005)
+
+### Understanding
+
+A contextualized model of reality derived from observation and organized through survey. Understanding is the state an engineer reaches when they can explain not only what a system does, but why it was designed that way, what alternatives were considered, and what trade-offs were made. Understanding is distinct from information: information is the raw material; understanding is the structured relationship between information, context, and reality. (Source: OE-0006)
+
+### Verification
+
+The process of testing understanding against reality. Understanding is provisional until verified. See OE-0007. (Source: OE-0007)
+
+### Decision
+
+A choice made within a specific context, informed by observation and bounded by constraints, preserved as a structured record. See OE-0008. (Source: OE-0008)
+
+### Stewardship
+
+The obligation to maintain and improve engineering knowledge for future practitioners. Stewardship is the transmit discipline: the responsibility to pass knowledge forward in better condition than it was received. See OE-0009. (Source: OE-0009)
+
+### Inheritance
+
+The act of receiving and engaging with engineering knowledge from prior work. Inheritance is the receive discipline: the responsibility to actively understand what has been passed down, not merely to possess it. See OE-0010. (Source: OE-0010)
+
+### Spiral Re-evaluation
+
+The process of returning to previously examined questions with additional experience or evidence, producing progressively deeper understanding. (Source: OE-0001)
+
+### Translation
+
+The process of converting an observation from any domain into precise engineering language. Translation extracts the observation while discarding the surrounding ideology. The authoritative rules governing translation are defined in `reference/editorial-principles.md`. (Source: OE-0001, `reference/editorial-principles.md`)
+
+### Evolution
+
+The disciplined, verified extension of the standard's body of knowledge through the change workflow defined in OE-0011. (Source: OE-0011)
+
+### Enduring Concept
+
+A concept identified by its function rather than by any technology that currently expresses it. Enduring concepts survive technology change. The test for enduring-concept compliance is defined in `reference/editorial-principles.md`. (Source: `laws/engineering-laws.md`, `reference/editorial-principles.md`)
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0003-engineering-context.md

@@ -0,0 +1,69 @@
+# OE-0003: Engineering Context
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0002 (Core Vocabulary)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Open Engineer is an open standard for preserving engineering context.
+
+Everything else in the standard extends from that purpose.
+
+## Definition
+
+Engineering context is the structured record of the reasoning behind an engineering decision. A complete context record enables a subsequent practitioner to reconstruct why a decision was made, what alternatives were considered, what constraints applied, and how the outcome was confirmed.
+
+Context is not background information. It is the decision-shaped record of an engineering process. Without context, a decision is an isolated artifact — its output may be visible but its reasoning is inaccessible.
+
+## Minimum Context Record Structure
+
+Every engineering context record must contain the following fields:
+
+| Field | Description | Required |
+|---|---|---|
+| **Decision** | What was decided | Yes |
+| **Observation** | What was observed that prompted the decision | Yes |
+| **Alternatives** | What options were considered, including rejected options | Yes |
+| **Constraints** | What bounded the choice (technical, environmental, temporal, economic) | Yes |
+| **Reasoning** | Why this option was selected over the alternatives | Yes |
+| **Verification** | How the outcome was confirmed against reality | Yes |
+| **Lineage** | What prior work this decision builds on | Yes |
+| **Assumptions** | What was assumed, both explicit and implicit | Yes |
+
+### Supplementary Fields
+
+Context records may additionally include:
+
+| Field | Description |
+|---|---|
+| **Open Questions** | What remains unknown or uncertain |
+| **Discipline-Specific Data** | Measurements, calculations, test results relevant to the specific engineering domain |
+| **Traceability** | Links to related context records, specifications, or requirements |
+
+### Completeness
+
+A context record is complete when all required fields are populated with sufficient detail that a practitioner unfamiliar with the original decision can reconstruct the reasoning. Sufficiency of detail is judged by whether the record passes the thread integrity test defined in OE-0001: can the reader explain why the decision was made without consulting the original decision-maker?
+
+## Why Context Matters
+
+When context is lost, practitioners must re-derive understanding from first principles. Re-derivation is costly in engineering time and introduces risk when the re-derivation produces different conclusions than the original reasoning.
+
+When context is preserved, subsequent practitioners begin where their predecessors left off, building on verified understanding rather than restarting from first principles. This is the function of the thread made concrete.
+
+## Context as the Unit of Preservation
+
+If Open Engineer has a unit of measurement, it is the context record — a structured, self-contained record of engineering reasoning.
+
+Every other element of the standard serves the goal of capturing, structuring, preserving, and transmitting engineering context.
+
+## Known Limitations
+
+This standard addresses explicit, articulable context. Much engineering knowledge is tacit — embodied in practice, judgment, and experience. Tacit knowledge cannot be fully captured in a structured record. The standard acknowledges this limitation and aims to preserve the explicit portion as completely as possible, recognizing that it captures the articulable fraction of engineering understanding.
+
+Some engineering context is proprietary, classified, or legally restricted. The standard defines the structure of context records but does not define access control mechanisms. Implementations must address confidentiality, security, and access control as required by their domain.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0004-observation.md

@@ -0,0 +1,62 @@
+# OE-0004: Observation
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0003 (Engineering Context)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Observation is the primary input to the engineering process. Before any principle can be established, before any decision can be made, there must first be observation.
+
+## Definition
+
+An observation is a verifiable encounter with reality.
+
+## Taxonomy of Observations
+
+Not all observations enter the engineering process through the same path. Open Engineer distinguishes two categories:
+
+### Direct Observation
+
+A measurement, experiment, or empirical encounter with physical reality conducted by the practitioner or their team. Direct observations are the primary input to engineering decisions.
+
+Examples: load test results, material strength measurements, system performance benchmarks, field inspections.
+
+### Corroborated Observation
+
+An observation reported by a source outside direct engineering practice that has been independently confirmed by engineering evidence or by independent confirmation across multiple traditions or domains.
+
+Corroborated observations are valid inputs when the underlying observation has withstood testing from independent sources. The standard does not accept them on authority — it accepts them on the basis of independent corroboration.
+
+Examples of corroboration:
+
+| Reported Observation | Independent Engineering Confirmation |
+|---|---|
+| Distinguish controllable from uncontrollable factors (multiple traditions) | Control theory, stress engineering, decision theory — all independently arrived at this distinction |
+| Attachment to preferred solutions distorts judgment (multiple traditions) | Cognitive bias research, engineering failure analysis — both confirm this pattern |
+| Hypotheses must survive testing (scientific method) | Every engineering verification methodology confirms this |
+
+## The Principle of Observation First
+
+Observe first. Before theorizing. Before abstracting. Before generalizing. The practitioner must first identify what has been observed — directly or through corroboration — and record it as it is, not as expected or desired.
+
+This is the first step in the Open Engineer process:
+
+1. Observe first.
+2. Recognize patterns.
+3. Translate into engineering language.
+4. Verify against reality.
+5. Preserve the resulting understanding.
+
+## Observation as Foundation
+
+No later specification document may redefine what observation means. Only extend it. Observation is bedrock.
+
+## Single Responsibility
+
+This document defines observation and its taxonomy. It does not define verification (see OE-0007) or translation (see `reference/editorial-principles.md`). It references them.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0005-survey.md

@@ -0,0 +1,40 @@
+# OE-0005: Survey
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0004 (Observation)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+A survey is a structured assessment of the current state of engineering understanding on a specific topic.
+
+## Definition
+
+A survey captures what is known, what is unknown, and what is contested within a specific engineering domain. A survey aggregates observations (OE-0004), identifies patterns, and flags gaps. It produces an organized view of the current state of understanding that serves as input to the formation of understanding (OE-0006).
+
+## Structure
+
+A survey document must contain:
+
+1. **Scope** — The specific topic or domain being assessed
+2. **Observations Collected** — The direct and corroborated observations relevant to the topic
+3. **Patterns Identified** — Recurring relationships or principles observed across the collected observations
+4. **Gaps Flagged** — Areas where observations are missing, insufficient, or contested
+5. **Relationship to Prior Surveys** — How this survey builds on or differs from prior assessments
+
+## Relationship to Observation
+
+Surveys depend on observations (OE-0004) as their primary input. A survey without observations is speculation. A survey built on verified observations is engineering context.
+
+## Relationship to Understanding
+
+A survey is not understanding itself. It is the organized input from which understanding is formed. Understanding (OE-0006) is the contextualized model that a practitioner constructs by engaging with a survey's findings.
+
+## Single Responsibility
+
+This document defines the structure and role of surveys. It does not define understanding (see OE-0006). It references it.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0006-understanding.md

@@ -0,0 +1,40 @@
+# OE-0006: Understanding
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0005 (Survey)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Understanding is a contextualized model of reality derived from observation and organized through survey.
+
+## Definition
+
+Understanding is the state a practitioner reaches when they can explain not only what a system does, but why it was designed that way, what alternatives were considered, and what trade-offs were made.
+
+Understanding is distinct from information. Information is the raw material — facts, measurements, records. Understanding is the structured relationship between information, context, and reality. A database contains information. An engineer who can explain the reasoning behind every entry in that database holds understanding.
+
+## From Observation to Understanding
+
+Understanding follows a path through the specification's dependency chain:
+
+Observation (OE-0004) -> Survey (OE-0005) -> Understanding (OE-0006) -> Verification (OE-0007)
+
+Observation provides the raw input. Survey organizes observations into a coherent picture. Understanding is the model the practitioner constructs from that picture. Verification (OE-0007) then tests that model against reality.
+
+Understanding is provisional until verified. Even after verification, understanding remains subject to spiral re-evaluation — the accumulated deepening that comes from returning to the same question with more experience.
+
+## Understanding as What the Thread Carries
+
+When one generation passes engineering knowledge to the next, what they pass is understanding — the deep comprehension of why things are the way they are, not merely what things are.
+
+Open Engineer's purpose is to preserve this understanding so that each generation can begin closer to bedrock than the last. The mechanism for that preservation is the engineering context record (OE-0003).
+
+## Single Responsibility
+
+This document defines understanding. It does not define verification (see OE-0007). It references it.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0007-verification.md

@@ -0,0 +1,40 @@
+# OE-0007: Verification
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0006 (Understanding)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Verification is the process of testing understanding against reality.
+
+## Definition
+
+Verification applies to understanding that has been formed through observation and survey. It is the mechanism by which understanding earns confidence.
+
+No amount of reasoning, no matter how elegant, substitutes for verification. An engineering model that has not been verified is a hypothesis — potentially valuable, but not yet reliable enough to base decisions on.
+
+## The Verification Loop
+
+Verification closes the loop with observation:
+
+1. Observation provides the initial input (OE-0004)
+2. Survey organizes observations (OE-0005)
+3. Understanding forms a model (OE-0006)
+4. Verification tests the model against reality
+5. If the model fails verification, the practitioner returns to observation with new information
+
+This loop is what drives spiral re-evaluation. Each cycle through the loop potentially deepens understanding.
+
+## Relationship to Understanding
+
+Verification is applied to understanding. It is not part of understanding's definition. Understanding (OE-0006) is the model. Verification is the test applied to that model. The dependency chain reflects this ordering: a model must exist before it can be tested.
+
+## Single Responsibility
+
+This document defines verification and its relationship to the observation loop. It does not define decision-making (see OE-0008). It references it.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0008-decisions.md

@@ -0,0 +1,34 @@
+# OE-0008: Decisions
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0007 (Verification)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+A decision is a choice made within a specific context, informed by observation and bounded by constraints, preserved as a structured record.
+
+## Definition
+
+In Open Engineer, a decision is not merely a choice. It is a recorded, contextualized choice — one that preserves the reasoning, alternatives considered, constraints faced, and verification applied. A decision without its context is an isolated artifact. A decision with its context is a building block for future understanding.
+
+## The Context Record as Decision Output
+
+Every decision produces an engineering context record (OE-0003). The minimum required fields of that record — Decision, Observation, Alternatives, Constraints, Reasoning, Verification, Lineage, Assumptions — constitute the structured output of the decision process.
+
+## Decisions as Engineering Context
+
+When preserved as a context record, a decision allows future practitioners to understand not just what was done, but why — and to make better decisions as a result. This is the mechanism by which the thread is maintained.
+
+## Editorial Gate for New Additions
+
+All additions to the standard — whether new specification content, RFCs, or reference material — must pass the editorial gate defined in `reference/editorial-principles.md`. That gate includes the four-question framework, the Enduring Concept test, and the RC2 refinement criteria. This document does not duplicate those rules.
+
+## Single Responsibility
+
+This document defines the role of decisions within the standard and their relationship to context records. It does not define the editorial process for evaluating decisions (see `reference/editorial-principles.md`). It references it.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0009-stewardship.md

@@ -0,0 +1,41 @@
+# OE-0009: Stewardship
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0008 (Decisions)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Stewardship is the obligation to maintain and improve engineering knowledge for future practitioners.
+
+## Definition
+
+Stewardship is the transmit discipline: the responsibility to pass engineering knowledge forward in better condition than it was received. A steward does not possess the knowledge — they hold it in trust, maintaining it and improving it before passing it onward.
+
+## Stewardship Distinguished from Inheritance
+
+Stewardship and inheritance (OE-0010) are coupled but distinct:
+
+- **Stewardship** is the transmit direction. It governs how the current practitioner maintains, improves, and transmits knowledge.
+- **Inheritance** is the receive direction. It governs how the next practitioner receives and engages with what has been transmitted.
+
+A single generation performs both simultaneously — inheriting from the past and stewarding for the future. They are separated in the specification because they impose different obligations and face different failure modes. Stewardship fails through neglect. Inheritance fails through passivity.
+
+## Implications
+
+- Standard documents are stewarded, not owned.
+- Contributions are evaluated on their value to future practitioners, not the status of the contributor.
+- The standard's primary obligation is to clarity and preservation.
+
+## Known Limitation: Incorrect or Obsolete Context
+
+Stewardship includes the obligation to identify and flag context that has become obsolete or that was incorrect when inherited. Preservation is not blind accumulation. A steward must actively evaluate whether inherited understanding still reflects reality and, where it does not, document the discrepancy.
+
+## Single Responsibility
+
+This document defines stewardship. It does not define inheritance (see OE-0010). It references it.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0010-inheritance.md

@@ -0,0 +1,38 @@
+# OE-0010: Inheritance
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0009 (Stewardship)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Inheritance is the act of receiving and engaging with engineering knowledge from prior work.
+
+## Definition
+
+Inheritance is the receive discipline: the responsibility to actively understand what has been passed down, not merely to possess it. Passive reception — storing documents without engaging with their reasoning — is not inheritance. Inheritance requires the practitioner to reconstruct the understanding behind the inherited context.
+
+## Inheritance Distinguished from the Thread
+
+The thread (OE-0001) is the channel — the model of continuity itself. Inheritance is the act of engaging with what that channel carries. The thread's integrity (OE-0001) is measured by whether inheritance succeeds: can the inheriting practitioner reconstruct the original reasoning? If yes, the thread is intact. If no, the thread has broken at that point.
+
+## Inheritance Distinguished from Stewardship
+
+Inheritance and stewardship (OE-0009) are coupled but distinct. See OE-0009 for the full distinction.
+
+## Inheriting Responsibilities
+
+Practitioners inherit responsibilities as well as resources. Every engineering artifact comes with obligations: a bridge must be maintained, a specification must be kept current, a body of knowledge must be evaluated and extended. The inheriting practitioner assumes these obligations as part of receiving the artifact.
+
+## The Pre-Discipline Principle
+
+Engineering was not always divided into civil, mechanical, electrical, software. Before specialization, engineering was unified around shared principles: observation, measurement, craftsmanship, and the transmission of knowledge. Open Engineer asks what principles existed before the disciplines separated — because those principles apply universally and form the bedrock on which discipline-specific knowledge is built.
+
+## Single Responsibility
+
+This document defines inheritance. It does not define stewardship (see OE-0009) or the thread (see OE-0001). It references them.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

spec/oe-0011-evolution.md

@@ -0,0 +1,48 @@
+# OE-0011: Evolution
+
+**Status:** Draft
+**Version:** 0.2.0-draft
+**Depends on:** OE-0010 (Inheritance)
+**Phase:** The Bedrock Phase
+
+## Overview
+
+Evolution is the disciplined, verified extension of the standard's body of knowledge.
+
+## Definition
+
+Evolution is not arbitrary change. It is the extension of the standard through the defined change workflow. Every change must survive the editorial gate defined in `reference/editorial-principles.md`. Every change must be consistent with the dependency tree.
+
+## The Dependency Tree
+
+The specification documents form a strict dependency chain:
+
+Charter (OE-0000) -> Foundation (OE-0001) -> Core Vocabulary (OE-0002) -> Engineering Context (OE-0003) -> Observation (OE-0004) -> Survey (OE-0005) -> Understanding (OE-0006) -> Verification (OE-0007) -> Decision (OE-0008) -> Stewardship (OE-0009) -> Inheritance (OE-0010) -> Evolution (OE-0011)
+
+Nothing later in the chain may redefine an earlier layer. Only extend it.
+
+## The Change Workflow
+
+The canonical workflow for all changes:
+
+Observe -> Draft -> Review -> Accept -> Freeze (RC) -> Reference
+
+Once a document reaches RC status, it is not rewritten unless a subsequent RFC explicitly supedes it. The status lifecycle governing these transitions is defined in OE-0000 (Charter).
+
+## Constitutional Governance Gap
+
+This document defines the change workflow for the standard's technical content. It does not define the process for modifying the standard's own governance — its laws, editorial principles, or status criteria. A future specification or amendment must address this constitutional layer. Until then, changes to governance follow the same workflow as changes to technical content, with the acknowledgment that this is an interim arrangement.
+
+## Spiral Re-evaluation as Evolution
+
+Evolution is not linear. It is spiral. The standard will return to earlier concepts with deeper understanding, refining and extending them without contradicting the bedrock they rest on. Each spiral pass either eliminates ambiguity or strengthens traceability.
+
+## The Bedrock Phase
+
+The current phase of the Open Engineer standard is The Bedrock Phase. Every sentence accepted during this phase is intended to support everything built above it. If this phase is executed carefully, downstream implementations — presentation layers, interchange formats, context record tooling — will not require new concepts. They will express what already exists in the specification.
+
+The specification leads. Everything else follows.
+
+## Applicable Laws
+
+This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`.

whatremains.txt

@@ -0,0 +1,228 @@
+WHAT REMAINS — RC2 Revised Tarball
+====================================
+
+This file tracks content from the source sessions and the independent
+review that has NOT been incorporated into the specification.
+
+All review findings have been addressed in one of three ways:
+  FIXED   — The issue has been resolved in the revised files
+  PARTIAL — Addressed but a residual gap remains
+  DEFERRED — Acknowledged as a known gap for a future phase
+
+---
+
+
+REVIEW FINDINGS STATUS
+=======================
+
+S-1  Dual Charter                    FIXED
+     Root CHARTER.md is now a navigation pointer.
+     spec/oe-0000-charter.md is the sole authoritative charter.
+
+S-2  Triple-Distributed Editorial    FIXED
+     reference/editorial-principles.md is now the sole
+     authoritative source. All other documents reference it.
+
+S-3  Laws/ and spec/ relationship    FIXED
+     All spec documents now include "Applicable Laws" section
+     referencing laws/engineering-laws.md.
+
+S-4  Bootstrap Problem (OE-0011)    PARTIAL
+     OE-0011 now explicitly acknowledges the constitutional
+     governance gap. The gap itself is not resolved — a
+     future amendment is required.
+
+T-1  Observation Definition/Usage    FIXED
+     OE-0004 now distinguishes Direct Observation from
+     Corroborated Observation. The translation examples are
+     presented under corroborated observation with engineering
+     confirmation evidence.
+
+T-2  Knowledge vs Understanding      FIXED
+     OE-0006 no longer redefines knowledge. Understanding is
+     defined on its own terms.
+
+T-3  Bedrock Term Collision          DEFERRED
+     Acknowledged. "Bedrock" has a geotechnical meaning.
+     No rename applied — the term is deeply embedded in the
+     project's identity. Enduring Concept test (Law 5) would
+     flag this if evaluated strictly. The project may choose
+     to rename or to accept the collision.
+
+T-4  The Thread — Untestable Model   FIXED
+     OE-0001 now defines four testable properties of the
+     thread: deliberate maintenance, carries understanding,
+     measurable integrity, breaks when context is lost.
+     OE-0010 defines thread integrity as testable by whether
+     a practitioner can reconstruct reasoning.
+
+T-5  Evolution Term Usage            PARTIAL
+     Renamed to "disciplined, verified extension" in the
+     definition. The document title remains "Evolution" —
+     same collision issue as T-3.
+
+SP-1 No Operational Context Def      FIXED
+     OE-0003 now defines a minimum context record structure
+     with 8 required fields and 3 supplementary fields,
+     plus a completeness criterion.
+
+SP-2 Understanding-Verification Circ  FIXED
+     OE-0006 no longer uses "verified" in the definition of
+     understanding. Understanding is "a contextualized model
+     of reality derived from observation and survey."
+     Verification (OE-0007) is the process applied to it.
+     The dependency chain is now acyclic.
+
+SP-3 No Conformance Clause           PARTIAL
+     OE-0000 now defines conformance basis at a high level:
+     "contains the minimum required fields, follows editorial
+     principles, respects dependency integrity." Detailed
+     conformance testing criteria deferred to Implementation
+     Phase.
+
+SP-4 Stub Documents                 FIXED
+     OE-0005 (Survey) now has a concrete 5-field structure.
+     OE-0007 (Verification) now defines the verification loop
+     explicitly. No forward references to undefined content.
+
+E-1  Meta-Commentary                 FIXED
+     All authorial asides removed from spec documents.
+
+E-2  Rhetorical Formatting           FIXED
+     Negation lists and emphatic repetition removed from
+     spec documents.
+
+E-3  Inconsistent Status Labels      FIXED
+     OE-0000 now defines the status lifecycle:
+     Draft -> Proposed -> RC -> Accepted -> Deprecated.
+     All documents set to Draft for consistency.
+
+I-1  No Implementable Artifact       FIXED
+     OE-0003 now defines a concrete context record structure.
+     The bridge example demonstrates a populated record.
+     This moves the standard from fully abstract to
+     partially implementable.
+
+I-2  Empty Directories              DEFERRED
+     website/, implementations/, schemas/, tools/ remain
+     empty. They are structural placeholders. Their content
+     will be defined during the Implementation Phase.
+
+EG-1 Translation Evidence           DEFERRED
+     The claim that translation produces better outcomes
+     is still asserted without empirical evidence. This is
+     an evidence gap that requires real-world testing.
+
+EG-2 Context Preservation Evidence  DEFERRED
+     The claim that context preservation reduces re-derivation
+     cost is asserted but not quantified. Requires empirical
+     study.
+
+EG-3 Historical Citations           PARTIAL
+     The Antikythera example now states "comparable complexity
+     in geared mechanisms" (more precise than "nothing of
+     comparable complexity"). Full citations still deferred.
+
+EG-4 "Engineers Already Speak This"  FIXED
+     OE-0002 now states "Engineers across disciplines share a
+     conceptual vocabulary" without the empirical claim.
+
+R-1  Stewardship/Inheritance         FIXED
+     Sharply distinguished: Stewardship = transmit discipline,
+     Inheritance = receive discipline. Different failure modes
+     (neglect vs passivity).
+
+R-2  Thread/Inheritance              FIXED
+     Sharply distinguished: Thread = the channel model,
+     Inheritance = the act of engaging with what the
+     channel carries. OE-0010 makes this explicit.
+
+R-3  Translation in Four Places      FIXED
+     Translation is defined in OE-0002, with authoritative
+     rules in reference/editorial-principles.md. All other
+     documents reference, not reproduce.
+
+P-1  Bedrock as Epistemology        PARTIAL
+     OE-0001 now defines bedrock as "reality — the physical
+     world, the constraints of materials and physics, the
+     behavior of systems under load" — more concrete than
+     the previous "immutable reality." Acknowledges that
+     understanding is always provisional. Does not address
+     the philosophical realism objection explicitly.
+
+P-2  Thread Untestable              FIXED
+     See T-4 above.
+
+M-1  No Engineer/Engineering Def    FIXED
+     OE-0000 now defines domain of applicability with
+     specific engineering disciplines listed.
+
+M-2  Tacit Knowledge               FIXED
+     OE-0003 now explicitly acknowledges the limitation:
+     "The standard acknowledges this limitation and aims to
+     preserve the explicit portion as completely as possible."
+
+M-3  Confidentiality/Security       FIXED
+     OE-0003 now acknowledges: "The standard defines the
+     structure of context records but does not define access
+     control mechanisms. Implementations must address
+     confidentiality, security, and access control as required
+     by their domain."
+
+M-4  Incorrect/Obsolete Context     FIXED
+     OE-0009 (Stewardship) now includes: "Stewardship includes
+     the obligation to identify and flag context that has
+     become obsolete or that was incorrect when inherited."
+
+M-5  No Versioning Scheme           FIXED
+     OE-0000 now defines versioning: independent document
+     versioning with MAJOR.MINOR.PATCH-status pattern.
+
+
+RC2 SESSION CONCEPTS STATUS
+===========================
+
+Law of Enduring Concepts            FIXED (Law 5 in engineering-laws.md)
+Five-Question RC2 Gate              FIXED (editorial-principles.md Section 4)
+Self-Fading Example                 FIXED (editorial-principles.md Section 6)
+Specification-first Architecture   PARTIAL (concept acknowledged in
+                                    OE-0011, ROADMAP; not yet a formal
+                                    directory-level concept)
+Compression Principle               FIXED (Law 6 in engineering-laws.md)
+RC2 Exit Criteria                   FIXED (ROADMAP.md)
+RC2 Acceptance Criteria             FIXED (ROADMAP.md)
+RC2 Milestone Statement            DEFERRED (not incorporated into spec
+                                    documents — it's process metadata,
+                                    not specification content)
+
+
+REMAINING GAPS (Not Addressed in This Revision)
+================================================
+
+1. Constitutional governance layer (S-4 PARTIAL)
+   OE-0011 acknowledges the gap. No solution implemented.
+
+2. "Bedrock" and "Evolution" term collisions (T-3, T-5 DEFERRED)
+   Both terms have established meanings in engineering that
+   differ from Open Engineer's usage. The Enduring Concept test
+   (Law 5) would flag both if applied rigorously to the
+   standard's own terms.
+
+3. Detailed conformance testing criteria (SP-3 PARTIAL)
+   The high-level conformance basis exists. Testable criteria
+   for "does a context record comply?" do not.
+
+4. Empirical evidence for core claims (EG-1, EG-2 DEFERRED)
+   Translation producing better outcomes and context preservation
+   reducing cost are asserted but not quantified.
+
+5. Full historical citations (EG-3 PARTIAL)
+
+6. Philosophical realism objection (P-1 PARTIAL)
+   The bedrock definition is more concrete but the
+   epistemological assumption remains unaddressed.
+
+7. A contemporary, multi-discipline worked example
+   All four examples are from historical contexts. A
+   software engineering or biomedical context record example
+   would strengthen cross-discipline applicability claims.