Future Contracts Queue — after Implementation Package DOT v0.1

Nature: the queue of deferred, execution-dependent contracts that sit behind the read/report-only v0.1. Each is carved out of v0.1 by the Authority Contract / Codex seal. For each: why it is deferred, what it would unlock, what must be proven before it may be opened, and whether Codex review is mandatory. This document opens none of them — it only queues them. Date: 2026-06-09 Production mutation: NO. No contract is opened, sealed, or implemented here. Governing authority: Authority Contract v0.1 §7 (unresolved/deferred), Codex seal BCDGH_SEALED, Gap-only Scope Spec §17.2. Ordering principle: nothing downstream may open until its prerequisites are proven; the Call Contract is the keystone — most execution capability is blocked on it.

---

1. Queue overview (dependency order)

v0.1 (read/report-only)  ──►  [1] Call Contract (keystone)
                                  ├─► [2] Proof-of-run semantics
                                  └─► (run-half of claim↔test binder, command-runner)
[3] system_issues write contract        (independent of Call Contract; needed for audit_dead_links sink)
[4] Directus DOT-control proof          (independent; gates any Directus write)
[5] TAC↔IU bridge/resolver contract     (owner+Codex; corpus authority)
[6] registry cleanup/reconciliation     (gated on Call Contract + owner)
[7] OPA/Conftest/Squawk/CI integration  (gated on a runnable verifier existing first)

---

2. Contract details

[1] Call Contract — keystone

• Why deferred: Codex B/C sealed v0.1 to make no calls; "can run" is NOT AVAILABLE for filesystem DOT. Nothing is callable until this exists.
• What it unlocks: the command-runner with exit codes (gap #8.1), the run/pass half of the claim↔test binder (gap #8.2), and ultimately a runnable verifier that closes the Article-14 class with proof, not just evidence-presence.
• Must be proven first (per-command): identity, permitted mode, inputs, exit-code semantics, timeout, lease/gate, audit ledger, and a non-mutation boundary. The 15 IU mutating=false commands are a candidate governed set — not yet authorized. No static whitelist, no new dispatcher.
• Codex review: MANDATORY (before any build).

[2] Proof-of-run semantics

• Why deferred: what counts as "can run" (presence + run-ledger record vs. an actual dry-run) is undefined; presence/exec-bit/historical dot_iu_command_run rows never prove current safe runnability.
• What it unlocks: the ability for the tool to upgrade EVIDENCE_PRESENT to a real run-verdict (ran_clean/ran_with_drift/error_running — the P11E vocabulary held in reference-only).
• Must be proven first: a defined, reproducible run-evidence model (exit code + log + determinism re-run) tied to the Call Contract's audit ledger; how dot_iu_command_run history may (or may not) be used as evidence.
• Codex review: MANDATORY (rides with / immediately after the Call Contract).

[3] system_issues write contract

• Why deferred: Domain F — the deployed fn_tac_log_checker_issue → system_issues is the only sink; a new logger is prohibited and v0.1 writes nothing. The audit_dead_links() persistent engine + sink (gap #8.5) is blocked here.
• What it unlocks: escalation of read/report findings into system_issues via the existing sink; the persistent dead-link engine.
• Must be proven first: the timing/approval for a v0.1 successor to mutate; that escalation routes only through fn_tac_log_checker_issue (no new sink); severity-map / md5-dedup / escalate semantics reused, not forked.
• Codex review: MANDATORY (it writes a production sink).

[4] Directus DOT-control proof contract

• Why deferred: Domain E — Directus 100%-DOT-control is PARTIAL_EVIDENCE_ONLY; no mutation path until proven. v0.1 only observes flows read-only.
• What it unlocks: any future Directus write, routed only through existing [DOT-REG] sync / [WATCHDOG] flows.
• Must be proven first: that 100% of the relevant Directus estate is DOT-controlled (not PARTIAL); that writes can route through existing flows without a new CRUD path.
• Codex review: MANDATORY if any write path is proposed.

[5] TAC↔IU bridge / resolver contract

• Why deferred: Domain H — 0 joining views/functions exist; corpus authority is unresolved by design. v0.1 dual-reports only and cannot choose/merge/bridge.
• What it unlocks: a sanctioned relationship between information_unit (219) and tac_logical_unit (102) — a bridge, a canonical choice, or a resolver.
• Must be proven first: an owner decree of corpus authority + a Codex-reviewed bridge/resolver design; runtime-read evidence (never hardcoded counts or a hardcoded "no bridge").
• Codex review: MANDATORY + owner authorization (two gates).

[6] Registry cleanup / reconciliation mutation contract

• Why deferred: Domain D — reconciliation is read-only reporting only; unmatched entries are NON-CALLABLE; no rebirth/cleanup. No new registry authority; dot_tools is not forked.
• What it unlocks: rebirth/cleanup of registry-no-file / file-no-registry entries; reconciliation actions beyond reporting.
• Must be proven first: the Call Contract (callability of any entry) + an owner decision on cleanup policy; that any action reuses existing reconciliation surfaces, not a new reconciler.
• Codex review: MANDATORY (mutates the registry/reconciliation surface).

[7] OPA / Conftest / Squawk / CI / Git-hook integration contract

• Why deferred: outside the v0.1 envelope (Gap-only Spec §16.14); these are gating/enforcement mechanisms that presuppose a runnable verifier exists.
• What it unlocks: wiring the verifier into CI / policy gates / pre-commit so the Article-14 check runs automatically on change.
• Must be proven first: a runnable verifier exists (post-Call-Contract) and its run-evidence/exit semantics are stable; the integration adds no new authority and routes findings only through the approved sink.
• Codex review: MANDATORY (it makes the verifier load-bearing in delivery).

---

3. Standing rule for every queued contract

• Each is opened only by explicit owner/operator/authority action, not inferred from progress.
• Each must be runtime-PG-native and fail-closed, never a hardcoded list or a collapsed count.
• None may create a parallel runner/registry/logger/graph/corpus authority (the five NOs stand).
• Until opened, the corresponding capability stays not built and not invoked.

---

Cross-references

• Authority Contract: contracts/authority-contract-v0-1-2026-06-09.{md,json} (§7 unresolved/deferred)
• Codex seal: reviews/codex-seal-authority-matrix-bcdgh-2026-06-09.md (BCDGH_SEALED)
• Gap-only Scope Spec: designs/implementation-package-dot-v0-1-gap-only-scope-spec-2026-06-09.md (§17.2 carve-outs)
• Action-ready blockers: checkpoints/action-ready-blockers-after-gap-only-spec-2026-06-09.md