Architecture decision records preserve cross-cutting choices whose rationale would otherwise be lost as the implementation changes. Each record states its status. Acceptance records an architectural decision; it does not promise a stable public contract.
| ADR | Decision | Status |
|---|---|---|
| 0001 | Use a Python-first control plane | Accepted |
| 0002 | Seal plugin packages and registry snapshots | Accepted, pre-stable |
| 0003 | Use SQLite acceptance with immutable search checkpoints | Accepted, pre-stable |
| 0004 | Verify parameter regions through immutable subjects | Accepted, pre-stable |
| 0005 | Keep epistemic workspaces separate from capability assurance | Accepted, pre-stable |
| 0006 | Isolate tests by semantic depth and resource ownership | Accepted, pre-stable |
| 0008 | Package every executable benchmark case in claim-specific Harbor datasets | Accepted, pre-stable |
| 0009 | Keep LRAT replay experimental and addition-only until an independent backend passes the authority gate | Accepted, pre-stable |
| 0010 | Keep formal inspection and intermediate representations domain-owned and bounded | Accepted |
Add an ADR when a decision changes a trust boundary, durable data model, cross-component contract, dependency strategy, or other choice that would be costly to reverse. Routine implementation details belong in code, tests, or a how-to guide.
When a decision changes, preserve the old record and add a new ADR that marks the earlier one as superseded. Do not silently rewrite an accepted decision to describe a different architecture.
Related project-control documents: