2.9 KiB
Executable File
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.