KB-F7B1

CP-08 Registry / Evidence Placement / Retention Review

4 min read Revision 1
fix7architecturet1-reviewcp08

08 - SUPERTRACK H — CP-08 Registry / Evidence Placement / Retention Review

Source reviewed: doc 09-cp08-registry-evidence-placement-retention.md (revision 2).

Verdict: CP08_ADVISORY_REMAINING (original advisory met; two cross-impact items in this domain — RP-01, RP-02 — are now BLOCKING)

Checklist evidence (original advisory satisfied)

  • Placement clear — VERIFIED. All authority/evidence registries live in qt001_cp, owner qt001_cp_owner NOLOGIN; Directus/PUBLIC no DML/DDL/ownership; append-only/superseded/revoked, no history delete.
  • Byte-level DDL for the load-bearing anchors — VERIFIED (important). evidence_registry and analyzer_run are published with explicit columns/PK/FK/CHECK. This matters because doc-02 core manifest_activation, manifest_set.created_by_principal_id, and manifest_item_envelope.retired_reason_evidence_id carry NOT NULL FKs into evidence_registry/principal_registry — so these are no longer merely advisory; they are core dependencies, and they are now defined, not prose.
  • Retention / sealed retention policy — VERIFIED as described (retention is an ACTIVE sealed policy manifest; never deletes authority/history needed for audit; archive copies heavy artifacts to immutable versioned object storage, readback+hash-verifies, then may detach PG bytes while retaining metadata/URI/SHA-256/size/lifecycle/supersession; failure to read archived evidence invalidates dependent proof).
  • Partitioning/index strategy reasonable — VERIFIED in shape (range-partition high-growth result/event/export tables by immutable created_at/finalized_at; identity/evidence/run ANCHORS unpartitioned; sensible active lookup indexes listed).
  • Evidence growth at scale considered — VERIFIED ("growth follows plans/runs, not business-object count"); consistent with my prior FEASIBILITY_SCALE_VERIFIED.
  • Advisory-vs-blocking status — Codex states advisory now, blocking before any retention action or when partitions exceed sealed capacity. Reasonable framing.

Blocking cross-impact in this domain

  • RP-01 (BLOCKING): doc 09 explicitly names the high-volume tables it partitions — "high-volume capability/gate/analyzer result events, denied-attempt evidence, dashboard exports, and Level-B packet executions" — and H04/H05/H06 hash their contents, yet NONE of these instance/result tables has a published CREATE TABLE. The package therefore specifies partitioning and hashing for tables it never defines. Define them byte-level (owner/seal/append-only/FK), or explicitly downscope under a mandatory re-audit rule binding their columns into the H-maps before any apply (CP-01 path-B pattern).
  • RP-02 (BLOCKING): the retention interval/capacity are "from the ACTIVE sealed retention policy," but no retention/storage-policy manifest is among the exactly-27, contradicting CP-05's "no 28th authority surface." State which sealed surface holds them, whether counted as an additional sealed surface or folded into an existing manifest, and ensure they are hash-included and exact-set sealed.

Conclusion

The registry/evidence PLACEMENT and retention/archival POLICY are adequately specified and the load-bearing anchors are now byte-defined. CP08_ADVISORY_REMAINING. The two blocking cross-impact items (RP-01 undefined instance/result tables; RP-02 retention-surface counting) are NOT failures of Codex's CP-08 response but are blocking-completeness gaps surfaced by the other corrections; they must close before final approval.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-corrected-spec-short-review-proposals-2026-06-07/08-cp08-retention-review.md