69 lines
4.2 KiB
Markdown
Executable File
69 lines
4.2 KiB
Markdown
Executable File
# 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`. |