02 — Supertrack B: RP-01 runtime-evidence non-authority review

Verdict: RP01_NEEDS_PROPOSAL (table layer resolved; hash-binding precision drives P-01/P-02/P-03).

What Codex delivered (doc 02, rev 2)

Eleven byte-level physical tables in qt001_cp: signoff_binding, capability_run, capability_measurement, capability_artifact, gate_fact_result, bypass_vector_fact_result, quorum_vote, denied_attempt_evidence, dashboard_export, level_b_packet_execution, post_activation_verifier_state. Typed domains (sha256, positive_bigint, nonnegative_bigint, nonempty_text); every FK ON UPDATE RESTRICT ON DELETE RESTRICT NOT DEFERRABLE; seven high-volume event tables range-partitioned on immutable event time; four identity anchors unpartitioned. evaluated_pass/evaluated_blocked accepted only from owner generic guards.

Checklist

Criterion	Result	Note
runtime-evidence physical tables = 11	✅	7 partitioned + 4 anchors = 11
non-authority	✅	facts/evidence only; data never defines policy
owner-only / append-only / hash-bound / exact-set	✅	owner qt001_cp_owner; append-only after finalization + immutable-trigger setup (order step 9); exact set via #20 rows
not counted as authority surfaces	✅	count stays 27 (see Supertrack J)
12→11 discrepancy resolved	✅	capability_environment explicitly folded into capability_run.environment_sha256 + environment_evidence_id — not silently dropped (T1's RP-01 §5 permitted folding "Decide explicitly"; Codex decided)
H04/H05/H02 payload keys bind to named table.columns	⚠️ PARTIAL	table-level mapping present + CP-06 doc 07 "Runtime-Evidence Column Bindings" added; but see gaps below
capability_environment decision clear	✅	folded, stated in both doc 02 and CP-08 doc 09
Directus cannot use as authority	✅	Directus/PUBLIC inaccessible; not business base tables
retention applies coherently	✅	each high-volume row binds storage_class_item_id; partition cadence from sealed storage-class row (RP-02)
rollback exists	✅	append-only; new version; reversal drops empty candidate-only tables per RP-03 order

The three binding gaps (verified against the byte-level DDL)

H05 and H02 table-level bindings are correct and consistent (run/measurements/artifacts → the three capability tables; environment folded; H02 consumes the named runtime rows). The gaps are precision defects that block "byte-implementable without guessing":

G1 (→ P-01, contradiction). CP-06 doc 07 says: "H04 target_id = signoff_binding.target_manifest_id; all remaining H04 keys map one-to-one to named signoff_binding columns." False for two keys: reviewer_evidence_hash and binding_evidence_hash are SHA-256 hashes, but the columns are reviewer_evidence_id / binding_evidence_id (uuid FKs to evidence_registry). The hash must be dereferenced: = evidence_registry.artifact_sha256 (the unique content-hash column, confirmed in CP-08 doc 09) via the stored evidence_id. 13/15 H04 keys resolve one-to-one; these 2 do not.

G2 (→ P-02). signoff_binding.scope_hash is both an H04 payload key and the basis for excluding slot metadata from H04 ("…only if scope_hash canonically includes quorum profile, principal class, slot ordinal, and action"). Its canonical composition is asserted as a condition, never pinned. H04 can read the stored value, but the write path (control-plane computing scope_hash) is non-deterministic without the key list, and H04's slot-exclusion + RP-06's slot-binding are only safe if scope_hash provably includes the slot. Pin scope_hash's ordered key list.

G3 (→ P-03). The CP-06 "Total Orders" section enumerates 6 orders but omits the new runtime aggregates: H05 measurements (capability_measurement), H05 artifacts (capability_artifact), H02 capability_evidence_hashes (over capability_run), and H02 post_activation_verifier_state. The general rule ("every jsonb_agg has an explicit total unique ORDER BY ending in immutable UUID/item ID") guarantees a total order exists but not which one; distinct valid orders yield distinct digests. (Note: H02 signoff_binding_hashes IS covered — the signoff total order (target_id,tier_id NULLS FIRST,action_id,reviewer_principal_id,signoff_id) is pinned.)

Why these matter (not nitpicks)

RP-01 was raised because runtime instance tables behind H04/H05/H06 were never byte-defined → "hash not byte-implementable → reopens divergence loop." Codex closed the table half. G1–G3 are the remaining slivers of that same loop: an implementer and a verifier who resolve the evidence-hash source, scope_hash composition, or aggregate order differently will compute different digests — exactly the divergence RP-01 set out to eliminate. All three are confined to CP-06 doc 07 and add no surface/gate/hash/table.

Cross-checks that PASS

• H04 already includes reviewer_human_identity_id / binder_human_identity_id as keys → bound identities are hashed (supports RP-06).
• capability_environment fold matches CP-08 doc 09 "Exact Runtime-Evidence Category" (11 tables).
• Partition set (7) and anchor set (4) are internally consistent and match CP-08 doc 09.
• No caller-authored PASS: evaluated_pass/evaluated_blocked owner-guard-only.