Reality Boundary
Claim matrix for what is implemented, demonstrated, benchmarked, auditable, private, or not public.
Open Architecture Note
The Decision Record Model
A decision is not a disposable output. It is a structured record bound to evidence, policy, provenance, lifecycle, reviewability, regulatory context, and audit packaging.
This page describes the architectural identity of a decision record. Operational scope is verified per deployment.
Decision Records as Durable Objects
OmegaOS does not treat a decision as a log entry. Each decision is a record. Each record retains the inputs that produced it, the rules that evaluated them, and the context in which the evaluation occurred.
A record stays bound to its evidence set and policy version. It carries a lifecycle. It can be reviewed. It composes into a packaged audit surface. These properties are not features added on top of a decision — they define what a decision is in this architecture.
Surface Boundaries
Evidence + Policy state origin genealogy contestability regulatory horizon proof envelope Audit Pack
Attributes of the Decision Record
Six attributes define the record as an object. Each attribute is described below at the level of the model. Operational behaviour for each attribute is verified per deployment.
State
- Definition: A decision record carries a lifecycle state: active, requires revalidation, expired, superseded, revoked, or invalidated. The state is computed at read time from the record’s history. It is not stored on the record itself.
- What the model requires: Correctness at birth (the record’s evaluation result) and consumability at read time (the record’s current state) are architecturally separated. A record that was correct when produced may still require revalidation if its policy or evidence horizon shifts.
- Verified per deployment: Lifecycle semantics, revalidation surfaces, and read-time state handling are defined for each deployment scope.
Origin
- Definition: A record binds to its evidence set, its policy version, and the execution context under which it was produced. Evidence is content-addressed; the policy version is locked at evaluation time.
- What the model requires: Evidence and policy version are immutable inputs to the record. A record cannot be detached from the inputs that produced it.
- Verified per deployment: The completeness of origin metadata and exported record context is defined for each deployment scope.
Genealogy
- Definition: A record references its predecessors when superseded. The lineage composes record, evidence, policy, and supersession nodes.
- What the model requires: Provenance is recorded, not inferred. Each link in the chain is independently addressable.
- Verified per deployment: Lineage traversal surfaces, predecessor references, and reconstruction views are defined for each deployment scope.
Contestability
- Definition: A record remains challengeable. Its evidence set and policy version are retained. Its lineage is auditable.
- What the model requires: The right to review and to contest a record is a property of the model. The record does not expire as a basis for review even after its operational state changes.
- Verified per deployment: Review surfaces, retained references, and historical comparison views are defined for each deployment scope.
Regulatory Horizon
- Definition: A record carries its regulatory context: the frameworks evaluated and the obligations referenced. When enabled, monitoring and incident surfaces can use records to support drift review and incident classification workflows.
- What the model requires: Compliance is a runtime property derived from records, not a static checklist. The record knows the frameworks under which it was evaluated.
- Verified per deployment: Monitoring thresholds, incident workflows, and regulatory mappings are defined for each deployment scope.
Proof Envelope
- Definition: A record and its evidence are content-addressed. The audit-pack surface composes record, lineage, explanation, monitoring, compliance, and incident views.
- What the model requires: Each component of the envelope is independently identifiable. The audit pack is the packaging surface — it does not replace any of the underlying records.
- Verified per deployment: Export, packaging, and integrity surfaces are defined for each deployment scope. Private verification mechanisms are not described on this page.
Operational Scope
The model is a structural identity. Deployment-specific operational scope — including what is implemented, demonstrated, verified, or kept private — is described through the references below.
Verify Offline
Verification note for exported artefacts and offline integrity checks.
OpenPilot Scope
Bounded deployment review with prerequisites, deliverables, and exit conditions.
OpenTechnical Artifact
Canonical definitions for OmegaOS, OmegaOS Kernel, terminal states, evidence, replay, and ledger terms.
OpenBoundary Clause
This page describes a model. It does not assert that every attribute is operationally complete in every deployment.
Deployment-specific operational scope, exported artefacts, runbooks, topology notes, and integration procedures are not public. They are addressed through the engagement path: Pilot Scope, Verify Offline, and direct technical contact under review context.
Contact Engineering