RP-02 Retention Authority Surface — Refinement
03 - SUPERTRACK C — RP-02 Retention Authority Surface (REFINED_BLOCKING)
Decision: host retention interval/capacity in an EXISTING counted surface (primary), with a counted-contract alternative documented
The corrected package's "ACTIVE sealed retention policy" interval/capacity is numeric authority that decides partition-maintenance behavior but lives in no counted surface — contradicting CP-05's "no uncounted 28th authority surface." Three placement options were evaluated:
- (i) inside an existing sealed contract — RECOMMENDED.
- (ii) a counted sealed runtime/retention policy contract — viable but changes the exact count.
- (iii) Level-B/operator policy outside readiness — only acceptable if the VALUES are still sealed (not adapter literals); maintenance is already Level-B operator-gated, but the values must not float.
Primary recommendation (option i): fields on storage_class_manifest (child 05)
Retention is a STORAGE-CLASS property. storage_class_manifest already exists, is one of the 27, is sealed/hash-bound, and is the FK target of evidence_registry.storage_class_item_id. Add per-storage-class sealed fields:
retention_interval_seconds qt001_cp.positive_bigint— partition interval / minimum retention.partition_capacity_rows qt001_cp.positive_bigint(or_bytes) — capacity threshold that flips maintenance to blocking.archive_required boolean,archive_storage_class_id uuid(FK to a storage class with immutable_versioned=true) — where archived bytes go.
The RP-01 high-volume category-(c) tables each bind a storage_class_item_id FK; their retention/partition behavior is then READ from the sealed storage_class row. Partition maintenance stays Level-B operator-gated, reading these sealed fields — never an adapter literal.
This keeps everything inside surface #05: no count change, no 28th surface, and the values are automatically sealed + hash-bound because storage_class_manifest rows already flow into manifest_set payload_sha256 → control hashes.
Alternative (option ii): explicit counted retention contract
If Codex prefers a dedicated retention_policy_manifest, then it becomes child #28 with FULL parity: owner-only, versioned, exact-set sealed, item/payload SHA-256, activation-quorum-bound, included in readiness/control hashes, exact-set seal both-EXCEPT. Every doc/claim asserting "exactly 27" must change to "exactly 28," and READINESS_MANIFEST_EXACT / the HASH_COMPONENT denominator update accordingly. This is acceptable but heavier; option (i) is preferred precisely because it avoids touching the "27" invariant.
Anti-hardcode explanation
Either path makes retention interval/capacity a SEALED manifest field, never an adapter/function/CHECK literal. The maintenance engine reads the sealed value; mutating it requires a new activation (quorum + epoch). This removes the mutable-denominator / disguised-hardcode vector while keeping maintenance operator-gated.
Cross-impact (required fields)
- Affected docs: 06 (CP-05 no-28th-surface invariant), 09 (retention/partition), 02 (storage_class_manifest #05 columns or new child 28), 11 (self-review items 3 & 8 reconciliation).
- Affected contracts/tables/manifests: storage_class_manifest #05 (primary) OR new #28; evidence_registry.storage_class_item_id; all RP-01 category-(c) high-volume tables (they bind storage_class).
- Affected hashes: storage_class item hash → manifest_set payload_sha256 → H01 plan_content (operator/policy manifest set) and H02 control_state (active_manifest_set). If option (ii): HASH_COMPONENT denominator/expected_item_count changes.
- Affected readiness gates: SCALE_SAFE (capacity threshold source), READINESS_MANIFEST_EXACT (exact-set seal), and (option ii only) the gate-count/denominator gates.
- Affected bypass vectors: a floating retention denominator would be a mutable-denominator bypass; sealing it closes that vector.
- Affected rollback path: retention change = new sealed version of storage_class (or retention) manifest; never an in-place edit; partition maintenance actions are evidence-bound and reversible per doc 09.
- Affected Directus/read path: none (storage_class is control-plane authority; Directus no access).
- Affected PG-native enforcement: positive_bigint domains; FK to immutable_versioned storage class for archive; values resolved from sealed rows by generic maintenance engine.
- Affected no-hardcode proof: removes the uncounted-authority-surface finding from supertrack J.
- Verification after Codex edits: retention interval/capacity appear as sealed fields on a counted surface; mutate them without new activation → partition-maintenance/readiness gate fails closed; "exactly N" count statement is consistent across all docs.