KB-6566

T1 FIX7 Design Verification - 12 T1 Implementation Boundary (SUPERTRACK L)

4 min read Revision 1
QT001FIX7T1implementation-boundarysupertrack-l

12 — T1 Implementation Boundary (SUPERTRACK L)

This boundary applies only after the design corrections in doc 14 are made by Codex. Until then, T1 implements nothing (status DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE).

L.1 What can T1 do in FIX7a without operator?

Author-mode / local-rehearsal only:

  • Author candidate manifest schemas, generic engine functions, control-epoch object, readiness/no-bypass/hash/capability engine SQL as files (e.g. /opt/incomex/docs/mcp-writes/...), not applied to production authority.
  • Rehearse BEGIN..ROLLBACK locally; author DOT visibility, tests, negative tests, rollback scripts.
  • Generate candidate DOT/migration packages and the Level-B pipeline definition.
  • Leave authority_cutover_complete=false; no repoint; no active seal.

L.2 What must remain operator-gated?

Role creation (qt001_cp_owner), ownership cutover (REASSIGN/ALTER OWNER), ACL/REVOKE from directus/PUBLIC, extension install (e.g. pgcrypto if needed), manifest activation (quorum), scheduler/scanner enable, writer repoint, FIX7b, FIX7c, and any live privileged deployment (Level-B pipeline run).

L.3 What must remain Codex-reviewed?

The corrected concrete design itself (doc 14 corrections); and a fresh independent Codex re-audit of FIX7a artifacts before any FIX7b cutover — consistent with the FIX..FIX6 discipline (every fix re-audited before the next layer).

L.4 What exact artifacts should T1 produce (post-correction)?

  1. Manifest DDL (policy/operator/measurement/principal/action/tier/hash/vector/gate) with seal columns.
  2. Generic typed interpreter functions + typed-fact adapters + operator primitives.
  3. control_epoch object + writer/activation lock protocol.
  4. Readiness engine (exact-set, NULL-strict count-match) + capability engine (behavioral+operational) + hash engine + no-bypass engine.
  5. Analyzer contract + manifest-bound dynamic-SQL OID-check.
  6. DOT visibility, positive/negative test suites, self-audit harness.
  7. Rollback scripts + Level-B migration package.
  8. A self-audit report + an independent adversarial read-only sub-check (the FIX6 discipline that worked).

L.5 What exact live mutations are forbidden?

No DDL/DML against production authority objects; no role/owner/grant/revoke; no manifest activation; no writer/repoint; no trigger/gateway change; no permit/apply; no Directus role change; no Stage 2.6B; no scheduler enable. (Identical to the macro's Forbidden list.)

L.6 What exact self-audit must T1 run before reporting?

The FIX6-proven discipline: run a Codex-style self-audit after building, before reporting; self-find and fix own defects in-macro; re-run; then run an independent adversarial read-only sub-agent that tries to refute every guard (NULL=FAIL, no tautology, no false-green, no caller-PASS, denominator not self-defined). Report self_audit_pass + the independent confirmation. No PASS without both.

L.7 What result should T1 report if owner/ACL is not applied?

PARTIAL, with readiness BLOCKED and authority_cutover_complete=false. Explicitly: FIX7a scaffolding live (if applied through the approved pipeline) but control-plane immutability NOT achieved because Directus still owns the tables; capability self-attestable; signoff spoofable; therefore apply, permit, REAL_RUN, Stage 2.6B all remain blocked. Never report PASS or green readiness while Directus owns the control plane.

Boundary verdict

The author-vs-activate boundary the design draws is correct and usable. T1 must not guess the missing concrete spec. Because that spec is missing today, the operative instruction is: do not implement FIX7a yet; require Codex to publish the concrete design (doc 14); then implement within this boundary.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-design-deep-verification-before-implementation-2026-06-07/12-t1-implementation-boundary.md