openengineer/spec/oe-0000-charter.md

OE-0000: Charter

Status: Draft Phase: The Bedrock Phase Version: 0.3.0-draft

Purpose

Open Engineer is an open standard for preserving engineering context.

Open Engineer does not seek to tell engineers what to think. It seeks to preserve how engineers arrive at understanding.

Domain of Applicability

This standard applies to any discipline in which practitioners make decisions under constraints, observe outcomes, and transmit the results of those decisions to subsequent practitioners. This includes but is not limited to:

• Civil, mechanical, electrical, chemical, and aerospace engineering
• Software and systems engineering
• Biomedical and environmental engineering
• Industrial design and manufacturing engineering

The standard does not require that all disciplines use identical methods. It requires that context preservation follow a common structural framework, regardless of discipline-specific content.

Nature of the Standard

Open Engineer is a standard.

Not a philosophy. Not a documentation system. Not a project. Not a presentation layer.

Philosophy, documentation systems, projects, and presentation layers become implementations. The standard comes first.

Scope

Open Engineer remains grounded in engineering while recognizing that valuable observations about decision-making and knowledge continuity have emerged from many domains throughout human history. It is open. It respects every discipline. It welcomes observations from every domain and every generation. It remains anchored to reality through observation, verification, and stewardship.

Governance Authority

The Engineering Laws (see laws/engineering-laws.md) govern all content in this standard. All editorial rules are defined in reference/editorial-principles.md. Specification documents may reference but must not duplicate them.

Amendment of governance content (Laws, Editorial Principles, Status Lifecycle) requires additional constraints beyond the standard change workflow. See OE-0011 (Amendment), section: Constitutional Governance.

Document Status Lifecycle

Status	Definition
Draft	Under active development. Content may change without formal process.
Proposed	Submitted for review. Content is stable pending review outcome.
RC (Release Candidate)	Reviewed and accepted. Frozen unless a subsequent RFC explicitly supcedes it.
Accepted	Part of the canonical standard. Changes require RFC.
Deprecated	Superseded by a later document. Retained for historical traceability.

Advancement from Draft to Proposed requires completion of the editorial gate defined in reference/editorial-principles.md. Advancement from Proposed to RC requires successful independent review. Advancement from RC to Accepted requires no outstanding objections.

Versioning

Each specification document carries an independent version number following the pattern MAJOR.MINOR.PATCH-status. The overall standard version is the highest version number of any Accepted document.

Conformance Criteria

A context record complies with Open Engineer when all of the following are true:

1. Field Completeness: All eight required fields (Decision, Observation, Alternatives, Constraints, Reasoning, Verification, Lineage, Assumptions) are present and populated.

2. Observation Traceability: The Observation field references at least one verifiable encounter with reality (direct or corroborated as defined in OE-0004).

3. Constraint Bounding: The Constraints field identifies at least one constraint that bounded the decision.

4. Verification Against Reality: The Verification field describes a test, measurement, or assessment against observable outcomes — not against a model or an opinion.

5. Lineage Traceability: The Lineage field either references at least one prior context record or explicitly states "no prior work" with rationale.

6. Assumption Awareness: The Assumptions field contains at least one assumption, even if the assumption is "no significant unknowns."

7. No Contradiction: The context record does not contradict any Accepted-status specification document.

A context record that satisfies all seven criteria is compliant. A record that satisfies criteria 1-6 but not 7 is compliant at the document level but may require resolution at the project level. Records that fail any of criteria 1-6 are non-compliant.

Testable Hypotheses

The standard is based on hypotheses that require empirical validation during the Implementation Phase. These are not asserted as proven; they are stated as testable predictions:

Hypothesis 1 (Context Preservation): Practitioners who receive an OE-compliant context record will require less time to reconstruct decision reasoning than practitioners who receive only the final artifact, as measured by controlled comparison.

Hypothesis 2 (Translation): Engineering principles derived through translation (extracting observations from any domain and converting to engineering language) will demonstrate equal or greater durability across technology changes than principles derived from a single domain.

Hypothesis 3 (Thread Integrity): A context record that passes all seven conformance criteria will enable a practitioner unfamiliar with the original decision to reconstruct the reasoning, as measured by the reconstruction test defined in OE-0001.

The standard does not require these hypotheses to be proven before use. It requires that they be testable and that the standard's adoption be evaluated against them.

Dependency

This is the root document. All other specification documents extend from this charter.