Architecture acceptance matrix — invariant, test, evidence, and backend traceability #837

New Issue

2026-07-22T19:51:24-05:00

jcwalker3 commented

2026-07-22 19:51:24 -05:00

Candidate architecture requiring executable validation; not yet approved, production-ready, or certified.

Parent: #820. Depends on: #821–#836 (every ARCH-01/02/04 epic and leaf).

1. Summary / objective

Maintain a single acceptance matrix mapping every normative invariant across ARCH-01, ARCH-02, and ARCH-04 to a numbered acceptance criterion, a named test, an enforcement layer, an audit event, required evidence, and backend coverage. This is the program's completeness proof.

2. Problem

Distributed across 16 issues, invariants can silently lose test coverage or enforcement-layer accuracy. The matrix is the durable, auditable index that a fresh author or reviewer uses to confirm nothing is unproven.

3. Required columns (per invariant row)

Issue · numbered AC · unique test name · initial state · exact operation or raw-write bypass · expected structured result · expected committed state · backend coverage (SQLite/PostgreSQL) · enforcement layer ([SCHEMA]/[TRUSTED-SERVICE]/[RUNTIME-ADAPTER]) · required evidence + audit event.

4. Mandatory coverage (must appear as rows)

Installation + rollback; dominance-set finalization (#822).
Actor-context leakage/spoofing (#822, #827).
Platform-grant concurrency, expiry, suspension (#823).
Cross-class principal conflicts (#824).
Typed-subject exclusivity + digest binding (#825).
Issuer-proof replay + store generation (#826).
PostgreSQL role/privilege/pool posture (#827).
Transport authority + external bindings (#829).
Ref byte behavior + prohibited classes (#830).
Authorized lookup / cross-project disclosure / direct SELECT (#831).
Global-object authority + isolation proofs (#833).
Workspace initial generation; current-evidence NULL/composite-key behavior (#834).
External drift; probe/finalization race (#835).
Domain lifecycle + dependent fencing; global-object retirement (#836).
Required audit events (all).
SQLite- and PostgreSQL-specific expected failures where mechanisms differ.

5. Enforcement classification rule

Each row's enforcement layer must match the implementation, not the aspiration. A [SCHEMA] claim requires a passing raw-write bypass test; a [TRUSTED-SERVICE] claim requires a service-boundary test; a [RUNTIME-ADAPTER] claim requires an adapter test (altered/replay/unavailable). A row with no passing test is marked UNPROVEN.

6. Acceptance criteria

Every normative invariant in #822–#836 has a matrix row.
Every row has a named, existing test and a recorded pass/fail.
Every enforcement label is backed by the matching test class.
Backend coverage is explicit; SQLite pass does not imply PostgreSQL.
No invariant is UNPROVEN at program completion.
The matrix is regenerated/validated in CI so drift is caught.

7. Required tests

t_matrix_completeness (every invariant referenced by #822–#836 appears), t_matrix_enforcement_backed (each label has its test class), t_matrix_no_unproven (gate at program completion).

8. Enforcement classification (this issue)

Matrix generation/validation is [TRUSTED-SERVICE] (a CI/tooling contract), reporting on [SCHEMA]/[TRUSTED-SERVICE]/[RUNTIME-ADAPTER] rows of the other issues.

9. Dependencies / parent

Parent #820; depends #821–#836.

10. Definition of done

Matrix exists, is CI-validated, and shows zero UNPROVEN rows before any component is proposed as a production security boundary.

11. Known limitations / deferred

The matrix reports coverage; it does not itself enforce runtime security. Enabling any component in production remains gated by its own readiness checks.

**Candidate architecture requiring executable validation; not yet approved, production-ready, or certified.** Parent: #820. Depends on: #821–#836 (every ARCH-01/02/04 epic and leaf). ## 1. Summary / objective Maintain a single acceptance matrix mapping **every normative invariant** across ARCH-01, ARCH-02, and ARCH-04 to a numbered acceptance criterion, a named test, an enforcement layer, an audit event, required evidence, and backend coverage. This is the program's completeness proof. ## 2. Problem Distributed across 16 issues, invariants can silently lose test coverage or enforcement-layer accuracy. The matrix is the durable, auditable index that a fresh author or reviewer uses to confirm nothing is unproven. ## 3. Required columns (per invariant row) Issue · numbered AC · unique test name · initial state · exact operation or raw-write bypass · expected structured result · expected committed state · backend coverage (SQLite/PostgreSQL) · enforcement layer (`[SCHEMA]`/`[TRUSTED-SERVICE]`/`[RUNTIME-ADAPTER]`) · required evidence + audit event. ## 4. Mandatory coverage (must appear as rows) - Installation + rollback; dominance-set finalization (#822). - Actor-context leakage/spoofing (#822, #827). - Platform-grant concurrency, expiry, suspension (#823). - Cross-class principal conflicts (#824). - Typed-subject exclusivity + digest binding (#825). - Issuer-proof replay + store generation (#826). - PostgreSQL role/privilege/pool posture (#827). - Transport authority + external bindings (#829). - Ref byte behavior + prohibited classes (#830). - Authorized lookup / cross-project disclosure / direct SELECT (#831). - Global-object authority + isolation proofs (#833). - Workspace initial generation; current-evidence NULL/composite-key behavior (#834). - External drift; probe/finalization race (#835). - Domain lifecycle + dependent fencing; global-object retirement (#836). - Required audit events (all). - SQLite- and PostgreSQL-specific expected failures where mechanisms differ. ## 5. Enforcement classification rule Each row's enforcement layer must match the implementation, not the aspiration. A `[SCHEMA]` claim requires a passing raw-write bypass test; a `[TRUSTED-SERVICE]` claim requires a service-boundary test; a `[RUNTIME-ADAPTER]` claim requires an adapter test (altered/replay/unavailable). A row with no passing test is marked UNPROVEN. ## 6. Acceptance criteria 1. Every normative invariant in #822–#836 has a matrix row. 2. Every row has a named, existing test and a recorded pass/fail. 3. Every enforcement label is backed by the matching test class. 4. Backend coverage is explicit; SQLite pass does not imply PostgreSQL. 5. No invariant is UNPROVEN at program completion. 6. The matrix is regenerated/validated in CI so drift is caught. ## 7. Required tests `t_matrix_completeness` (every invariant referenced by #822–#836 appears), `t_matrix_enforcement_backed` (each label has its test class), `t_matrix_no_unproven` (gate at program completion). ## 8. Enforcement classification (this issue) Matrix generation/validation is `[TRUSTED-SERVICE]` (a CI/tooling contract), reporting on `[SCHEMA]`/`[TRUSTED-SERVICE]`/`[RUNTIME-ADAPTER]` rows of the other issues. ## 9. Dependencies / parent Parent #820; depends #821–#836. ## 10. Definition of done Matrix exists, is CI-validated, and shows zero UNPROVEN rows before any component is proposed as a production security boundary. ## 11. Known limitations / deferred The matrix reports coverage; it does not itself enforce runtime security. Enabling any component in production remains gated by its own readiness checks.

jcwalker3 referenced this issue

2026-07-22 20:04:09 -05:00

Architecture program — role-delivery-reliability control plane #820

jcwalker3 referenced this issue

2026-07-22 20:04:46 -05:00

ARCH-01 — Authority, identity, evidence, and platform-bootstrap architecture #821

jcwalker3 referenced this issue

2026-07-22 20:12:12 -05:00

ARCH-02 — Canonical repository resources, transport identity, and authorized lookup #828

jcwalker3 referenced this issue

2026-07-22 20:12:52 -05:00

ARCH-04 — Workspace identity, verification, exclusion domains, and mutation safety #832