61 lines
3.2 KiB
Markdown
Executable File
61 lines
3.2 KiB
Markdown
Executable File
# OE-0011: Amendment
|
|
|
|
**Status:** Draft
|
|
**Version:** 0.3.0-draft
|
|
**Depends on:** OE-0010 (Inheritance)
|
|
**Phase:** The Bedrock Phase
|
|
|
|
## Overview
|
|
|
|
Amendment is the disciplined, verified extension or modification of the standard's body of knowledge.
|
|
|
|
## Definition
|
|
|
|
Amendment is not arbitrary change. It is the extension or modification of the standard through the defined change workflow. Every change must survive the editorial gate defined in `reference/editorial-principles.md`. Every change must be consistent with the dependency tree.
|
|
|
|
## The Dependency Tree
|
|
|
|
The specification documents form a strict dependency chain:
|
|
|
|
Charter (OE-0000) -> Foundation (OE-0001) -> Core Vocabulary (OE-0002) -> Engineering Context (OE-0003) -> Observation (OE-0004) -> Survey (OE-0005) -> Understanding (OE-0006) -> Verification (OE-0007) -> Decision (OE-0008) -> Stewardship (OE-0009) -> Inheritance (OE-0010) -> Amendment (OE-0011)
|
|
|
|
Nothing later in the chain may redefine an earlier layer. Only extend it.
|
|
|
|
## The Change Workflow
|
|
|
|
The canonical workflow for all changes:
|
|
|
|
Observe -> Draft -> Review -> Accept -> Freeze (RC) -> Reference
|
|
|
|
Once a document reaches RC status, it is not rewritten unless a subsequent RFC explicitly supersedes it. The status lifecycle governing these transitions is defined in OE-0000 (Charter).
|
|
|
|
## Constitutional Governance
|
|
|
|
### Amendment of Technical Content
|
|
|
|
Changes to specification documents (OE-0000 through OE-0011) follow the standard change workflow: Observe -> Draft -> Review -> Accept -> Freeze (RC) -> Reference.
|
|
|
|
### Amendment of Governance Content
|
|
|
|
Changes to the Engineering Laws (`laws/engineering-laws.md`), Editorial Principles (`reference/editorial-principles.md`), or Document Status Lifecycle (OE-0000) require an additional constraint:
|
|
|
|
1. The proposed change must survive the standard editorial gate (see `reference/editorial-principles.md`).
|
|
2. The proposed change must not reduce the precision of an existing law or principle.
|
|
3. The proposed change must be reviewed by at least two independent reviewers who were not involved in drafting it.
|
|
4. The proposed change must not contradict any Accepted-status document.
|
|
|
|
This two-tier process ensures that governance changes receive higher scrutiny than technical content changes, while remaining within a single coherent framework rather than requiring a separate constitutional document.
|
|
|
|
## Spiral Re-evaluation as Amendment
|
|
|
|
Amendment is not linear. It is spiral. The standard will return to earlier concepts with deeper understanding, refining and extending them without contradicting the reality basis they rest on. Each spiral pass either eliminates ambiguity or strengthens traceability.
|
|
|
|
## The Bedrock Phase
|
|
|
|
The current phase of the Open Engineer standard is The Bedrock Phase. Every sentence accepted during this phase is intended to support everything built above it. If this phase is executed carefully, downstream implementations — presentation layers, interchange formats, context record tooling — will not require new concepts. They will express what already exists in the specification.
|
|
|
|
The specification leads. Everything else follows.
|
|
|
|
## Applicable Laws
|
|
|
|
This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`. |