69 lines
3.8 KiB
Markdown
Executable File
69 lines
3.8 KiB
Markdown
Executable File
# OE-0003: Engineering Context
|
|
|
|
**Status:** Draft
|
|
**Version:** 0.2.0-draft
|
|
**Depends on:** OE-0002 (Core Vocabulary)
|
|
**Phase:** The Bedrock Phase
|
|
|
|
## Overview
|
|
|
|
Open Engineer is an open standard for preserving engineering context.
|
|
|
|
Everything else in the standard extends from that purpose.
|
|
|
|
## Definition
|
|
|
|
Engineering context is the structured record of the reasoning behind an engineering decision. A complete context record enables a subsequent practitioner to reconstruct why a decision was made, what alternatives were considered, what constraints applied, and how the outcome was confirmed.
|
|
|
|
Context is not background information. It is the decision-shaped record of an engineering process. Without context, a decision is an isolated artifact — its output may be visible but its reasoning is inaccessible.
|
|
|
|
## Minimum Context Record Structure
|
|
|
|
Every engineering context record must contain the following fields:
|
|
|
|
| Field | Description | Required |
|
|
|---|---|---|
|
|
| **Decision** | What was decided | Yes |
|
|
| **Observation** | What was observed that prompted the decision | Yes |
|
|
| **Alternatives** | What options were considered, including rejected options | Yes |
|
|
| **Constraints** | What bounded the choice (technical, environmental, temporal, economic) | Yes |
|
|
| **Reasoning** | Why this option was selected over the alternatives | Yes |
|
|
| **Verification** | How the outcome was confirmed against reality | Yes |
|
|
| **Lineage** | What prior work this decision builds on | Yes |
|
|
| **Assumptions** | What was assumed, both explicit and implicit | Yes |
|
|
|
|
### Supplementary Fields
|
|
|
|
Context records may additionally include:
|
|
|
|
| Field | Description |
|
|
|---|---|
|
|
| **Open Questions** | What remains unknown or uncertain |
|
|
| **Discipline-Specific Data** | Measurements, calculations, test results relevant to the specific engineering domain |
|
|
| **Traceability** | Links to related context records, specifications, or requirements |
|
|
|
|
### Completeness
|
|
|
|
A context record is complete when all required fields are populated with sufficient detail that a practitioner unfamiliar with the original decision can reconstruct the reasoning. Sufficiency of detail is judged by whether the record passes the thread integrity test defined in OE-0001: can the reader explain why the decision was made without consulting the original decision-maker?
|
|
|
|
## Why Context Matters
|
|
|
|
When context is lost, practitioners must re-derive understanding from first principles. Re-derivation is costly in engineering time and introduces risk when the re-derivation produces different conclusions than the original reasoning.
|
|
|
|
When context is preserved, subsequent practitioners begin where their predecessors left off, building on verified understanding rather than restarting from first principles. This is the function of the thread made concrete.
|
|
|
|
## Context as the Unit of Preservation
|
|
|
|
If Open Engineer has a unit of measurement, it is the context record — a structured, self-contained record of engineering reasoning.
|
|
|
|
Every other element of the standard serves the goal of capturing, structuring, preserving, and transmitting engineering context.
|
|
|
|
## Known Limitations
|
|
|
|
This standard addresses explicit, articulable context. Much engineering knowledge is tacit — embodied in practice, judgment, and experience. Tacit knowledge cannot be fully captured in a structured record. The standard acknowledges this limitation and aims to preserve the explicit portion as completely as possible, recognizing that it captures the articulable fraction of engineering understanding.
|
|
|
|
Some engineering context is proprietary, classified, or legally restricted. The standard defines the structure of context records but does not define access control mechanisms. Implementations must address confidentiality, security, and access control as required by their domain.
|
|
|
|
## Applicable Laws
|
|
|
|
This document is governed by all Engineering Laws defined in `laws/engineering-laws.md`. |