openengineer/spec/oe-0001-foundation.md

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.

Definition

Within this standard, Bedrock refers to the physical world and its constraints — materials, physics, the behavior of systems under load — which 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. Bedrock is always there regardless of how understanding is amended 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.

Term Collision Note

"Bedrock" has an established meaning in geotechnical engineering (the consolidated rock underlying surface soils). Within the scope of this standard, the term carries the definition above. Where ambiguity is possible, the standard uses the phrase "reality basis" as an unambiguous synonym.

Methodological Commitment

This standard makes a methodological commitment, not an ontological one. The commitment is: test understanding against observable outcomes. This commitment is compatible with multiple philosophical positions regarding the nature of reality. What the standard requires is that engineering models be tested against what is observed — not that practitioners hold a specific philosophical view about what reality is. Whether reality is ultimately knowable, socially constructed, or independent of observation is outside the scope of this standard. What is within scope is the engineering practice of testing models against evidence.

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.

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 seeks principles that existed before the disciplines separated, because those principles apply universally and form the reality basis on which discipline-specific knowledge is built. Discipline-specific content belongs in implementations, not in the core standard.

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.