97 lines
4.4 KiB
Markdown
Executable File
97 lines
4.4 KiB
Markdown
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:
|
|
|
|
1. **Observation?** — What was observed that prompted this?
|
|
2. **Engineering Principle?** — What engineering principle does this express?
|
|
3. **Reasoning?** — What connects the observation to the principle?
|
|
4. **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 Refinement Gate
|
|
|
|
Every proposed refinement to existing content must additionally answer (this gate applies during any compression or stabilization pass, not only to a specific project milestone):
|
|
|
|
5. **Is it an enduring concept?** — Would this hold if current technologies disappeared?
|
|
6. **Does it already exist elsewhere?** — Does another document or term already cover this?
|
|
7. **Does it reduce ambiguity?** — Does this revision make something more precise?
|
|
8. **Can it survive technology change?** — Is it anchored to a concept or a technology?
|
|
9. **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. |