64 lines
3.3 KiB
Markdown
Executable File
64 lines
3.3 KiB
Markdown
Executable File
# OE-0000: Charter
|
|
|
|
**Status:** Draft
|
|
**Phase:** The Bedrock Phase
|
|
**Version:** 0.2.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.
|
|
|
|
## 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 Basis
|
|
|
|
Compliance with Open Engineer means that an engineering context record contains the minimum required fields defined in OE-0003 (Engineering Context), follows the editorial principles defined in `reference/editorial-principles.md`, and respects the dependency integrity defined in OE-0011 (Evolution).
|
|
|
|
Detailed conformance testing criteria will be defined during the Implementation Phase.
|
|
|
|
## Dependency
|
|
|
|
This is the root document. All other specification documents extend from this charter. |