KB-72F3

T1 FIX7 Design Verification - 02 Zero Hardcode (SUPERTRACK B)

5 min read Revision 1
QT001FIX7T1zero-hardcodesupertrack-b

02 — Zero Hardcode / Disguised Hardcode Review (SUPERTRACK B)

Verdict key: PASS = design intent is correct and concretely specified enough to verify; INTENT-OK / NEEDS_CLARIFICATION = direction correct but no concrete artifact to confirm (cannot be called PASS); FAIL = design recreates hardcode.

No "zero hardcode" claim can be made: most categories are NEEDS_CLARIFICATION because the concrete manifest/engine artifacts do not exist to inspect.

# Hardcode category Verdict Cite Correction needed if not PASS
1 Fixed collection lists NEEDS_CLARIFICATION design-plan 00/11 ("required sets … are manifest rows") Codex must publish the collection/required-set manifest schema + a worked example showing the set is data, not literal, and how the denominator is sealed.
2 Fixed gate counts not sealed in manifest NEEDS_CLARIFICATION 00 ("required sets … SHA-256 exact-set manifest rows") Specify the gate-set manifest: rows, the SHA-256 seal coverage, and the count-derivation (must be count(manifest) not a literal).
3 CASE policy in functions INTENT-OK 11 ("no … code branches on gate, tier, capability … identity"); 10 ("generic typed fact/policy interpreter") Publish the interpreter contract: operator-primitive set, typed-fact adapter signatures, and ≥1 policy row example. Confirm no tier/gate name appears in any authoritative function body.
4 Metadata-ID CASE/list INTENT-OK 00 ("Policy is never embedded as tier/gate/capability-specific CASE logic") Same as #3 — needs the concrete engine to verify no metadata-ID literal survives.
5 Regex / source-text authority NEEDS_CLARIFICATION 10 ("analyzer contract"), index (FIX6 demoted regex to diagnostic) Confirm in design that no authoritative guard derives from regex/source-text; specify how the analyzer output (if static-text-based) is sealed so it is not runtime source-scan authority.
6 Manual inventory as authority INTENT-OK 02 ("Deterministic authority-scope closure replaces manual inventory") Specify the closure algorithm + its inputs (catalog/ACL), and prove it is not a hand-maintained list.
7 Function/view existence as proof INTENT-OK 11/10 (capability = behavioral+operational evidence, not existence) Define the behavioral test + operational-evidence schema (see doc 07).
8 Arbitrary strings as principal/evidence/provenance INTENT-OK 10 ("manifest/FK principal/action/tier contracts", "content-addressed evidence") Publish FK principal/action/tier tables + content-address scheme (see doc 06).
9 MD5 / delimiter hash INTENT-OK 00 ("SHA-256"), checkpoints ("sealed SHA-256") Confirm no MD5/concat anywhere; resolve the extension-availability question (doc 08).
10 Runtime rows defining their own denominator NEEDS_CLARIFICATION 02 ("Sealed manifests are append-only"; runtime roles zero DML) Specify that the denominator comes from a sealed manifest the runtime role cannot write, and that activation (quorum) is the only path to change it (doc 05).
11 Literal PASS/FAIL shortcuts INTENT-OK 10 ("no caller PASS") Confirm in the engine spec that callers cannot pass a literal verdict; verdict must be computed from sealed policy.
12 bool_and NULL-ignore NEEDS_CLARIFICATION index (FIX6 readiness "count-match not bool_and", NULL=FAIL) FIX7 readiness spec must restate NULL-strict count-match semantics explicitly; not yet written for FIX7.
13 "Routed later" without blocking now PASS 09/11/14 (apply BLOCKED; authority_cutover_complete=false; readiness stays red until cutover+evidence) None — deferral is paired with a present-tense block, not a fake green. Confirmed live: signoff_plan_binding=0, cap evidence=0 → BLOCKED now.

Summary

  • PASS: 1/13 (#13 routed-with-block).
  • INTENT-OK (correct direction, unverifiable without concrete spec): 7/13 (#3,4,6,7,8,9,11).
  • NEEDS_CLARIFICATION: 5/13 (#1,2,5,10,12).
  • FAIL: 0/13 — no category shows the design recreating hardcode; the gap is missing concreteness, not a detected hardcode.

Conclusion: "Zero hardcode" is not yet demonstrable. The design intends zero hardcode and no category is observably violated, but 12/13 categories cannot be confirmed PASS until Codex publishes the manifest schemas and interpreter contracts. This is a block on evidence, not a finding of hardcode.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-design-deep-verification-before-implementation-2026-06-07/02-zero-hardcode-review.md