Incomex AI Portal
KB-2C6B

Supertrack N — Proposal Package (P-01..P-04)

8 min read Revision 1
fix7architecturet1-reviewproposal-packagesupertrack-n

14 — Supertrack N: proposal package

Four proposals. P-01..P-03 are blocking-for-final-approval and surgical (all inside CP-06 hash doc …/codex-fix7-spec-artifact-correction-from-t1-proposals-2026-06-07/07-cp06-canonical-hash-encoding-order-numeric.md). P-04 is advisory (RP-03 doc). None introduces a new authority surface, gate, hash contract, or runtime table. T1 supplies the unambiguous values found during review so the next Codex cycle is fast. T1 does not edit Codex docs.

P-01 — Pin H04 evidence-hash keys to the named source column (fix internal contradiction)

  • Severity: LOW (blocking-for-final-approval; one-line correctness fix)
  • Affected docs: CP-06 doc 07 ("Runtime-Evidence Column Bindings"); cross-check CP-08 doc 09.
  • Affected layer: H04 incomex.qt001.signoff-binding.v1 payload binding.
  • Current issue (contradiction): doc 07 states "all remaining H04 keys map one-to-one to named signoff_binding columns," but reviewer_evidence_hash and binding_evidence_hash are SHA-256 values while the columns are reviewer_evidence_id / binding_evidence_id (uuid FKs). There is no signoff_binding.*_evidence_hash column. As written, an implementer could hash the UUID instead of the evidence content.
  • Proposed correction: state the dereference explicitly — reviewer_evidence_hash = evidence_registry.artifact_sha256 where evidence_registry.evidence_id = signoff_binding.reviewer_evidence_id; likewise binding_evidence_hash via binding_evidence_id. (artifact_sha256 is the unique content-hash column on evidence_registry, confirmed in CP-08 doc 09 — so the source is unambiguous.)
  • Why needed: "every H04 sub-payload key resolves to a named table.column" is the explicit acceptance gate; 2/15 keys currently do not, and the doc's claim about them is false.
  • How Codex should verify: for every H04 key, assert a resolvable table.column (with the evidence keys resolving through the FK to evidence_registry.artifact_sha256); recompute H04 on a fixture and confirm a change to the referenced evidence's artifact_sha256 changes the digest.
  • Blocks final approval: YES.

P-02 — Pin signoff_binding.scope_hash canonical composition

  • Severity: MEDIUM (blocking-for-final-approval)
  • Affected docs: CP-06 doc 07 (add scope_hash composition to Total Orders / a "scope_hash" note); ties to RP-06 doc 03 and CP-09 doc 10.
  • Affected layer: signoff write path determinism; H04 slot-key exclusion; RP-06 slot hash-binding.
  • Current issue: doc 07 says H04 may omit slot metadata "only if scope_hash canonically includes quorum profile, principal class, slot ordinal, and action" — a condition, never a pinned definition. The control plane cannot compute scope_hash deterministically, and H04's slot-exclusion + RP-06's slot-binding are asserted, not demonstrated.
  • Proposed correction: define scope_hash as a canonical SHA-256 over an explicit ordered key list — minimally {quorum_profile_id, required_principal_class_id, slot_ordinal, action_id}, and state explicitly whether target_id/plan_content_hash are included — under the same CP-06 encoding rules; OR, if simpler, add the four slot keys directly to the H04 published key list and drop the conditional. Either makes the slot provably hash-bound.
  • Why needed: determinism of the signoff write path and a real (not asserted) slot-binding that closes the same-human/slot bypass RP-06 targets.
  • How Codex should verify: recompute scope_hash on a fixture; confirm changing slot_ordinal / principal class / action / quorum profile changes scope_hash (and thus H04); confirm two independent builds produce identical scope_hash.
  • Blocks final approval: YES.

P-03 — Enumerate total orders for the new runtime aggregates

  • Severity: MEDIUM (blocking-for-final-approval)
  • Affected docs: CP-06 doc 07, "Total Orders" section.
  • Affected layer: H05 measurements, H05 artifacts; H02 capability_evidence_hashes, H02 post_activation_verifier_state.
  • Current issue: the section enumerates 6 total orders (incl. signoffs) but omits these four newly-bound runtime aggregates. The general rule ("every jsonb_agg has an explicit total unique ORDER BY ending in immutable UUID/item ID") guarantees a total order exists, not which one; two implementations choosing different valid orders compute different digests — the determinism loop RP-01 set out to close.
  • Proposed correction: add one pinned canonical order per aggregate, each ending in the row's immutable PK, e.g.:
    • capability_measurement (H05 measurements): (measurement_requirement_id, measured_at, measurement_id)
    • capability_artifact (H05 artifacts): (artifact_requirement_id, created_at, capability_artifact_id)
    • capability_run (H02 capability_evidence_hashes): (capability_id, finalized_at NULLS LAST, run_id)
    • post_activation_verifier_state (H02): (activation_id, verifier_principal_id, verifier_state_id) (Codex owns the exact tuples; the requirement is that each is a pinned, total, unique order under COLLATE "C".) Also confirm the membership predicate (which rows belong to each aggregate) is pinned — e.g., measurements/artifacts scoped to their run_id, control-state sets scoped to the active control_epoch.
  • Why needed: deterministic, reproducible H05/H02 digests across implementer and verifier.
  • How Codex should verify: CP-06 determinism fixture — reorder rows on input, confirm the digest is unchanged for each of the four aggregates.
  • Blocks final approval: YES.

P-04 — State benign-extra-constraint disposition in RP-03 expected-constraint check (ADVISORY)

  • Severity: ADVISORY (does not block final approval)
  • Affected docs: RP-03 doc 06; #20 verification logic.
  • Affected layer: OBJECT_AUTHORITY_IMMUTABLE both-EXCEPT constraint comparison.
  • Current issue: doc 06 fails on missing/extra/changed authority-relevant constraints but is silent on an extra benign non-authority index on a control-plane table, and does not define which classes are "authority-relevant." T1's RP-03 refinement left this to Codex's choice with default FAIL.
  • Proposed correction: state explicitly (a) the authority-relevant constraint classes (PK/UNIQUE/FK/CHECK) and (b) the disposition of an extra benign index — fail-closed, or explicit operator-quarantine — so there is no definitional gap.
  • Why needed: removes a small fail-closed ambiguity; keeps the constraint contract total.
  • How Codex should verify: rehearsal — add a benign non-unique index to a control-plane table; confirm the specified disposition (FAIL or quarantine) actually fires.
  • Blocks final approval: NO.

Summary

  • Blocking-for-final-approval: P-01, P-02, P-03 (all CP-06 doc 07; no new surface/gate/hash/table).
  • Advisory: P-04 (RP-03 doc 06).
  • After Codex applies P-01..P-03, T1's short re-review confirms H04/H05/H02 byte-implementability → DESIGN_READY_FOR_CODEX_FINAL_APPROVAL.
Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-rp-corrected-design-short-review-2026-06-07/14-proposal-package-if-any.md