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