4.3 KiB
Executable File
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:
- Observation? — What was observed that prompted this?
- Engineering Principle? — What engineering principle does this express?
- Reasoning? — What connects the observation to the principle?
- 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:
- Is it an enduring concept? — Would this hold if current technologies disappeared?
- Does it already exist elsewhere? — Does another document or term already cover this?
- Does it reduce ambiguity? — Does this revision make something more precise?
- Can it survive technology change? — Is it anchored to a concept or a technology?
- 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.