---
title: "Shipping Better MLPs Smarter—Research Paper"
description: "**MLP = Most Lovable Product** — the minimum product scope that maximises customer delight."
version: "9.3"
pubDate: 2026-07-08
updated_date: 2026-07-16
changelog: "v9.3 (2026-07-16; status & 23 conformance categories indexed 2026-10-23): Design proposal and formal model; empirical benefits unestablished."
author: "Michael Kozloff"
stage: "03-product"
article_type: "Research paper"
keywords: ["NBM4","Product Operations","03-product"]
canonicalPath: "/introduction/shipping-better-mlps-smarter-research-paper/"
---

> **Document Status & Epistemic Boundary (`v9.3` — Design Proposal, Not Empirically Validated)**:
>
> - **Status**: Architectural Design Proposal & Formal Specification (`Version 9.3`, created `2026-05-17`, published `2026-07-08`, updated `2026-07-16`).
> - **Validation State**: Formal invariants and repository-local checks are author-reported on a private reference substrate (`ship-mlp`). Broad empirical productivity and product-outcome benefits are **not yet established** via controlled external studies.
> - **Core Principle**: *"The AI proposes; the PM ratifies; the Compiler enforces."* AI agents may propose plans, but cannot invent tasks or mutate execution topology at run time.
> - **Conformance Matrix**: The 23 compiler/executor conformance and fail-closed rejection categories (`C-01`–`C-23`) are summarized in the table immediately following the Abstract below.

## Domain-Ordered Directed Graph Execution: Compile-Time Governance for Hypothesis-Aligned AI Execution

**MLP = Most Lovable Product** — the minimum product scope that maximises customer delight.

**Author:** Mikhail Kozlov (aka Michael Kozloff)

**Version:** 9.3

**Created Date:** May 17, 2026

**Publication Date:** July 08, 2026 \[updated to v9.3 on July 16, 2026\]

**Change History:** Appendix E summarizes the changes in this revision and the full version lineage since v1.

**License:** The author intends to submit this work under arXiv’s non-exclusive distribution license. Software artifacts, if released, will be licensed separately under Apache-2.0.

**Acknowledgements:** The author used generative-AI systems for adversarial review, argument stress-testing, and prose refinement. The author reviewed and verified the manuscript and is solely responsible for its content, claims, references, and errors.

* * *

## Abstract

AI-agent systems often let a model invent tasks, branches, and tool calls during execution. **Domain-Ordered Directed Graph Execution (DODGE)** (G-1) moves this freedom before execution: the AI may propose a plan, but only a compiler-attested, human-approved graph can run. *A tag such as (G-1) points to the numbered row in the Reader’s Guide and Glossary below where that term is defined; every term this Abstract uses before defining carries such a tag.*

DODGE uses a single **Intent-Plan-Compile-Execute (IPCE)** (G-5) cycle.

In the hypothesis-aligned profile formalized here, an executable **Intent** (G-5) must match a versioned, human-ratified hypothesis set (H\_set) (G-4) or carry an exact human-approved exception.

The **Planner** (G-8) chooses an allowed execution route and proposes standard tasks (G-61), typed artifacts, dependencies, activation conditions, and material-effect scope (G-58). *The Plan itself has no execution authority.*

The **Compiler** (G-12) validates it against a pinned policy bundle (G-22) containing domain schemas, population and relationship cardinalities, field-size bounds, predicate rules, triage evidence, and approval requirements, then emits a signed, content-addressed **Governed Graph Commit (GGC)** (G-14).

A graph-closed **Executor** (G-13) accepts only that GGC, cannot mutate its topology, rejects out-of-scope effects, and emits an **OutcomeBundle** (G-15) that records what happened without authorizing further action.

DODGE does not claim deterministic model output, unique planning, correct hypotheses, or product success. We state sufficient conditions for hypothesis-aligned admission, bounded legal topology space, commit topology invariance, replay-equivalent eligibility, compiler admissibility, and runtime output admission (G-49).

The primary instantiation applies DODGE to **New Business Modelling Framework (NBM4, nbm4.com)** (G-50) product-hypothesis work; a second appendix sketches Request for Changes (G-52) governance. Version 9.3 leaves this formal model unchanged and additionally documents three author-reported governance surfaces operating in the reference substrate — a prompt-intake gate (G-64) that fail-closed scores interpretation confidence before any tool action, a bounded planner rejection loop (G-66), and release-claim governance (G-67) that mechanically blocks unsupported conformance wording — together with the typed evidence ledgers (G-63, G-65) that record them. Earlier repository-local checks are author-reported only; v9.3 conformance and empirical benefits remain unestablished.

### Summary of the 23 DODGE Conformance & Fail-Closed Rejection Categories (`C-01`–`C-23`)

To make the verification boundary inspectable without requiring access to the private reference repository, the table below summarizes the 23 conformance categories across the **IPCE (`Intent → Plan → Compile → Execute`)** pipeline:

| Case ID | IPCE Phase | Conformance / Rejection Rule | Expected Compiler / Executor Outcome |
| :--- | :--- | :--- | :--- |
| **C-01** | Intake | Ambiguous prompt below confidence threshold (`G-64`) | Fail-closed; request human clarification before tool calls |
| **C-02** | Intent | Intent unaligned with active `H_set` (`G-4`, `G-6`) | Block admission unless human ratifies `H_set` amendment/exception |
| **C-03** | Intent | Expired or superseded hypothesis reference | Reject Intent; require current `H_set` version binding |
| **C-04** | Plan | Unregistered task or unknown artifact type (`G-61`) | Reject candidate plan (`G_proposed`); log planner violation |
| **C-05** | Plan | Cycle detected in proposed task graph | Reject non-DAG topology before human review |
| **C-06** | Plan | Undeclared material-effect scope (`G-58`) | Reject plan missing explicit file/network/tool effect bounds |
| **C-07** | Plan | Planner exceeds bounded retry budget (`G-66`) | Halt automatic replanning; escalate diagnostic receipt to human |
| **C-08** | Approval | Missing or mismatched human ratification signature | Refuse compilation (`G_candidate` cannot promote to `G_approved`) |
| **C-09** | Approval | Plan mutated after human approval digest | Invalidate approval; require fresh ratification on new digest |
| **C-10** | Compile | Artifact payload fails JSON Schema Draft 2020-12 contract | Fail compilation; emit schema path diagnostic |
| **C-11** | Compile | Cardinality or field-size bound exceeded (`G-22`) | Fail compilation; enforce policy bundle limits |
| **C-12** | Compile | Missing upstream `authority_refs` lineage | Fail compilation; block orphan artifact creation |
| **C-13** | Compile | Non-canonical JSON serialization (`ship-mlp-c14n-json`) | Normalize or reject non-RFC 8785 digest input |
| **C-14** | Compile | Validated `G_approved` + policy bundle + authority proof | Emit signed, content-addressed `Governed Graph Commit (GGC)` (`G-14`) |
| **C-15** | Execute | Unsigned or tampered `GGC` digest presented to Executor | Refuse execution immediately (`G-13`) |
| **C-16** | Execute | Runtime attempt to add task, branch, or tool call | Block dynamic topology mutation; abort execution |
| **C-17** | Execute | Tool call targets path/host outside committed effect scope | Block out-of-scope effect; record violation in `OutcomeBundle` |
| **C-18** | Execute | Put-once store overwrite or deletion attempt (`G-3`) | Reject mutation of existing content-addressed artifact |
| **C-19** | Execute | Deterministic replay check against pinned inputs (`G-49`) | Verify replay-equivalent eligibility and commit topology invariance |
| **C-20** | Output | Runtime output fails post-condition schema check | Quarantine output; emit failed `OutcomeBundle` without promotion |
| **C-21** | Output | Attempt to use `OutcomeBundle` (`G-15`) as execution authority | Reject; `OutcomeBundle` is an evidence record only, never a plan |
| **C-22** | Release | Unsupported conformance or outcome claim in release notes (`G-67`) | Mechanically block release until claim matches verified evidence ledger |
| **C-23** | Audit | End-to-end lineage walk (`H_set → Intent → GGC → OutcomeBundle`) | Pass when all cryptographic digests and authority chains verify |

* * *

## Reader’s Guide and Glossary

The formal notation used below is summarized here so that product-management readers can follow the architecture without relying on revision notes or companion material.

| No. | Formal object | Plain meaning |
| --- | --- | --- |
| G-1 | DODGE | Domain-Ordered Directed Graph Execution: the framework this paper defines for turning open-ended AI planning into bounded, reviewed, signed execution graphs. |
| G-2 | H(...) — cryptographic hash | The paper’s collision-resistant cryptographic hash function (SHA-256 or stronger). H(x) is the content-address, or digital fingerprint, of x: any change to x yields a different H(x) except with negligible collision probability. Written H(...) to keep it distinct from H_set. |
| G-3 | Content-addressed identity / put-once store | An artifact is content-addressed when its identity is H(...) of its own bytes, so any edit changes its identity. A put-once store accepts each identity exactly once and thereafter returns byte-identical content, rejecting overwrite and deletion. |
| G-4 | H_set — hypothesis set | The versioned, human-ratified set of product hypotheses that marks the user’s declared product direction. DODGE treats these hypotheses as intent anchors, not as truths or as candidates the system may independently rank. The notation H_set avoids collision with H(...), the paper’s cryptographic hash function. |
| G-5 | DODGE stages (IPCE) | Intent → Plan → Compile → Execute, the single lifecycle vocabulary shared with ship-mlp. Intent states the requested outcome and must pass the H_set alignment check. Plan selects allowed routes and standard tasks (both defined below, G-61), typed artifacts, graph topology, and effect scope. Compile validates and binds that plan and its authority evidence into a GGC (Governed Graph Commit, defined below). Execute admits only that GGC, enforces its committed bounds, and emits an OutcomeBundle (defined below). |
| G-6 | Hypothesis-alignment check | The mandatory pre-Plan check that compares an Intent with the active H_set. Sufficient alignment admits the Intent to Plan. Low alignment blocks direct execution until a human ratifies an H_set amendment or approves an exception bound to that exact Intent; the agent cannot amend H_set or grant the exception. |
| G-7 | Graph states | Raw AI proposal (G_proposed) → statically admitted candidate (G_candidate) → human-ratified topology (G_approved) → compiler-attested commit (GGC, defined below). |
| G-8 | Planner | The AI role invoked at the Plan stage. It proposes the raw execution graph G_proposed — routes and standard tasks (defined below, G-61), typed artifacts, topology, confidence scores, and activation predicates (defined below, G-26) — but holds no execution authority; its proposal must be compiled before anything can run. |
| G-9 | Worker | The execution agent that runs a single admitted node during Execute and emits that node’s typed output. Worker outputs are recorded in the execution trace and are admitted only if they satisfy the node’s committed field schema and scope bounds. |
| G-10 | Domain method | A concrete applied set of steps for product-hypothesis formation or governance work. NBM4 is the primary reference method in this paper and combines multiple submethods and techniques; its machine-checkable encoding is the domain-method schema Σ (sigma). Lean Startup, JTBD, and Continuous Discovery are alternative examples. |
| G-11 | Σ (domain-method schema) | The machine-checkable encoding of a domain method: which artifact types exist (Persona, Pain, Feature…), what order stages come in, what depends on what. Formally it is the tuple Σ = (S, A, f, F, L, R, c_candidate, c_eligible, B_min, B_max, Φ, Ψ) — stages, artifact types, stage assignment, field schemas (G-62), path bounds, relationships, candidate and eligible cardinalities, population bounds, predicate language, and structural constraints. Each component is glossed in its own row below or defined in Appendix A.1. |
| G-12 | Compiler | The automated admission gate. It rejects plans that break the domain-method schema, cardinality bounds, predicate language, or attestation requirements before execution. |
| G-13 | Executor (graph-closed) | The runtime that can execute only the verified committed graph and exposes no topology-mutation API. |
| G-14 | GGC (Governed Graph Commit) | The signed, content-addressed execution artifact retained in a put-once store; any payload change produces a different identity except with negligible collision probability. |
| G-15 | OutcomeBundle | The content-addressed, evidence-bound result of one execution run: commit and run identities, Intent and H_set references, trace and activation-log references, terminal node statuses, typed output references, and supporting evidence. It records what happened but grants no authority for another action; a later user Intent may cite it and must re-enter the same IPCE lifecycle. |
| G-16 | β (beta) — adversarial triage record | The adversarial review record produced by the three-role triage panel (Advocate, Skeptic, Judge — defined below at §3.8). It contains two hashed reports, one from the Advocate and one from the Skeptic; the Judge’s verdict and rationale, carried inside the signed β_payload rather than as a separate report; the exact model and prompt configuration; and all three role attestations. |
| G-17 | HITL | Human-in-the-loop approval: in DODGE, this is a hard compile-time gate over the exact approved graph hash, not an advisory review after execution has already begun. |
| G-18 | α (alpha) | The human approval record that cryptographically binds the exact proposed commit, approver identity, trusted approval time, and trust-manifest hash. Without valid α, the Compiler cannot produce an admissible GGC. |
| G-19 | γ (gamma) | The Compiler’s signed attestation that the approved commit passed its checks. It is separate from the human approval α. |
| G-20 | μ (mu) | The commit-bound map from each governed role to the exact immutable model, prompt, tool, and binary references used for that role. |
| G-21 | GGC pipeline | Intent → H_set alignment → Plan (the Planner proposes G_proposed) → Compile (static validation → G_candidate → adversarial Triage → HITL approval → final Compiler attestation → GGC) → Execute (the graph-closed Executor runs the committed graph and emits an OutcomeBundle). |
| G-22 | Policy bundle — Π (pi) | The complete, version-pinned rulebook that a GGC binds to. It combines the domain schema and structural limits with hypothesis-alignment, route, standard-task, artifact-schema, activation, triage, approval, lifecycle, trust, and storage policies used to compile and execute the commit. |
| G-23 | σ (sigma) / Π_σ (pi sub sigma) | σ is the content-addressed identifier—the digital fingerprint—of the policy bundle. ResolvePolicyBundle(σ) returns Π_σ, and the Compiler or Executor verifies that the returned bundle hashes back to σ before using any rule. σ identifies the bundle but contains no readable policy fields. |
| G-24 | λ (lambda) / λ_V / λ_E — label maps | The node- and edge-label mappings of a graph. λ_V labels each node with its artifact type and stage; λ_E labels each edge with its semantic type (requires, derives_from, activates, or evidence_for). |
| G-25 | V / V_root / E_exec / E_audit — graph sets | V is a graph’s node set and V_root ⊆ V its commit-bound roots (nodes with zero incoming execution edges). E_exec is the scheduler-visible execution-edge set (requires/derives_from/activates); E_audit is the audit-only edge set (evidence_for), excluded from scheduling and reachability. |
| G-26 | Φ (phi) / activation predicates | Typed go/no-go formulas over bounded node-output fields. |
| G-27 | ρ (rho) | The commit-bound map from each execution edge to its activation predicate: ρ(e) ∈ Φ when the edge is an activates edge, and ρ(e) = ⊤ (always true) for requires and derives_from edges. |
| G-28 | Ψ (psi) — structural constraints | The schema’s structural-constraint set. It authorizes which artifact types and cardinalities may serve as roots, requires every root to have execution in-degree zero, forbids non-root nodes with execution in-degree zero, and requires every schedulable node to be reachable from V_root through E_exec. Every in-degree condition in Ψ is counted over E_exec alone; E_audit edges never contribute to in-degree, reachability, or schedulability. |
| G-29 | ν (nu) | Planner-supplied node data captured in the commit before execution. Worker outputs are recorded later in the execution trace. |
| G-30 | Score_bp | The canonical confidence-score domain: integers from 0 to 10,000 (basis points), where 0 = 0.0000 and 10,000 = 1.0000, under version tag basis-points-v1. |
| G-31 | κ (kappa) | Planner confidence scores per proposed edge, canonically encoded as integer basis points from 0 to 10,000. |
| G-32 | B_min / B_max | The minimum and maximum number of artifacts of each type that a candidate graph may contain. Profile-specific minima make mandatory roots machine-checkable. |
| G-33 | Cardinality bounds | Limits on how many relationships each artifact may have to other artifacts, specified separately for incoming and outgoing relationships. These differ from the artifact counts in B_min/B_max. |
| G-34 | L (path-level scope bounds) | Size limits on individual fields and collections, such as maximum text length or maximum list-item count, inside node records and outputs. |
| G-35 | Activation modes | Mode A commits branch-eligibility decisions before execution. Mode B records runtime decisions in a content-addressed replay log and is the practical default. Mode C recomputes decisions and makes no replay-equivalence claim. |
| G-36 | K / K_log | K records the values and decisions that determine optional-branch eligibility. K_log is the saved, content-addressed replay copy used by Mode B. |
| G-37 | χ (chi) | The commit-bound activation-control record that names the activation mode and binds the applicable precommitted-decision or replay-policy data. |
| G-38 | supersedes_id | An optional identifier linking a successor GGC to the exact earlier GGC it replaces. |
| G-39 | C_min / C_plus | Two precision levels of the GGC model. C_min is the minimal commit tuple: the authority references (Intent, H_set, alignment record, route, tasks, effect scope), the topology and its labels, per-edge ρ, and α, σ, μ. C_plus is the full implementation commit tuple; it carries everything in C_min and additionally binds the explicit E_exec/E_audit partition, ν, κ, β, γ, χ, supersedes_id, and the extension fields. Note that α is present in both — no precision level of the GGC model omits the human approval record. Both are defined in §3.10. |
| G-40 | τ_r (tau sub r) | The execution trace of run r: the append-only, content-addressed event log the Executor emits while running a GGC. Its hash H(canonical(τ_r)) is referenced by the run’s OutcomeBundle. |
| G-41 | Lifecycle chain | The signed, append-only history of GGC state changes. It proves transition order and current state while enforcing effective-dated authorization and preventing rollback to an older state. |
| G-42 | Δ_max (delta max) | The maximum allowed clock skew between a lifecycle transition’s claimed signed_at and the registry’s own recorded time, pinned by the lifecycle-head policy. |
| G-43 | Epistemic layers (L1–L4) | A claim-and-evidence stack numbered from concrete implementation upward to market adjudication. The numbering expresses level, not the chronological order in which work is created. These epistemic layers (L1–L4) are distinct from the five governance tiers of the validation pipeline (G-48). They are also distinct from two label namespaces that appear only in Appendix D and are not this paper’s: ship-mlp’s own repository schema/law tiers, written L1/L2 because those are the literal artifact names, and the OpenSSF SLSA L2 assurance level. Wherever this paper reasons about epistemic burden of proof, L1–L4 carry the meanings in G-44–G-47 and no other. |
| G-44 | L1 — Code conformance | Does the implementation satisfy its specifications? Tests and conformance guards check this layer. |
| G-45 | L2 — Implementation specifications | What the system must do: engineering requirements and executable contracts that constrain the code. |
| G-46 | L3 — Product hypotheses | Human-ratified markers of product direction: customer problems, segments, features, and value propositions against which executable Intents are checked. DODGE does not determine whether these hypotheses are true or worth pursuing. |
| G-47 | L4 — Market adjudication | What real-world evidence says after release: whether customers buy and use the product and whether its economics hold. This verdict is outside DODGE’s scope. |
| G-48 | Five-tier graph validation pipeline (Tiers 1–5) | The five physical tiers with checkpoints DODGE uses to validate a graph before it can execute: Tier 1 Schema ➡️ Tier 2 Cardinality ➡️ Tier 3 Predicates ➡️ Tier 4 Triage ➡️ Tier 5 HITL. These governance tiers are distinct from the epistemic layers L1–L4. |
| G-49 | P-* / T4a / T4b — formal property identifiers | The paper’s formal claims, each with a prefixed identifier: P-HALIGN Hypothesis-Aligned Admission; P-BLTS Bounded Legal Topology Space; P-CTI Commit Topology Invariance; P-ERE-A and P-ERE-B the strict and practical variants of Eligibility Replay Equivalence; P-CADM Compiler Admissibility; P-OUT Runtime Output Admissibility; P-EDGE Edge Semantic Biconditional; P-AUD Auditability; P-IMM Commit Immutability, Persistence, and Anti-Rollback; T4a Inter-stage Acyclicity; and T4b Bounded M:N. The P-/T prefix marks the formal-claim namespace; full statements are in §3.1 and §4. |
| G-50 | NBM4 | New Business Modelling Framework: the author’s product-management method used as the primary DODGE reference instantiation <https://nbm4.com/articles/nbmf-guide-intro/>. It comprises two phases, Solution Discovery and Solution Delivery, each containing three stages. |
| G-51 | MLP | Most Lovable Product: the product-development target concept used by NBM4, emphasizing the smallest scope that users will value. |
| G-52 | RFC | Request for Changes: a formal governance proposal document. |
| G-53 | Note / Napkin | Lightweight early-stage idea artifacts in NBM4 and ship-mlp. A Napkin is a minimal captured idea; a Note is a short free-form working document. A governed route may progress either one into an RFC, specification, tests, sprint artifacts, and code. |
| G-54 | DODGE-NBM4 | DODGE instantiated with the NBM4 domain-method schema for product-hypothesis formation. |
| G-55 | DODGE-RFC | DODGE instantiated for Request for Changes governance; presented as a sketch in Appendix C. |
| G-56 | Typed artifact progression | Progress from ideas to working code through routes whose allowed standard tasks, artifact types, schemas, dependencies, and effect scope are known before execution. In DODGE-NBM4 and ship-mlp these routes may govern Notes, Napkins, RFCs, specifications, tests, sprint artifacts, and code without a special cross-layer handoff object. |
| G-57 | ship-mlp | The author’s private reference substrate for DODGE (defined below in this row’s own terms; first referenced at G-5). The author reports v7.1 mechanism checks over it, but direct conformance to the v9.3 model defined in this paper is unestablished — several v9.3 contracts, including the pre-Plan H_set alignment gate and the OutcomeBundle contract, are reported as not yet implemented (§7.2, §7.7.4). Its implementation artifacts are not independently accessible with this paper. |
| G-58 | ship-mlp execution scope | The Plan stage receives governed target paths, Compile normalizes and binds the admitted paths into the GGC as an authorized_path_set, and Execute rejects material effects outside that set. OutcomeBundle references record the resulting effects but cannot widen or renew that authority. |
| G-59 | Check-API layer | The private reference substrate’s governed interfaces for validating and admitting plans, approvals, commits, and execution effects, together with their conformance-test harness. These are author-reported implementation surfaces, not independently accessible evidence or proof of conformance to the model defined in this paper. |
| G-60 | Test Cases TC-1–TC-23 | Twenty-three adversarial conformance cases (§7.5) covering invalid commits, mutations, signatures, lifecycle transitions, replay claims, low-alignment bypass, unauthorized H_set mutation, and OutcomeBundle authority misuse. A conforming implementation must reject or flag each case as specified. |
| G-61 | Route / Standard task / Route position | A route is a registered entry in Π_σ.route_registry, the policy-bundle registry of execution paths a Plan is allowed to select. A route is an ordered sequence of route positions; each position admits a declared set of standard tasks, the registered units of work resolved through Π_σ.standard_task_registry. A route and its tasks declare which artifact types they may produce and which targets and effects they authorize; a commit’s effect_scope may be no wider than that authorization (P-CADM step 17). Plan selects the route, Compile resolves route_id and every task_ref against the pinned registries and binds them into the commit, and Execute rejects material effects outside the resulting scope. Because both registries are members of Π and Π hashes to σ, a route’s content is fixed at commit time and cannot be widened after approval without producing a different σ. |
| G-62 | F / Path(F) — field schemas | F maps each artifact type to its typed field schema: for every type a, F(a) is a finite, acyclic, nonrecursive schema describing that type’s fields (§3.4). Path(F(a)) is the set of field paths reachable within it. Finiteness, acyclicity, and nonrecursiveness are what make Path(F(a)) finite and therefore make the path-level bounds L (G-34) machine-enforceable; recursive schemas and unbounded variable-length paths are not admitted. |
| G-63 | SEL — session evidence ledger | An append-only, typed evidence ledger scoped to an interaction session. Every governance decision defined in v9.3’s added sections — prompt-intake gate decisions, planning decisions, stage decisions — is written to SEL as a typed record carrying the prompt hash, checkpoint identity, and decision payload before the governed effect is admitted. SEL rows are evidence, not authority: citing a SEL record grants no execution right. Author-reported substrate surface (§3.14, D.4); DODGE’s formal properties do not depend on it. |
| G-64 | Prompt-intake gate / PromptIntentGateDecision | A fail-closed gate that runs on every action-requesting user prompt, before any executable Intent exists. The agent must log a typed PromptIntentGateDecision to SEL (G-63) — interpreted intent, bounded scope, assumptions, gaps, and an intent-confidence score — before the transport layer admits any non-logger tool action. Decisions are banded by a base threshold and safety margin: auto-continue at or above threshold plus margin, explicit human confirmation inside the margin band, redirect at or below threshold. The prompt-intake gate scores interpretation fidelity (did the system understand the request) and is distinct from the hypothesis-alignment check (G-6), which scores direction fidelity (whether the requested outcome matches the ratified H_set); a conforming composition runs intake first, alignment second. Author-reported substrate mechanism formalized in §3.14. |
| G-65 | Stage-decision record | The typed per-stage evidence row a Dispatcher pipeline appends to SEL (G-63) as an IPCE (G-5) stage completes: stage identity (route, planner, compiler, executor), a PROCEED or BLOCK decision, the governed path, a rationale, and a content digest of the stage output. Stage-decision records make the lifecycle’s intermediate admissions independently reconstructable without granting any authority themselves. Author-reported substrate surface (§3.14, C.6, D.4). |
| G-66 | Planner rejection loop | The bounded repair protocol between Planner (G-8) and Compiler (G-12): a Compiler rejection returns a typed, machine-readable repair payload; the Planner may replan at most a fixed number of times (the substrate pins three); exhaustion escalates to HITL (G-17) with structured repair guidance instead of admitting further self-repair. The bound prevents both unbounded planner self-play and silent scope widening across retries. Author-reported substrate mechanism formalized in §3.15. |
| G-67 | Conformance ledger and release-claim gate | A machine-readable ledger that records, per acceptance criterion and conformance case, a GREEN or NOT_GREEN status with evidence references and named deviations, plus an executable gate that scans declared release, grant, and marketing surfaces for blocked claim phrases. Full-conformance claim wording is admitted only while the ledger predicate is green and every named deviation is closed; otherwise the gate blocks the wording itself. Governs claims about the system rather than execution by the system. Author-reported substrate mechanism formalized in §3.16. |
| G-68 | ATG — Artefact Traceability Graph | The substrate-wide typed graph of governed artifacts and their declared relationships (authority references, creation edges, supersession), maintained as a derived index over the repository and queried through registered presets. ATG extends traceability discipline beyond the per-commit scope of a GGC (G-14) to the whole artifact population; it is an audit surface, not an execution authority. Author-reported substrate surface (D.4). |
| G-69 | Route amortization | The economic property motivating registered routes (G-61): a route compiled and ratified once is reusable across subsequent voyages, so the governance cost of deriving topology, tasks, and effect scope is paid once and amortized over every later run, with recompilation triggered by policy or schema drift. Routes are ratified into the registry by observed traffic rather than speculatively. Author-reported design rationale (C.6, D.4); no empirical cost measurements are claimed. |

* * *

## 1\. Introduction: Governing the Voyage, Not Predicting the Sea

Consider a product team that ships what the data says is right. Six months later, their primary market collapses due to geopolitical disruption outside any model’s training data. The product was well-researched, correctly prioritized, and structurally sound. It still failed.

No product-governance framework can guarantee immunity from such external shocks. Forecasting systems may estimate risks, but they cannot make product outcomes deterministic. Any paper claiming to make product development deterministic is selling a theorem the future will not honor.

This paper claims something different.

Given that the future is irreducibly uncertain, the question is not *can we guarantee product success* but *can we eliminate avoidable failure* — the failures that come not from unpredictable markets but from predictable process errors: skipping customer discovery, building features before validating pain, letting AI agents hallucinate scope without human ratification, repeating mistakes that decades of product management practice have already cataloged and named.

These failures are not caused by an unknowable future. They are caused by an ungoverned present execution of planned activities.

**Scope of DODGE.** This framework governs the *executable* path from hypothesis-aligned product Intent to artifact-producing AI execution. Initial PM interviewing and human ratification establish the first version of `H_set` before the first execution cycle. Exploratory conversation that invokes no Executor remains outside DODGE, but every executable Intent must pass the pre-Plan alignment check and the same IPCE lifecycle. In DODGE-NBM4, allowed typed routes may progress from Notes and Napkins through RFCs, specifications, tests, sprint artifacts, and code; while epistemic layer labels are used to distinguish the burden of proof—separating verifiable facts from unproven market assumptions—they do not require separate execution lifecycles.

### 1.1 The Structural Problem with Current AI-Assisted Development

Many AI-agent workflows permit task decomposition, delegation, and branching to emerge during execution. In the target class considered here, the absence of a complete pre-execution topology and hard admission boundary can produce three structural risks:

**Unauditable before execution.** When graph shape emerges only as a side effect of running, there may be no complete pre-execution artifact a PM can inspect, challenge, or ratify.

**Non-replayable for learning.** Without durable topology identity and trace binding, a failed product’s execution path may not be reconstructable, weakening institutional learning.

**Ungovernable at material forks.** Without a structural gate, runtime planning may generate 12 features instead of 4, skip pain validation, or skip a discovery stage. Natural-language prompt constraints are a common mitigation, but they are not self-enforcing structural controls.

DODGE addresses this structural governance gap. Whether it improves process or outcome measures is reserved for H1–H6.

### 1.2 What Governance Means Here

In a conforming DODGE implementation, governance means four things:

**Intent fidelity.** Every executable Intent resolves against the active human-ratified `H_set`. Low alignment blocks direct planning; only a human-controlled `H_set` amendment or exact-Intent exception can reopen the path.

**Structural constraint.** Known-bad execution paths are excluded by construction — not by PM vigilance, not by prompt discipline, but by a compiler that rejects structurally illegal graphs before any agent executes.

**Human ratification at material forks.** At every decision point where graph topology branches — how many features to pursue, which pains are material, which personas to prioritize — a human approves the topology before execution. Not after. The AI proposes; the PM ratifies; the Compiler enforces.

**Auditable institutional memory.** Under the P-AUD and P-IMM assumptions, every admitted execution produces a retained, human-attributed record of what was decided, why, and by whom. Post-mortem analysis becomes possible, successful patterns become reusable, and prior mistakes encoded in the domain-method schema become structural guardrails.

### 1.3 The Central Contribution

This paper introduces **Domain-Ordered Directed Graph Execution (DODGE)** — a hypothesis-aligned IPCE architecture with a five-tier graph validation pipeline, parameterized over a domain-method schema Σ. The schema transforms an admitted user Intent into a **Governed Graph Commit (GGC)**: a bounded, inspectable, adversarially reviewed, human-ratified, Compiler-validated execution artifact. Execute returns an OutcomeBundle rather than a new authority decision.

In a conforming DODGE implementation, “Execution” denotes the governed admissibility boundary: only a domain-constrained, human-ratified, Compiler-attested GGC is admissible to the Executor.

The contribution is the **specific conjunction** anchored by a human-ratified product-hypothesis set at **Layer 3 (L3)** and applied to typed artifact-producing routes:

- input shape = a user Intent admitted by the pre-Plan `H_set` alignment check, followed by open-ended AI planner output (not human-authored workflow code or pre-existing diagrams)
- subject domain = typed route-governed artifacts (Pain / Persona / Feature / ValueProposition / GTMChannel and, where the route declares them, Notes / Napkins / RFCs / specifications / tests / sprint artifacts / code) with declared semantic relationships
- constraint origin = cardinality bounds derived from a domain method and encoded in a domain-method schema (NBM4 is the primary instantiation; Lean Startup, JTBD, and RFC governance are alternative method families)
- HITL semantics = human approval is a *precondition for artifact existence*, enforced as a compile-time admission rejection when absent, not a runtime pause
- closure = the executor accepts *only* compiler-attested commits, verified by content hash, with no graph-mutation API surface
- epistemic anchor = human-ratified L3 product hypotheses, where market truth is unavailable ex ante; typed routes may produce L2 or L1 artifacts without collapsing the distinction between hypothesis, specification, and code-conformance claims
- audit closure = every executed traversal is traceable back to (a) the admitted Intent and active `H_set`, (b) the exact ratified topology, route, tasks, and effect scope, (c) the signing human, (d) schema/model/tool version pins at sign time, and (e) its OutcomeBundle

The substance-axis grid in §2.3 plots selected comparator systems against these axes explicitly. No surveyed comparator directly satisfies five or more axes simultaneously.

### 1.4 Domain Instantiation and Parameterization

DODGE is parameterized over a **domain-method schema** Σ. In this paper, a **domain method** is a concrete applied method for product-hypothesis formation or governance work. Its machine-checkable encoding is the **domain-method schema** Σ. The framework’s contribution is the pattern of compile-time governance; specific domain methods and their Σ encodings are instantiations, not the contribution itself.

**Primary reference instantiation: DODGE-NBM4.** Product management is the proof-of-concept domain; NBM4 (Kozloff, 2024) supplies the staged domain method and artifact relationships encoded by DODGE-NBM4, while the explicit cardinality bounds are derived when that method is encoded in Σ. NBM4 is authored by the present author and is therefore declared explicitly as one available domain method — not as proof that NBM4 is the correct PM method, and not as evidence that DODGE’s structural properties depend on NBM4’s specifics. Alternative product-development methods — Continuous Discovery (Torres, 2021), Lean Startup (Ries, 2011), Jobs-to-be-Done (Christensen et al., 2016), Value Proposition Canvas (Osterwalder et al., 2014) — would yield alternative valid Σ encodings with different stage counts, artifact type universes, and cardinality tables. P-BLTS, P-CADM, P-EDGE, and T4a/T4b apply to any finite Σ satisfying their stated assumptions; P-CTI, P-ERE, P-OUT, P-AUD, and P-IMM additionally depend on the declared executor, activation-context, storage, audit-channel, and cryptographic assumptions.

**Sketched second instantiation: DODGE-RFC.** Appendix C sketches DODGE applied to RFC governance over AI orchestration systems (the author’s own ship-mlp infrastructure provides the substrate). This second instantiation demonstrates domain-agnosticism by construction. RFC governance has a different stage set (Draft / Review / Trial / Adopted / Deprecated), different artifact types (RFC / OpenQuestion / ADR / Decision), and different cardinality bounds — yet the same five-tier graph validation pipeline and the same GGC structure apply.

### 1.5 Apparatus and Non-Claims

DODGE’s contribution is the **composition** of governance tiers into an enforced production pipeline. The composition draws on a substantial body of established tooling. We name each borrowed primitive explicitly and disclaim novelty in it; the contribution is in *how they are combined into the forcing function*, not in the primitives.

| Apparatus | Standard literature / reference | Status in this paper |
| --- | --- | --- |
| Directed acyclic graphs, topological sort | Cormen, Leiserson, Rivest, Stein (2009); Kahn (1962) | Tooling; no novelty claim |
| Content-addressed signed artifacts; supply-chain attestation | Sigstore (Newman et al., 2022); in-toto (Torres-Arias et al., 2019); SLSA specification (OpenSSF, 2026) | Tooling; α/γ/σ/μ follow this pattern; no novelty claim |
| AST-validated typed predicate language; type-checking | Cardelli (1996); Reynolds (1974); standard PL theory | Tooling; Φ uses standard typed-predicate-language techniques; no novelty claim |
| Cryptographic hash binding; content-addressed identity | NIST FIPS 180-4; RFC 8785 JSON Canonicalization Scheme; standard cryptographic primitives | Tooling; content-addressed commit identity; no novelty claim |
| Event-sourced replay; durable workflow execution | Temporal documentation (2026); event sourcing literature | Tooling; Mode B replay log uses standard event-sourcing pattern; no novelty claim |
| Multi-agent critique; adversarial debate | Constitutional AI (Bai et al., 2022); Debate (Irving et al., 2018); abstract argumentation (Dung, 1995) | Tooling; Advocate/Skeptic/Judge applies established multi-agent critique patterns; no novelty claim |
| Human-in-the-loop approval workflows | LangGraph documentation; OpenAI Agents SDK documentation; standard approval-workflow patterns | Tooling primitive — DODGE changes the binding semantics of HITL (compile-time precondition vs runtime advisory), not the mechanism |
| Domain schema modeling; entity-relationship diagrams | Chen (1976) | Tooling; Σ is a typed ER schema; no novelty claim |
| Hierarchical task decomposition | HTN/SHOP (Nau et al., 1999); SHOP2 (Nau et al., 2003) | Acknowledged adjacent literature; DODGE does not perform HTN decomposition |
| Graph-closed DAG workflow execution | Airflow, Prefect, Dagster documentation | Tooling pattern; DODGE’s executor uses established graph-closed execution semantics |
| Static workflow verification | Agentproof (Melwin Xavier et al., 2026; arXiv:2603.20356) | Adjacent pre-deployment verification of already-authored agent workflows; DODGE governs topology formation before workflow code exists (see §2.2) |
| Requirements and artifact traceability | Gotel & Finkelstein (1994); Cleland-Huang et al. (2014) | Tooling; typed route edges and OutcomeBundle references apply standard traceability discipline across Intents, artifacts, effects, and evidence |
| Argumentation frameworks; semantic stability of debate | Dung (1995); Bench-Capon & Dunne (2007) | Tooling; triage panel applies argumentation-theoretic patterns; no novelty claim |

A reader who observes “but Agentproof / Sigstore / LangGraph / Dung-1995 / SHOP2 already does X” can confirm by reading this section that we cite X as our tooling, not as our contribution. The contribution is the **architectural forcing function** that makes hypothesis alignment, route/task/schema admission, human ratification, graph closure, and evidence binding operate as preconditions for AI execution — not novelty in any primitive listed.

### 1.6 Paper Structure

Section 2 reviews prior art and plots every comparator against a seven-axis substance grid. Section 3 presents the `H_set`\-aligned IPCE lifecycle, governance stack, graph-state model, GGC definition, OutcomeBundle, typed artifact progression, schema governance, and — new in v9.3 — prompt-intake governance (§3.14), the bounded planner rejection loop (§3.15), and release-claim governance (§3.16). Section 4 gives formal propositions and proof sketches. Section 5 instantiates DODGE-NBM4. Section 6 describes the gap-control decomposition. Section 7 presents the validation method, author-reported private implementation status, and alignment boundary. Section 8 concludes with limitations and future work. Appendices provide the full Φ grammar, selected NBM4 projections, a sketched DODGE-RFC instantiation, the ship-mlp substrate cross-reference, and the version change history.

* * *

## 2\. Prior Art and the Governance Gap

### 2.1 The Specification Movement and Its Domain Boundary

The emergence of AI code generation has produced a significant methodological response: Spec-Driven Development (SDD) — a movement treating specifications, not code, as the primary artifact of software development. A recent arXiv paper by Deepak Babu Piskala (arXiv:2602.00180, 2026) defines the core inversion: specifications become executable contracts; code is a derived artifact. Three maturity levels are described: spec-first, spec-anchored, and spec-as-source.

The movement is substantial. By 2026 it encompasses multiple documented frameworks — from Spec-Kit to enterprise systems and academic proposals. Constitutional Spec-Driven Development by Srinivas Rao Marri (arXiv:2602.02584, 2026) adds governance layers: security constraints with explicit CWE vulnerability mappings, audit trails, and supervision checkpoints — one close surveyed comparator to DODGE in governance intent, at a different epistemic layer.

A practitioner essay by Wasowski (2026) pushes the movement further: stop writing specs entirely, write *facts*. Natural-language specifications require model interpretation, and that interpretation can drift. Once its types, environment, and inputs are pinned, a machine-executable assertion has fixed evaluation semantics and returns pass or fail.

This claim is plausible at the software layer. Facts exist there. Does function X return Y given input Z? Verifiable. Binary. The assertion either holds or it does not.

#### The product layer is a different epistemic domain

The product-outcome claims DODGE governs are not facts before market validation. “Customers will pay $50/month for this feature” is a hypothesis. It becomes evidence-backed only when enough customers pay and unit economics survive long enough to support the business model. A team can conduct rigorous customer discovery, validate pain with 200 interviews, prioritize features with WSJF scoring, and still ship a product that fails because the market shifted, a competitor pivoted, a technology became commoditized, or a geopolitical event restructured demand.

This is not a deficiency of method. It is the nature of the domain. Product development operates under irreducible uncertainty. No framework converts product hypotheses into facts before the market renders its verdict.

**DODGE does not claim otherwise.** `H_set` records human-ratified hypotheses as markers of declared product direction, not facts about the product. A GGC records the governed execution authorized against those markers; it does not prove the hypotheses true or give the system authority to rank them.

The layer separation is precise. **L3 vs L2 discriminating criterion:** a node belongs to L3 if its content is a *bet falsifiable by market evidence*; it belongs to L2 if its content is a *contract falsifiable by an implementation that violates it*. A hypothesis “users will pay $50/mo” cannot be falsified by code, only by the market. A spec “endpoint returns 200 with JSON shape S” cannot be falsified by market, only by implementation. The two layers admit different disciplines.

```text
L3: human-ratified hypotheses in H_set anchor executable Intent
L2: typed specifications constrain implementation behavior
L1: tests and code provide implementation-conformance evidence
```

SDD governs implementation specification — the formalization of what the system should do, at Layer 2. DODGE governs the executable path from a user Intent that is aligned with a human-ratified L3 `H_set`. It asks whether the Intent may enter Plan and whether the resulting route, tasks, typed artifacts, effect scope, topology, and approvals are admissible before AI executes them. An Intent to produce specifications or code is compiled into the applicable typed route directly; there is no autonomous promotion decision or special L3-to-L2 handoff. The epistemic layers remain distinct because a market-falsifiable hypothesis, an implementation-falsifiable specification, and code-conformance evidence make different kinds of claims even when one governed route connects their artifacts.

### 2.2 Workflow, Orchestration, and Verification Frameworks

We examine selected adjacent systems and the axes on which each touches DODGE. Each system is genuinely useful; none directly satisfies five or more axes in the DODGE substance grid (§2.3).

**LangGraph** provides graph-structured agent orchestration with predetermined paths, human-in-the-loop interrupt patterns, and persistence. LangGraph does not apply a domain-method schema as topology constraint, does not enforce ERD cardinality, does not require adversarial triage before human review, does not bind HITL as a compile-gate, and does not produce a compiler-validated execution commit as the sole admissible executor input. A reader may ask whether this is simply LangGraph with HITL discipline; topology invariance can be *achieved* through developer discipline in LangGraph, but achieving it as a *compile-time precondition* requires the architectural forcing function DODGE describes (see §3.2 Policy vs Physics).

**Temporal** provides durable execution and event-sourced replay: workflow execution records side effects so that re-execution from history returns the same decisions without re-running external calls. Temporal does not constrain what graph shapes are legal at the domain level, does not enforce domain-ordered artifact typing, and has no human approval gate that must be satisfied before an execution commit is produced. Its determinism guarantee applies to replay from recorded history — DODGE uses Temporal-style replay logging as Mode B tooling but does not contribute novelty in replay infrastructure.

**BPMN 2.0** (OMG specification) provides standardized process notation and semantics for business process modeling. BPMN is human-authored process diagrams; DODGE’s G\_candidate is AI-planner output that has never been executable until compiled. BPMN has no scored activation conditions over AI-generated output fields, no adversarial confidence triage, and no compiler that validates domain-schema conformance of an AI-proposed execution topology.

**OpenAI Agents SDK and AutoGen** support multi-agent orchestration with handoffs, agents-as-tools, guardrails, and human review patterns. These are runtime and application-orchestration facilities. They do not provide domain-cardinality-bounded graph compilation, mandatory topology ratification before execution, or the admissibility/state model (T\_legal, G\_proposed → G\_candidate → G\_approved → G\_eligible) that DODGE formalizes.

**Guardrails AI** and **OpenAI Structured Outputs** validate inputs, outputs, and tool behavior at runtime. They are appropriate inside Planner/Triage/Node output generation; they do not govern graph formation or topology ratifiability.

**Agentproof (Melwin Xavier et al., 2026; arXiv:2603.20356)** is a close comparator on adjacent territory. It extracts workflow graphs from existing agent-framework code and checks whether those graphs satisfy declared temporal safety requirements, including requirements for human approval before sensitive actions. Agentproof implements these checks by compiling its policy rules into finite-state monitors and comparing them with the extracted workflow graph. It therefore asks whether an already-authored workflow obeys specified safety rules. DODGE acts one stage earlier: it first checks user Intent against `H_set`, then governs how open-ended AI planner output becomes a typed route, bounded task graph, authorized effect scope, and human-approved GGC before executable workflow code exists. In Agentproof, a human gate is a property verified within an existing workflow; in DODGE, human approval is a compile-time condition for producing the only artifact the Executor may run. The systems are complementary: Agentproof-style temporal verification could be applied downstream to a DODGE GGC to check safety properties beyond DODGE’s intent-alignment, schema, cardinality, and authority constraints..

**GraphFlow** treats workflow diagrams as executable specifications with a restricted core specified for future compile-time proof checking, runs under a durable event-log runtime, and separates human judgment and AI decisions through swimlanes. GraphFlow’s contracts are about workflow behavior at the execution layer; DODGE’s constraints are about product-hypothesis artifact relationships at the formation layer. The subject matters differ.

**AgentFlow (Wang et al., 2026; arXiv:2607.01640)** recovers framework-agnostic agent dependency graphs from agent programs and uses those graphs for governance and security analysis. AgentFlow is adjacent to Agentproof and execution-lineage work: it improves static visibility into agent programs that already exist as code. DODGE remains distinct because it governs the formation of a product-hypothesis topology before it becomes executable code or a runtime workflow.

**Execution Lineage** (arXiv:2605.06365, 2026) represents AI-native work as a DAG of artifact-producing computations with explicit dependencies, stable intermediate boundaries, and identity-based replay. Its target is reproducibility of AI-native work; DODGE’s target is pre-execution ratifiability of hypothesis topology. Both use content-addressed artifacts; they address different problems.

**Certified Purity for Cognitive Workflow Executors** (McCann, 2026; arXiv:2605.01037) converts governance enforcement from runtime convention into structural capability boundaries using restricted WebAssembly, signed purity certificates, runtime verification gates, and remote attestation. It is a concurrent comparator on the *capability-isolation + cryptographic-attestation* substrate. Certified Purity operates at the code-execution layer (functional purity of computational steps inside a sandboxed runtime); DODGE operates at the L3 product-hypothesis-formation layer. The mechanisms overlap on substrate (WASM restriction, signed certificates, verification gates, and attestation) but not on subject matter (purity of computations vs ratification of product-hypothesis topology). Certified Purity therefore supplies partial A₅ substrate support; satisfying DODGE’s closure axis additionally requires GGC-only admission, preservation of the committed topology projection, and no topology-mutation surface. The presence of this prior art narrows DODGE’s novelty subclaim: capability isolation and attestation are not unique contributions; DODGE’s contribution is the L3 hypothesis-governance conjunction that includes its stronger closure contract as one of seven axes.

**HTN planning (SHOP / SHOP2)** decomposes goals hierarchically under task-network constraints. HTN planners construct plans; in DODGE, an AI Planner produces G\_proposed and Compiler.static alone admits G\_candidate. HTN constraint structure resembles Σ in that both encode method, but HTN does not bind HITL as a compile-gate or produce a content-addressed signed execution artifact.

**Constitutional Spec-Driven Development** (Marri, arXiv:2602.02584) embeds non-negotiable security constraints into the specification layer with empirical security-defect reduction results. It targets L2 security-by-construction; DODGE targets L3 product-hypothesis-by-construction.

**Recent LLM-agent workflow surveys** (Yue et al., 2026; arXiv:2603.22386) distinguish static vs dynamic workflow structures. DODGE commits topology before execution while permitting runtime eligibility decisions only through committed predicates and commit-bound or replay-logged activation contexts.

### 2.3 The Substance-Axis Grid

We claim DODGE’s contribution is the **conjunction** of seven substance axes simultaneously. The claim is not “no system does anything similar”; it is that no surveyed comparator directly satisfies five or more axes simultaneously. The grid below plots every comparator from §2.2 against the seven axes.

#### Axes

- **A₁ Input shape** — `H_set`\-aligned user Intent followed by open-ended AI-planner output (not human-authored workflow code, not pre-existing diagrams)
- **A₂ Subject domain** — typed route-governed product artifacts with named semantic relationships (Pain / Persona / Feature / specification / test / etc.), not generic tasks/states/activities
- **A₃ Constraint origin** — cardinality bounds derived from a product-development method (not implementation, not security, not process compliance)
- **A₄ HITL semantics** — human approval is a *precondition for artifact existence* (compile-time admission rejection if absent), not a runtime pause or a verifiable property
- **A₅ Closure** — executor accepts *only* compiler-attested commits, hash-verified, with zero topology-mutation API surface
- **A₆ Epistemic anchor** — human-ratified L3 hypotheses under irreducible market uncertainty anchor execution while typed routes preserve the distinct claim semantics of L2/L1/L4 artifacts
- **A₇ Audit closure** — every executed traversal maps back to (a) admitted Intent and `H_set`, (b) ratified route/topology/effect scope, (c) signing human, (d) schema/model/tool pins, and (e) OutcomeBundle evidence

Legend: **✓** means the cited source directly satisfies the axis as defined; **partial** means it supplies only part of the axis; **—** means the axis is not supported by the cited source. An L1/L2 label records an adjacent epistemic layer and does not satisfy A₆. Partial cells are not counted as direct satisfaction.

| System | A₁ Input | A₂ Subject | A₃ Constraint | A₄ HITL | A₅ Closure | A₆ Layer | A₇ Audit |
| --- | --- | --- | --- | --- | --- | --- | --- |
| LangGraph | partial | — | — | — | partial | — | partial |
| Temporal | — | — | — | — | partial | — | partial |
| BPMN 2.0 | — | — | — | — | — | — | partial |
| OpenAI Agents SDK | partial | — | — | — | — | — | — |
| AutoGen | partial | — | — | — | — | — | — |
| Guardrails AI / Structured Outputs | — | — | — | — | — | — | — |
| Agentproof (Melwin Xavier et al.) | — | — | — | partial (verifiable property) | — | L2/workflow | partial |
| AgentFlow (Wang et al.) | — | — | — | — | — | L2/program | partial |
| GraphFlow | — | — | — | partial | — | L2/workflow | partial |
| Execution Lineage | — | — | — | — | — | — | partial |
| Certified Purity (McCann, arXiv:2605.01037) | — | — | — | — | partial (isolation + attestation) | L2/code | partial |
| Constitutional SDD (Marri) | — | — | partial (security) | — | — | L2 | partial |
| SDD / Spec Kit (Piskala) | — | — | — | — | — | L2 | — |
| HTN / SHOP2 | — | — | partial | — | — | — | — |
| Sigstore / in-toto / SLSA | — | — | — | — | — | — | partial |
| Dung argumentation / multi-agent debate | — | — | — | — | — | — | — |
| Airflow / Prefect / Dagster | — | — | — | — | partial | — | partial |
| LLM-agent workflow survey (Yue et al.) | — | — | — | — | — | — | — |
| NBM4 | — | ✓ | partial | — | — | ✓ | — |
| Lean Startup / JTBD / Continuous Discovery / Value Proposition Canvas | — | partial | — | — | — | ✓ | — |
| DODGE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |

No surveyed comparator directly satisfies five or more axes. NBM4 directly supplies the subject and L3-layer axes; DODGE-NBM4 derives explicit cardinality constraints when encoding the method into Σ. The other grouped product methods are adjacent at L3 but are not credited here with explicit cardinality constraints. **The seven-axis conjunction is unoccupied in the surveyed comparator set.** DODGE’s novelty claim is restricted to this conjunction; we make no novelty claim in any individual axis.

**Bounded prior-art search protocol.** The substance-axis grid above was constructed by the following search protocol, made explicit to make reviewer extension possible:

1. **Seed comparators** drawn from five families: (a) workflow/orchestration frameworks (LangGraph, BPMN, OpenAI Agents SDK, AutoGen, Airflow, Prefect, Dagster); (b) static workflow verification (Agentproof); (c) execution-lineage and durable-replay systems (Execution Lineage, Temporal, Certified Purity); (d) product-development methods (NBM4, Lean Startup, JTBD, Continuous Discovery, Value Proposition Canvas); (e) spec-driven development (SDD / Spec Kit, Constitutional SDD).
2. **Keyword search on arXiv** under cs.SE, cs.AI, cs.MA, cs.PL for combinations of terms from the §1.5 apparatus table: {“compile” + “agent” + “graph”}, {“workflow” + “verification” + “topology”}, {“governance” + “AI” + “schema”}, {“attestation” + “agent” + “executor”}, {“product hypothesis” + “compiler”}, {“AI planner” + “ratification”}, {“domain-method schema” + “AI workflow”}. Search window: 2023-01-01 through 2026-07-08.
3. **Forward and backward citation traversal** from each seed paper to depth 2.
4. **Substrate matrix completion**: for each cited system, populate the seven axes from the system’s primary documentation or paper, not inference.
5. **Falsification invitation**: a reviewer who identifies a system populating five or more axes — by name, with citation, mapped to the axes — falsifies the conjunction-novelty claim. Future revisions should update the grid if such a comparator is identified.

This protocol is documented and bounded; it makes the claim falsifiable by named system rather than rhetorical. Future revisions should incorporate named additions that meet the threshold.

### 2.4 The Hypothesis-Governance Gap

The deepest gap in the surveyed comparator set is not architectural — it is epistemic. The surveyed workflow, spec, and orchestration frameworks primarily assume the problem is *execution* of known intent. The harder problem — governing the *formation* of intent under uncertainty — is not represented at L3 in that set.

#### The four epistemic layers of governed software product development

```text
Layer 4: Market adjudication / verdict
         Unit economics survive. Customers pay at scale.
         Churn stays below threshold. Hypothesis confirmed.
         Adjudicated by: the market. Market adjudication is outside DODGE's scope.
              ↑
Layer 3: Product hypotheses
         Which pains are real. Which features address them.
         Which segments exist. Which value propositions resonate.
         Governed by: DODGE → GGC
              ↑
Layer 2: Implementation specs
         What the system should do. Executable contracts.
         Spec-as-source-of-truth for AI code generation.
         Governed by: SDD → executable specifications
              ↑
Layer 1: Code conformance
         Does implementation match spec?
         Compiler-verifiable guards on declared intent.
         Governed by: TDD (Beck, 2002) → test guards
```

Markets do not *govern* — they *adjudicate*. Governance implies a process with rules; the market is a verdict mechanism.

Test-Driven Development provides implementation conformance guards at the code layer. The SDD movement pushes the discipline one layer up: specs should precede and constrain AI code generation. Both are necessary. Neither is sufficient at L3.

DODGE operates at Layer 3 — the layer neither TDD nor SDD addresses. Implementation conformance tells you the code does what the spec says. Executable specs tell you what the AI should build. Neither tells you whether the spec addresses a real customer pain, whether customers will pay for the solution, or whether the market exists at the scale the business model requires.

Wasowski’s “facts not specs” insight, applied correctly across all four layers, produces a precise conclusion: write executable facts at Layer 1, governed specs at Layer 2, and governed hypotheses at Layer 3. Facts at Layer 3 do not exist until Layer 4 confirms them. The discipline appropriate to Layer 3 is not fact-writing — it is hypothesis governance.

That is what DODGE does. Not because the product voyage is predictable — it is not. It provides explicit structural accountability for a voyage through uncertainty, regardless of what the sea does next.

* * *

## 3\. Domain-Ordered Directed Graph Execution — The DODGE Stack

### 3.1 Hypothesis-Aligned IPCE and Graph-State Model

DODGE uses one lifecycle for every governed execution: **Intent → Plan → Compile → Execute (IPCE)**. It does not introduce a separate lifecycle for discovery, specification, implementation, or evidence gathering. The allowed route and typed artifacts differ by Intent; the governance sequence does not.

**Hypothesis-set initialization.** Before the first executable Intent, a human-controlled initialization process establishes `H_set = (set_id, version, hypotheses, ratification, content_hash)`. Each hypothesis has a stable identifier and states part of the user’s declared product direction. In DODGE-NBM4, structured PM interviewing is the primary initialization method. `H_set` is not a truth set, a ranking, or an AI recommendation. It is a versioned authority boundary owned by the user. The paper writes `H_set` rather than `H` because `H(...)` already denotes cryptographic hashing.

**Mandatory pre-Plan alignment.** For Intent I, `Align(I, H_set, Π_σ.hypothesis_alignment_policy)` produces an alignment record binding `{intent_ref, hypothesis_set_ref, matched_hypothesis_ids, alignment_score, alignment_threshold, evaluator_pins, decision, exception_ref}`. Both references are content-addressed. The decision is `ALIGNED`, `LOW_MATCH`, or `EXCEPTION_APPROVED`. Only `ALIGNED` and `EXCEPTION_APPROVED` may enter Plan. `LOW_MATCH` blocks direct planning and execution; it does not declare the Intent bad or false.

**Low-match path and user sovereignty.** After `LOW_MATCH`, only a human may (a) ratify a new `H_set` version that contains or reframes the relevant hypothesis, or (b) approve an exception cryptographically bound to the exact Intent, active `H_set` hash, scope, and expiry. The alignment check then runs again. An agent may explain the mismatch and propose an amendment, but it cannot amend `H_set`, issue an exception, lower the threshold, or treat an OutcomeBundle as new authority. This blocks free agent expansion while preserving the user’s right to pursue any hypothesis deliberately.

**Single-cycle semantics.** Plan receives the admitted Intent plus alignment evidence and proposes a registered route, standard tasks, typed artifacts, graph topology, and effect scope. Compile validates and binds that proposal into a GGC. Execute consumes only the GGC and emits an OutcomeBundle. An Intent to research market or customer evidence uses this same lifecycle; the resulting OutcomeBundle may support a later human `H_set` amendment. An Intent to create specifications, tests, sprint work, or code likewise uses the same lifecycle with the applicable typed route.

DODGE operates over a sequence of graph states. Separating these states avoids conflating raw AI output, admissible candidate topology, human-ratified topology, predicate eligibility, and completed runtime work. Let λ (lambda) denote the node- and edge-label mappings used below. Let `shape(G) = (V, V_root, E_exec, E_audit, λ_V, λ_E)` denote the finite typed graph-shape projection, excluding predicates, confidence scores, and node content. Let `top(C) = (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ)` denote the complete committed-topology projection whose preservation is claimed by P-CTI.

**G\_proposed** — raw Planner output from an admitted Intent I and its alignment record. It may be malformed, name an unregistered route or task, contain illegal artifact types, widen effect scope, or violate cardinality bounds. G\_proposed is not assumed to be admissible.

**T\_legal(Σ)** — the finite set of graph-shape projections permitted by domain-method schema Σ, instance bounds, candidate relationship cardinalities, and structural constraints. L, ρ, κ, and node content are validated separately but are not counted as shape variants.

**G\_admissible(Σ)** — the set of full candidate graphs G whose `shape(G) ∈ T_legal(Σ)` and whose predicates, basis-point scores, and canonical planner-provided field map `ν_G : V → PartialRecord(F(λ_V(v)))` satisfy Φ, scoring, F, and L admission rules. DODGE makes no finiteness claim for G\_admissible because predicate constants and content may range over non-finite semantic domains even though κ itself has a finite canonical domain.

**G\_candidate** — a specific graph admitted by the Compiler’s static pass. Formally, `compile_static_Σ : G_raw ⇀ G_admissible(Σ)` is a partial function and `G_candidate = compile_static_Σ(G_proposed)` when defined. On failure it emits a typed rejection. Compiler.static does not silently delete illegal planner output to manufacture an admissible graph. G\_candidate contains candidate nodes, typed edges, planner-provided fields ν, confidence scores, and activation conditions.

**G\_approved** — the human-ratified graph compiled into an immutable Governed Graph Commit C. G\_approved is the topology the Executor is allowed to consume. Its exact root set V\_root ⊆ V is commit-bound; Ψ (psi) authorizes its types and cardinality, every root has E\_exec indegree zero, and non-root components with E\_exec indegree zero are illegal.

**G\_eligible(r)** — the predicate-induced execution subgraph for run r under a total per-activation-edge decision context K\_r. For every `activates` edge e = (u, v), K\_r(e) is either `VALUE(source_ref_e, x_e)`, where source\_ref\_e binds an admitted source record and x\_e is the exact typed projection required by the already-committed ρ(e), or `SOURCE_INELIGIBLE`. Let V\_eligible be the least set containing V\_root and admitting a non-root node v iff every incoming `requires` or `derives_from` predecessor is in V\_eligible and every incoming activation edge carries `VALUE(source_ref_e, x_e)` whose source is in V\_eligible and whose predicate evaluates true; `SOURCE_INELIGIBLE` makes that edge false without evaluating ρ. Let E\_eligible contain exactly those e = (u, v) ∈ E\_exec whose endpoints are in V\_eligible and satisfy `λ_E(e) ∈ {requires, derives_from} ∨ (λ_E(e) = activates ∧ K_r(e) = VALUE(source_ref_e, x_e) ∧ eval(ρ(e), x_e) = true)`. Then G\_eligible is `(V_eligible, E_eligible, λ_V|V_eligible, λ_E|E_eligible, ρ|E_eligible)`; E\_audit is not part of the eligible execution subgraph. Eligibility is a function only of C and a total, consistency-valid K\_r, independent of whether a worker later succeeds or fails.

**V\_ready(r, t)** — the time-indexed set of nodes whose eligibility decision is resolved true from the append-only partial context K\_{r,t}, and whose incoming `requires` and `derives_from` predecessors have reached `COMPLETED` by time t. Declared roots and nodes with no incoming `activates` edge can become ready before K\_r is total. An activated target is resolved SKIPPED if any incoming decision is `SOURCE_INELIGIBLE` or any available `VALUE` makes its predicate false; it can become ready only after every incoming activation decision is `VALUE`, every predicate evaluates true, and all mandatory predecessors are complete. Because decisions are append-only and E\_exec is a DAG, readiness decisions are monotone and `V_ready(r,t) ⊆ V_eligible(r)` once K\_r is total. Readiness controls release to a Worker; it does not alter final eligibility.

**V\_executed(r)** — `{v ∈ V_eligible(r) | status_r(v) = COMPLETED}`. For every `v ∈ V_executed(r)`, `successful_attempt_r(v)` is the unique execution attempt whose authoritative `OUTPUT_ADMITTED` event established terminal COMPLETED status for v in run r. **G\_executed(r)** is the subgraph of G\_eligible(r) induced by V\_executed(r). Completion depends on runtime reliability, timeouts, worker failures, and retries; those concerns are separate from replay equivalence.

**SKIPPED nodes** are committed candidates in G\_approved that are not in G\_eligible(r); a skipped source contributes `SOURCE_INELIGIBLE` decisions to its outgoing activation edges and is not an incomplete-context failure. **FAILED nodes** are nodes released for execution but not completed. **BLOCKED nodes** are nodes that cannot become ready because an incoming `requires` or `derives_from` predecessor failed. `ACTIVATION_CONTEXT_INCOMPLETE` is the terminal run condition in which an *eligible* activation-source node fails, is blocked, or finishes without emitting a field required by ρ; the affected targets are not released, final G\_eligible is undefined for that run, and P-ERE does not apply. These distinctions are load-bearing: replay claims concern final G\_eligible under total K, scheduling concerns staged V\_ready, and reliability claims concern G\_executed.

**Relations.** For a run with defined final G\_eligible, G\_executed(r) ⊆ G\_eligible(r) ⊆ G\_approved. At approval, V\_approved ⊆ V\_candidate and E\_approved ⊆ E\_candidate; labels and predicates may differ only under the material-edit rules of §3.9. G\_candidate ∈ G\_admissible and `shape(G_candidate) ∈ T_legal`; G\_proposed is not generally admissible.

#### What DODGE claims — precisely

- **P-HALIGN — Hypothesis-Aligned Admission:** No Intent reaches Plan, Compile, or Execute without an admitted alignment record bound to the active human-ratified `H_set`; low match requires a human-controlled amendment or exact-Intent exception
- **P-BLTS — Bounded Legal Topology Space:** |T\_legal(Σ)| < ∞ under the finite-slot assumptions of §4.2
- **P-CTI — Commit Topology Invariance:** Fixed GGC → graph-closed Executor preserves `top(C) = (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ)`
- **P-ERE-A — Strict Replay Equivalence (Mode A):** Pre-committed K → G\_eligible(r₁) = G\_eligible(r₂)
- **P-ERE-B — Practical Replay Equivalence (Mode B):** Replay-logged K → G\_eligible(r₁) = G\_eligible(r₂) under replay
- **P-CADM — Compiler Admissibility:** All accepted C satisfy declared structural constraints
- **P-OUT — Runtime Output Admissibility:** Worker outputs are admitted only if they satisfy the committed field schema and L bounds
- **P-EDGE — Edge Semantic Biconditional:** ρ(e) ∈ Φ iff λ\_E(e) = activates; ρ(e) = ⊤ iff λ\_E(e) ∈ {requires, derives\_from}
- **P-AUD — Auditability:** Every validated execution trace admitted through the trusted audit channel maps to one C with verifiable α and γ, except with negligible hash-collision probability
- **P-IMM — Commit Immutability, Persistence, and Anti-Rollback:** commit identity detects content modification, and the commit-store plus lifecycle-registry contracts reject overwrite, deletion, and rollback
- **T4a — Inter-stage Acyclicity:** Stage-forward edges imply acyclicity of the inter-stage subgraph
- **T4b — Bounded M:N:** |E(R)| ≤ min(max\_out · B\_max(aᵢ), max\_in · B\_max(aⱼ)) for the source and target types aᵢ, aⱼ of R, over any T ∈ T\_legal (proved in §4.7). For a single graph the per-instance corollary |E(R)| ≤ min(max\_out · |V\_source|, max\_in · |V\_target|) follows immediately, since |V\_source| ≤ B\_max(aᵢ) and |V\_target| ≤ B\_max(aⱼ)

**What DODGE does not claim.** Alignment proves consistency with the user’s declared `H_set`, not market truth, product quality, or strategic merit. The same Intent I need not produce the same G\_candidate or G\_approved across runs. The Planner is AI-driven, and human approval varies by context. Under P-HALIGN, the conforming-Executor, P-AUD, and P-IMM assumptions, the approved topology and effect scope are the only ones admitted for that commit, and admitted runs remain auditable to I and `H_set`.

### 3.2 The Core Architectural Claim

Before presenting the governance stack, the paper’s central architectural claim must be stated precisely — because it is routinely confused with a weaker claim.

**The weak claim (not this paper).** Topology invariance. A fixed graph stays fixed. Any workflow engine, any frozen JSON configuration, any hardcoded DAG achieves this. It is not a contribution.

**The strong claim (this paper).** Enforced production of a hypothesis-aligned, topology-invariant, scope-bound artifact in a conforming DODGE implementation. Open-ended AI planning is unavailable until Intent passes the `H_set` alignment gate, and planner output is not executable by the graph-closed Executor. It must be transformed — through registered route and task choice, domain and artifact-schema bounds, cardinality and effect-scope constraints, scoring, adversarial triage, human ratification, and compiler validation — into a Governed Graph Commit. Only a valid GGC is admissible.

The distinction is architectural, not definitional:

> Most systems achieve invariance by **removing freedom at execution time.** DODGE achieves invariance by **forcing all freedom to be expressed, bounded, and ratified before execution.**

This is the architectural contribution. The three forbidden paths are:

```text
Planner → Executor                          FORBIDDEN
Human Approval → Executor (uncompiled)      FORBIDDEN
Runtime Agent → New Topology                FORBIDDEN
LOW_MATCH Intent → Planner                  FORBIDDEN
OutcomeBundle → Executor                    FORBIDDEN

Legal path only:
Intent → H_set alignment → Planner → G_proposed → Compiler.static → G_candidate
       → Triage → β → HITL → α → Compiler.full → γ → GGC → Executor
       → OutcomeBundle
```

The GGC is not merely an artifact. It is the **sole admissible input to a conforming graph-closed Executor**. The Compiler does not merely validate a graph — it materializes the only form in which AI-generated product-hypothesis topology is admitted at that boundary. No valid GGC, no governed execution. Every admitted execution trace is grounded in a specific committed topology.

No novelty is claimed in graphs, compilers, attestation, replay, or HITL individually; the contribution is their L3 conjunction.

**Policy vs Physics.** A disciplined developer can build a topology-invariant execution graph in LangGraph today — by hardcoding nodes and withholding mutation APIs from agents. Topology invariance then remains a convention maintained by developer discipline. In a conforming DODGE implementation, topology invariance is an admission precondition: the Executor accepts only a valid GGC and exposes no topology-mutation capability. The distinction is between a policy an application upholds and a capability boundary the system enforces.

**Executor boundary clarification.** A possible objection is: “If the executor just checks a file format, that’s a parser not an architecture.” The defense is precise: the Compiler does not check a file format. The governed boundary validates the entire authority and epistemic chain — admitted Intent and active `H_set`; human-controlled exception when applicable; registered route and standard tasks; typed artifact schemas and effect scope; domain legality; population and relationship scope; activation language; planner-provided field scope; runtime Worker-output scope; human attribution; and Compiler attestation. Any failure blocks production or output admission. The Executor’s hash verification is the final link, not the whole chain.

### 3.3 The Governance Stack

DODGE resolves ungoverned AI execution through a five-tier governance stack. Each tier either constrains the legal space or enforces a guarantee at a specific transition. Together they produce the pipeline:

```text
Intent I
    ↓
Pre-Plan H_set Alignment Check     → ALIGNED / LOW_MATCH / EXCEPTION_APPROVED
    ↓ admitted only
Plan: Route + Standard Tasks       → chooses typed artifacts, graph, and effect scope
    ↓
Tier 1: Domain Schema + F/L       → defines types, order, fields, and content scope
Tier 2: Population/Cardinality    → bounds T_legal(Σ), populations, and relationship multiplicity
    ↓
Planner + Tier 3: Scored Edges    → enumerates V, E, ν, κ, and typed predicates in Φ
    ↓ G_proposed
Compiler.static (partial admission)
    ↓ G_candidate ∈ G_admissible; shape(G_candidate) ∈ T_legal
    ↓
Tier 4: Adversarial Triage        → confidence verdict β on G_candidate
    ↓
Tier 5: HITL Mandatory Approval   → produces G_approved (human-ratified, α-signed)
    ↓
Compiler.full → γ                 → validates and attests
    ↓
Governed Graph Commit C (GGC)     → sole admissible executor input
    ↓
Graph-Closed Executor             → derives G_eligible(r), releases V_ready(r,t), and records G_executed(r)
    ↓
OutcomeBundle O_r                 → records typed outputs and evidence; grants no new authority
```

### 3.4 Tier 1 — Domain-Method Schema (with Field-Level Scope Bounds)

A domain-method schema defines a finite, totally ordered set of stages S = {s₁, s₂, …, sₙ} where sᵢ < sⱼ iff i < j. Each stage sᵢ admits a finite set of artifact types Aᵢ. The complete type universe is A = ⋃ᵢ Aᵢ. Stage assignment f: A → S maps each artifact type to exactly one stage. For each a ∈ A, F(a) is a finite, acyclic, nonrecursive typed field schema. `Path(F(a))` is the finite set of addressable nested field paths induced by F(a), including collection-element projections.

Legal inter-stage edges are stage-forward: (u, v) ∈ E\_legal only if f(type(u)) < f(type(v)). This enforces *inter-stage* acyclicity structurally. Intra-stage execution edges are permitted with `requires`, `derives_from`, or `activates` semantics and must pass a secondary topological sort within the stage. Schema-authorized `evidence_for` edges may be same-stage or stage-forward, remain audit-only, and are excluded from scheduler acyclicity and reachability.

**Edge semantic types.** Not all edges carry the same meaning. DODGE defines four legal edge semantic types, encoded in λ\_E:

```text
derives_from  — artifact B is derived from artifact A as input
                (e.g. PainPriority derives_from Pain)

evidence_for  — artifact A provides evidence supporting artifact B
                (e.g. InterviewNotes evidence_for PersonaProfile)

activates     — edge carries activation condition φ ∈ Φ;
                B executes only if φ evaluates true against A's output
                (e.g. PainPriority activates ProductFeatureUJS)

requires      — B cannot execute unless A is COMPLETED;
                mandatory dependency, no activation condition
                (e.g. CustomerDiscovery requires PersonaProfile)
```

The edge set is partitioned: **E\_exec = activates ∪ requires ∪ derives\_from** (scheduler-visible) and **E\_audit = evidence\_for** (audit-only). `derives_from` semantically means “B takes A’s output as input”; that is an input dependency, and the scheduler must respect it. It behaves like `requires` for scheduling (no φ; mandatory predecessor) while retaining its distinct semantic label for type-checking purposes: the Compiler validates that B’s input schema accepts A’s output schema. `evidence_for` asserts epistemic support rather than input dependency; same-stage and stage-forward audit edges are admitted only when declared in R, and neither case affects scheduling or establishes Executor reachability.

**Field-level scope bounds L.** Cardinality bounds cap *node count*, not *node-content size*. Without field-level bounds, the Planner can pack unbounded scope into a single node’s outputs (one Feature node carrying 200 features in a list, one Persona description being 50 pages of free text). The “scope creep is a compiler error” claim is therefore false unless field-level limits are enforced. Σ includes a field-level scope-bound function:

```text
L : (a ∈ A, path ∈ Path(F(a))) → ScopeBound
ScopeBound = { max_collection_length : ℕ ∪ {⊥}, max_string_length : ℕ ∪ {⊥}, closed_enum : FiniteSet ∪ {⊥} }
```

For every variable-length collection path, `max_collection_length` MUST be a finite natural number; for every variable-length string path, `max_string_length` MUST be a finite natural number. A non-applicable component is denoted mathematically by `⊥` and encoded canonically as explicit JSON null. A conforming Σ therefore binds every variable-length typed path to a finite scope bound; recursive field schemas and unbounded variable-length paths are not admitted.

L is enforced at **two distinct gates**:

- **Compile-time enforcement (Compiler.static).** The Compiler validates L against Planner-provided fields in G\_proposed; any field exceeding its declared L causes rejection before G\_proposed becomes G\_candidate.
- **Runtime enforcement (Executor at output write).** When the Worker emits a node output to the blob store, the Executor validates the output against the same L bounds *before* writing the content\_hash to the trace. If runtime L is violated, the node transitions to FAILED with a `FIELD_SCOPE_BOUND_EXCEEDED_AT_RUNTIME` event. Mandatory downstream `requires`/`derives_from` dependents whose eligibility is already resolved remain eligible but are marked BLOCKED and are never released. Any activation target requiring a rejected output value produces `ACTIVATION_CONTEXT_INCOMPLETE` instead of a partial eligibility result. This is the P-OUT runtime-output property, separate from Compiler admissibility P-CADM.

Without runtime enforcement, scope creep merely waits for the Compiler to leave: a Worker LLM emits 200 acceptance\_criteria for a single Feature node, the topology is structurally legal, but the semantic scope explodes at output time. Two-gate enforcement closes this. Cardinality bounds cap topology at compile time; L bounds cap content at both compile time (planner-provided fields) and runtime (worker-generated fields). Together, scope creep — whether by node count, planner-provided field size, or runtime-generated field size — is a structural failure, never a silent overflow.

**Encoded domain-method schema as ratified structural law.** Decades of product management practice encode hard-won knowledge about what order things must happen in. Customer discovery before feature definition. Pain validation before solution design. Market sizing before channel investment. The domain-method schema makes this knowledge a structural property of every execution — not something a PM must remember to enforce, and not something an AI agent can bypass via prompt interpretation. **A domain-method schema is a ratified encoding of a domain method** — written by humans, subject to revision as practice improves, enforceable as structural constraint within the framework. As with all law: human-written, improvable, replaceable when empirical evidence demands it.

**PM example (NBM4 instantiation).** Stage 2 (Customer Discovery) admits PersonaProfile, EmpathyMap, PainAnalysis, and Pain. Stage 3 (Value Suggestion) admits PainPriority, ProductFeatureUJS, FeaturePriorities, and ValueMap. A ProductFeatureUJS node at Stage 2 is a Compiler rejection. A PainPriority node at Stage 2 is also a Compiler rejection. Within Stage 3, a FeaturePriorities node may carry a `requires` edge from two ProductFeatureUJS candidates — a legal intra-stage dependency validated by secondary sort. A PersonaProfile node whose `description` path exceeds `L(PersonaProfile, description).max_string_length` is rejected for field-level overflow.

### 3.5 Tier 2 — ERD Cardinality

For every artifact type a, let `V_a = {v ∈ V | λ_V(v) = a}`. Σ declares first-class population bounds `B_min(a)` and `B_max(a)` with `0 ≤ B_min(a) ≤ B_max(a) < ∞`; the Compiler requires `B_min(a) ≤ |V_a| ≤ B_max(a)`. Mandatory artifact types are therefore explicit and machine-checkable. For each relationship R: aᵢ → aⱼ where f(aᵢ) < f(aⱼ) (or intra-stage with `requires`, `derives_from`, or `activates`), Σ declares c\_candidate(R). For each scheduler-visible relationship R\_exec whose semantic is `requires`, `derives_from`, or `activates`, Σ also declares c\_eligible(R\_exec). Each function returns (min\_out, max\_out, min\_in, max\_in):

- **c\_candidate(R):** Bounds on G\_candidate edges — validated by the Compiler against G\_candidate before commit.
- **c\_eligible(R\_exec):** Per-endpoint runtime postconditions on E\_eligible. Predicates select E\_eligible; after a total, consistency-valid K yields final G\_eligible, the Executor validates every eligible source’s outgoing degree and every eligible target’s incoming degree. If activation context is incomplete, G\_eligible is undefined and no c\_eligible conclusion is drawn.

**M:N treatment.** Stage ordering gives acyclicity of the inter-stage subgraph and one-directional edges. It does not eliminate M:N relationships. Under the NBM4 PersonaProfile → JTBDAsIs relationship, one PersonaProfile may derive multiple JTBDAsIs nodes and one JTBDAsIs node may be supported by multiple PersonaProfiles. By the per-instance corollary of T4b (§4.7), |E(R)| ≤ min(max\_out · |V\_source|, max\_in · |V\_target|). M:N is governed, not eliminated.

**Artifact presence and relationship minima are distinct.** `B_min(a)` determines whether an artifact type must be instantiated. Relationship minima do not create nodes: min\_out is checked for each present source instance and min\_in for each present target instance, subject to the relationship’s Ψ conditions. An inactive alternative root can therefore have B\_min = 0 without weakening the selected profile’s mandatory root.

**PM example.** PainPriority → ProductFeatureUJS declares c\_candidate = (0, 12, 1, 1) and c\_eligible = (0, 12, 0, 1). One PainPriority node may propose 0 to 12 candidate Feature nodes; each proposed Feature references exactly one PainPriority. Zero may be eligible when every activation predicate is false, so ordinary candidate skipping does not trigger cardinality collapse. The upper bound 12 derives from NBM4 domain practice — declared, not arbitrary. A PM whose Planner proposes 13 candidate Features receives a Compiler rejection citing the violated candidate cardinality.

#### 3.5.1 Runtime Cardinality Violation Protocol

After K is total and final G\_eligible is defined, the Executor computes `deg_out_Eeligible(u, R)` for every eligible source endpoint u and `deg_in_Eeligible(v, R)` for every eligible target endpoint v. A degree below its minimum is a `COLLAPSE`; a degree above its maximum is an `OVERFLOW`. On either violation, the Executor MUST:

1. Halt the affected subgraph
2. Log a `RuntimeCardinalityViolation` event in the trace, including subtype, relationship, endpoint, direction, required bound, observed degree, relevant K decisions, and affected nodes
3. Emit a supersession-request event referencing id(C) — the GGC requires a new candidate pipeline run, not silent continuation

This is a runtime exception condition not silently masked. c\_eligible bounds are runtime postconditions in Mode B/C. `ACTIVATION_CONTEXT_INCOMPLETE` yields no final G\_eligible and therefore neither satisfies nor violates c\_eligible.

### 3.6 Tier 3 — Scored Edges and Φ

The Planner receives intent I and proposes graph shape, scores, and predicates under Tiers 1–3. Compiler.static admits the whole proposal as G\_candidate only when it is a member of G\_admissible whose graph-shape projection is in T\_legal. Candidate type populations must satisfy B\_min/B\_max and relationship edges must satisfy c\_candidate. Each `activates` edge carries a typed activation condition φ evaluated at runtime to determine whether the candidate node enters G\_eligible(r).

**Activation condition language Φ.** A formal grammar follows in Appendix A. The grammar in brief:

```text
segment     ::= attr_name | attr_name "[*]"
field_path  ::= "source" "." "outputs" "." segment ("." segment)*
constant    ::= string_literal | integer_literal | decimal_literal | boolean_literal | enum_literal
typed_atom  ::= field_path op constant
count_agg   ::= "count" "(" field_path op constant ")" op nat
                                                             -- bounded aggregation
                                                             -- over one finite typed array projection
φ           ::= typed_atom | count_agg | "(" φ ")" | φ∧φ | φ∨φ | ¬φ
op          ::= ≥ | ≤ | = | > | <
```

Φ is **total, pure, side-effect-free, strictly typed**, and **bounded-aggregation-extended**. Types are assigned by Compiler judgments over F; type annotations are not tokens in the concrete predicate syntax. No LLM calls. No external state. No clock. No randomness. Every expression in Φ is decidable and terminating. A `count_agg` is well-typed only when the projected collection path has type `List[T]`, its comparison constant has type T, the aggregation result has type Nat, and the projected collection path has a finite `L(...).max_collection_length`. Thus “at least 3 persona matches share this pain” is expressible as `count(source.outputs.personaPainMatches[*].sharesCurrentPain = true) ≥ 3` without breaking decidability. **Predicate scope is restricted to the immediate source node’s output fields** (Option A): Φ does not reference transitive predecessors. Aggregation across multiple upstream nodes must be lifted into the source node’s output computation.

The Compiler validates all activation conditions are well-typed members of Φ — rejecting conditions that reference undefined fields, mismatch types, reference non-immediate predecessors, or contain constructs outside the language.

**What scored edges do not claim.** If activation condition fields are computed by LLM during execution, two runs of the same G\_approved may produce different G\_eligible(r) because field values differ. P-CTI still holds — G\_approved topology is unchanged. P-ERE-B holds under replay only if activation values are logged to a content-addressed activation log (see §3.7 K and Modes). This is not a defect; it is the precisely stated boundary between topology governance and content governance.

**PM example.** Each PainPriority → ProductFeatureUJS edge carries `source.outputs.priorityScore ≥ 15`. Because each source node represents one prioritized pain, feature candidates activate independently. “The AI should assess whether this pain warrants a feature” is not a valid Φ expression and is rejected at compile time.

### 3.7 Activation Context K and Three Operational Modes

P-ERE depends on the activation context K — the valuation of fields referenced by predicates in ρ. Three operational modes are distinguished:

| Mode | K source | Replay claim | When to use |
| --- | --- | --- | --- |
| A — Pre-committed | Every source-bound activation-edge decision (VALUE or SOURCE_INELIGIBLE) committed into C before execution | P-ERE-A: G_eligible(r₁) = G_eligible(r₂) for runs satisfying the Mode A activation-integrity assumptions | High-stakes commits, regulatory audit, full replay required |
| B — Replay-logged (default) | Activation-edge decisions produced at runtime and written to content-addressed K_log; replay reads them from K_log | P-ERE-B: G_eligible(r₁) = G_eligible(r₂) under replay from K_log | Realistic default — practical for most product-hypothesis work |
| C — Re-evaluated | Activation values recomputed via LLM on each run; not logged | No replay claim — G_eligible may diverge across runs | Exploratory only; not recommended for governed production |

Every C\_plus (the full implementation commit model, defined in §3.10) binds an activation-control record χ:

```text
χ = {
  activation_mode: A | B | C,
  K_commitment: content_hash | null,
  replay_policy_hash: content_hash
}
```

For e = (u, v), `VALUE(source_ref_e, x_e)` carries `source_ref_e = {origin_kind, origin_id, source_node_id, source_output_hash, source_admission_event_hash, projection_paths, projection_hash}` and MUST satisfy `source_ref_e.source_node_id = u`. `origin_kind` is `PRECOMMITTED` in Mode A or `RUNTIME_OUTPUT` in Mode B/C; `origin_id` is respectively a precommit-admission identifier or a source execution-attempt identifier. `projection_paths` is the canonical ordered set `refs(ρ(e))`, x\_e must equal the exact projection of the admitted source output at those paths, and `projection_hash = H(canonical({projection_paths, values: x_e}))`. The referenced source record must conform to F and L, and its admission-event hash and source-output hash must verify. Mode A admits exactly one PRECOMMITTED source record per source node u, so every outgoing VALUE decision for u MUST share one `(origin_id, source_output_hash, source_admission_event_hash)` tuple even when edge-specific projections differ. Mode B/C applies the same single-origin invariant to every set of outgoing VALUE decisions derived from one source execution attempt. Because ρ is already bound in top(C) and C\_payload, K records values and provenance rather than redefining predicates.

Mode A requires a non-null K\_commitment resolving to a total, consistency-valid per-edge decision context K; exactly one PRECOMMITTED source record and its admission proof for each activation-source node are inside that commitment. If a Mode A run recomputes or executes u, the admitted output hash MUST equal u’s sole precommitted source\_output\_hash; a mismatch terminates the run as `ACTIVATION_INTEGRITY_MISMATCH`, leaves affected targets unreleased, and yields no G\_eligible or P-ERE conclusion for that run. Mode B uses `K_commitment = null` at commit time and requires a replay policy that writes exactly one terminal decision for every activation edge to K\_log; the trace later binds the resulting K\_log hash. `VALUE(source_ref_e, x_e)` is permitted only when u is eligible, `source_ref_e.source_node_id = u`, and the source binding and exact projection verify; `SOURCE_INELIGIBLE` is permitted only when u is ineligible. Mode C uses `K_commitment = null` and a replay policy that explicitly denies P-ERE.

**Mode B bootstrapping.** Runtime activation does not wait for a globally total K before any work begins. The Executor follows E\_exec topological order: (1) it releases V\_root and other nodes with no unresolved incoming activation predicates once their mandatory predecessors are complete; (2) when a node is resolved ineligible, it appends `SOURCE_INELIGIBLE` for every outgoing activation edge without evaluating those predicates; (3) when an eligible activation-source execution attempt’s F/L-admitted output establishes terminal COMPLETED, the Executor designates that attempt `successful_attempt_r(u)` and appends `VALUE(source_ref_e, x_e)` for each outgoing edge using that one authoritative admitted output hash and the exact edge-specific `refs(ρ(e))` projection before considering targets; (4) a target is resolved skipped if any incoming decision is `SOURCE_INELIGIBLE` or any predicate evaluates false, and it enters V\_ready only when all incoming decisions are `VALUE`, all predicates evaluate true, and all mandatory predecessors are complete; (5) after every activation edge has one terminal decision, K\_r is total and final G\_eligible(r) is derived; (6) if an eligible source fails, is blocked, omits a required field, or lacks a valid source binding, the run records `ACTIVATION_CONTEXT_INCOMPLETE`, leaves affected targets unreleased, and makes no P-ERE claim. The DAG and immediate-source restriction make this staged decision process well-founded, including chains in which an activation source is itself skipped.

**Mode B is the realistic default operating mode** and the abstract states this explicitly. P-ERE-A is the strict-determinism mode; P-ERE-B is the practical mode; Mode C is acknowledged and explicitly forfeits the replay claim. K\_log is a content-addressed append-only structure; its hash is included in the trace `τ_r` (tau sub r) so that replay reads from the exact bound activation context.

### 3.8 Tier 4 — Adversarial Triage

Before G\_candidate reaches human review, a structured three-role panel evaluates it:

- **Advocate** — argues for the plan’s scoring logic, threshold choices, cardinality decisions, and proposed topology. Surfaces the strongest case for the plan as presented.
- **Skeptic** — challenges thresholds, identifies missing nodes, questions cardinality choices, flags boundary cases, and identifies where the domain method may be underserved.
- **Judge** — produces a confidence verdict over G\_candidate: Adopt | Trial | Watch | Reject.

#### Verdict semantics

- **Reject:** G\_candidate returns to Planner. PM never reviews a plan the triage panel deems structurally unsound.
- **Adopt:** G\_candidate proceeds to HITL. The panel records high confidence in the plan.
- **Trial:** Proceeds to HITL with flag — moderate confidence, specific concerns attached.
- **Watch:** Proceeds to HITL with flag — low confidence; the PM should scrutinize specific elements.

The triage verdict β travels with G\_candidate into HITL as immutable attached metadata. PM sees the verdict and the specific concerns that produced it.

**Triage diversity and pin-resolution requirement.** A panel of three roles all instantiated as the same model is at risk of being a rubber-stamp panel. The triage panel MUST include at least two distinct model families and at least two distinct prompt families. σ is the content-addressed policy-bundle identifier; the Compiler first resolves and hash-verifies `Π_σ = ResolvePolicyBundle(σ)` as defined in §3.10, then applies `Π_σ.triage_policy`. β\_payload carries a role\_config with one Advocate, Skeptic, and Judge entry, each containing `model_pin_ref`, `prompt_pin_ref`, and `signer_key_id`. Every pin reference MUST resolve to an immutable entry in μ. The Compiler derives family membership from those pinned entries and validates the concrete role configuration against that resolved policy. This avoids duplicating version metadata while making the exact panel configuration verifiable.

**What adversarial triage claims.** Triage is a **confidence filter**, not a graph-theoretic guarantee. It does not further bound T\_legal. It is intended to reduce the probability that a structurally valid but semantically unsound G\_candidate reaches human approval; H1 and H2 test that intended effect. This is an engineering hypothesis, not a mathematical guarantee.

### 3.9 Tier 5 — HITL Mandatory Approval

Human-in-the-loop approval is a **structural compile gate**, not a configurable option. The Compiler will not produce a GGC from any G\_candidate without a valid human approval record α. Removing HITL is a compile-time admission rejection — enforced structurally, not by policy convention.

The PM reviews G\_candidate in full: all candidate nodes, types, stages, activation conditions, scores, preview-projected eligible/ineligible outcomes under any supplied preview values, adversarial triage verdict β, attached concerns, and proposed G\_approved topology. `SKIPPED` is reserved for a committed runtime candidate excluded from final G\_eligible under total K. The PM approves, adjusts within c\_candidate bounds, or rejects and triggers re-planning.

**Material edit taxonomy.** Edits are governed by a three-class taxonomy:

| Edit class | Definition | Compiler behavior |
| --- | --- | --- |
| Structural | Add/remove node; add/remove edge; change edge type | Re-triage REQUIRED; new β bound to new G_candidate hash |
| Predicate-structure | Add conjunct/disjunct to φ; new field path; change op | Re-triage REQUIRED |
| Predicate-value | Change constant in φ within a pre-declared safe-range; predicate structure unchanged | Re-validation pass only; no full re-triage; PM edit logged |

Predicate-value changes within a declared safe range are non-material when the triage panel reviewed *the range*, not a single value. **Safe-range declarations are part of β\_payload.** The PM declares safe\_ranges in the triage\_packet *before* the three-role panel evaluates G\_candidate. The Advocate and Skeptic then attest role-bound statements that bind their report hashes to the exact candidate and triage context; the Judge signs the canonical β\_payload containing those statements, the verdict, and the reviewed safe ranges. All three attestations are required. The PM cannot retroactively widen a safe range to legitimize a post-triage edit. Threshold adjustments inside the panel-reviewed range during HITL are non-material; adjustments outside the range are material and trigger a new triage run.

```text
triage_packet (canonical input to three-role panel):
  g_candidate_hash:  sha256_canonical
  safe_ranges:       { predicate_id → [min, max] }   # declared before panel review
  triage_policy_hash: must equal H(canonical_json(Π_σ.triage_policy))

role_config:
  advocate: { model_pin_ref, prompt_pin_ref, signer_key_id }
  skeptic:  { model_pin_ref, prompt_pin_ref, signer_key_id }
  judge:    { model_pin_ref, prompt_pin_ref, signer_key_id }

advocate_report_hash = H(canonical(advocate_report))
skeptic_report_hash  = H(canonical(skeptic_report))
triage_context_hash  = H(canonical({g_candidate_hash, safe_ranges,
                                    role_config, triage_policy_hash}))
advocate_statement_hash = H(canonical({role: "advocate",
                                       report_hash: advocate_report_hash,
                                       triage_context_hash}))
skeptic_statement_hash  = H(canonical({role: "skeptic",
                                       report_hash: skeptic_report_hash,
                                       triage_context_hash}))
advocate_attestation = Sign_advocate(advocate_statement_hash)
skeptic_attestation  = Sign_skeptic(skeptic_statement_hash)

β_payload (signed by Judge):
  verdict, concerns, judge_rationale
  advocate_report_hash, skeptic_report_hash
  advocate_statement_hash, skeptic_statement_hash, triage_context_hash
  g_candidate_hash:  must match triage_packet.g_candidate_hash
  safe_ranges:       must match triage_packet.safe_ranges (panel reviewed these ranges)
  role_config:        every model/prompt reference must resolve in μ
  timestamp

judge_attestation = Sign_judge(H(canonical(β_payload)))
β = { β_payload, advocate_report, skeptic_report,
      advocate_attestation, skeptic_attestation, judge_attestation }

α.payload binds h_pre = H(C_payload), which includes β; the human signs H(canonical_json(α.payload)), and γ signs H(concat(C_payload, canonical_signature_envelope(α))).
The safe_ranges field is therefore bound under both human and Compiler attestation.
```

Verification requires the canonical report hashes to equal the corresponding β\_payload hashes; the recomputed triage\_context\_hash to bind the exact candidate hash, reviewed safe ranges, role configuration, and `Π_σ.triage_policy`; each role-tagged statement hash to match β\_payload; each Advocate/Skeptic attestation signer to equal that role’s signer\_key\_id; the Judge signer to equal `role_config.judge.signer_key_id`; and all three keys to be authorized for those roles under that resolved, hash-verified policy.

**Approval record α.** Let `h_pre = H(C_payload)`, where `C_payload = canonical_json({intent_ref, hypothesis_set_ref, alignment_record, route_id, task_refs, effect_scope, V, V_root, E_exec, E_audit, λ_V, λ_E, ν, ρ, κ, β, σ, μ, χ, supersedes_id, extensions_hash})`, and define the structured object `α_payload = {h_pre, signer_key_id, trust_manifest_hash}`, where trust\_manifest\_hash resolves under `Π_σ.trust_history_root`. The human produces `user_signature = Sign_user(H(canonical_json(α_payload)))`. A timestamp authority admitted by `Π_σ.approval_timestamp_policy` computes `timestamp_subject = H(concat(canonical_json(α_payload), canonical_signature(user_signature)))`, defines the structured object `timestamp_statement = {timestamp_authority_id, timestamp_subject, trusted_signed_at}`, and produces `timestamp_signature = Sign_timestamp_authority(H(canonical_json(timestamp_statement)))`. The stored α object is `{payload: α_payload, signature: user_signature, timestamp_proof: {statement: timestamp_statement, signature: timestamp_signature}}`. Verification checks both signatures over those canonical byte encodings, exact timestamp\_subject equality, timestamp-authority authorization, and signer authorization at `α.timestamp_proof.statement.trusted_signed_at` under the exact trust manifest. The timestamp proof therefore authenticates the exact human approval signature and claimed historical time without a hash cycle. h\_pre excludes α and γ by construction; γ subsequently signs `H(concat(C_payload, canonical_signature_envelope(α)))`, and id(C) binds C\_payload plus the canonical encodings of α and γ.

**What HITL claims.** For a specific G\_approved, this PM at this moment ratified this topology. This is the strongest governance guarantee DODGE makes. It does not prove two PMs produce the same G\_approved for the same intent — human judgment varies by context, experience, and market conditions. **It proves that AI execution topology is a human decision, not an AI side-effect.** The PM is the navigator. The framework is the instrument panel.

### 3.10 The Governed Graph Commit

The GGC is defined at two precision levels:

```text
Minimal topology/schema model:
C_min = (intent_ref, hypothesis_set_ref, alignment_record, route_id, task_refs,
         effect_scope, V, V_root, E, λ_V, λ_E, ρ, α, σ, μ)

Implementation/admissibility model:
C_plus = (intent_ref, hypothesis_set_ref, alignment_record, route_id, task_refs,
          effect_scope, V, V_root, E_exec, E_audit, λ_V, λ_E, ν, ρ, κ,
          β, α, γ, σ, μ, χ, supersedes_id, extensions_hash,
          implementation_extension_map)

Field definitions:
  intent_ref = content-addressed reference to the exact user Intent admitted to Plan
  hypothesis_set_ref = content-addressed reference to the active human-ratified H_set
  alignment_record = pre-Plan decision bound to intent_ref, hypothesis_set_ref,
             evaluator pins, matched hypothesis IDs, score/threshold, and any exact-Intent exception
  route_id = registered route selected by Plan and admitted by Compile
  task_refs = finite ordered references to registered standard tasks used by the route
  effect_scope = finite set of material effects and governed targets authorized for this commit
  V        = node set of G_approved
  V_root   = exact commit-bound root set, V_root ⊆ V
  E        = E_exec ∪ E_audit  (in C_min, partition is implicit)
  E_exec   = execution edges {requires, activates, derives_from} — scheduler-visible
  E_audit  = traceability edges {evidence_for} — audit-only
  λ_V      = node labeling (artifact_type, stage)
  λ_E      = edge labeling (edge_semantic)
  ν        = V → PartialRecord(F(λ_V(v))); canonical planner-provided
             commit-time field values, excluding runtime Worker outputs
  ρ        = E_exec → Φ ∪ {⊤}; ρ(e) ∈ Φ iff λ_E(e) = activates; ρ(e) = ⊤ iff λ_E(e) ∈ {requires, derives_from}
  Score_bp = {0, 1, ..., 10000}; version "basis-points-v1"
  κ        = E_exec → Score_bp  (integer planner confidence per edge;
             0 = 0.0000 and 10000 = 1.0000)
  β        = β_payload plus Advocate/Skeptic reports and all three role attestations;
             β_payload binds report hashes, role-tagged report/context statements,
             verdict, concerns, Judge rationale, g_candidate_hash, safe_ranges,
             role_config, triage_context_hash, and timestamp
  Π        = {domain_schema, route_registry, standard_task_registry,
             artifact_schema_registry, hypothesis_alignment_policy,
             hypothesis_exception_policy, candidate_cardinality_table,
             eligible_cardinality_table, B_min, B_max, complete_field_schema_F,
             field_bounds_L, structural_constraints_Ψ, phi_grammar_version, score_domain_version,
             triage_policy, approval_timestamp_policy, lifecycle_authorization_policy,
             lifecycle_head_policy, trust_history_root, commit_store_policy}
  σ        = H(canonical_json(Π)); content-addressed policy-bundle identifier only
  Π_σ      = ResolvePolicyBundle(σ)
  require  H(canonical_json(Π_σ)) = σ; resolution or hash failure rejects
             where Π_σ.lifecycle_head_policy binds the authoritative registry_id,
             registry-key trust/rotation policy, freshness rule, maximum clock skew,
             and offline-checkpoint rule
  μ        = addressable immutable pin map for planner/triage models, prompts,
             compiler/executor binaries, tools, and other versioned dependencies
  χ        = activation-control record (activation_mode, K_commitment, replay_policy_hash)
  supersedes_id = nullable id(C_previous); a non-null value resolves to an
             already-stored, cryptographically valid predecessor whose own resolved,
             hash-verified policy bundle and authenticated latest head authorize supersession
  implementation_extension_map = finite canonical JSON object or null
  extensions_hash = H(canonical(implementation_extension_map)) or null; ship-mlp binds
             additional implementation-specific commit fields through this projection
  C_payload = canonical_json({intent_ref, hypothesis_set_ref, alignment_record,
               route_id, task_refs, effect_scope, V, V_root, E_exec, E_audit,
               λ_V, λ_E, ν, ρ, κ, β, σ, μ, χ, supersedes_id, extensions_hash})
  h_pre    = H(C_payload)
  α_payload = { h_pre, signer_key_id, trust_manifest_hash }
  user_signature = Sign_user(H(canonical_json(α_payload)))
  timestamp_subject = H(concat(canonical_json(α_payload),
                        canonical_signature(user_signature)))
  timestamp_statement = { timestamp_authority_id,
                          timestamp_subject, trusted_signed_at }
  timestamp_signature = Sign_timestamp_authority(
                          H(canonical_json(timestamp_statement)))
  timestamp_proof = { statement: timestamp_statement,
                      signature: timestamp_signature }
  α        = { payload: α_payload, signature: user_signature, timestamp_proof }
  γ        = Compiler attestation; γ = Sign_compiler(
               H(concat(C_payload, canonical_signature_envelope(α))))
```

**Commit identity.** Define:

```text
C_payload  = canonical_json({intent_ref, hypothesis_set_ref, alignment_record,
              route_id, task_refs, effect_scope, V, V_root, E_exec, E_audit,
              λ_V, λ_E, ν, ρ, κ, β, σ, μ, χ, supersedes_id, extensions_hash})
h_pre      = H(C_payload)
α_payload  = { h_pre, signer_key_id, trust_manifest_hash }
user_signature = Sign_user(H(canonical_json(α_payload)))
timestamp_subject = H(concat(canonical_json(α_payload),
                      canonical_signature(user_signature)))
timestamp_statement = { timestamp_authority_id,
                        timestamp_subject, trusted_signed_at }
timestamp_signature = Sign_timestamp_authority(
                        H(canonical_json(timestamp_statement)))
timestamp_proof = { statement: timestamp_statement,
                    signature: timestamp_signature }
α          = { payload: α_payload, signature: user_signature, timestamp_proof }
γ          = Sign_compiler(H(concat(C_payload, canonical_signature_envelope(α))))
id(C)      = H(concat(C_payload, canonical_signature_envelope(α),
                      canonical_signature_envelope(γ)))
transit(C) = (id(C), C_payload, α, γ, implementation_extension_map)
```

where `canonical_json` is a deterministic, unambiguous, injective canonical serialization over the admitted value domain (the ship-mlp reference implementation uses RFC 8785 JSON Canonicalization Scheme), `canonical(x) := canonical_json(x)` is shorthand for the same function, `canonical_signature(s)` is the unambiguous canonical byte encoding of a structured signature object, `canonical_signature_envelope(x) = canonical_json(x)` is the canonical byte encoding of a stored structured attestation envelope such as α or γ, H is a collision-resistant cryptographic hash (SHA-256 or stronger), and `concat(x1, ..., xn)` denotes length-delimited concatenation of byte sequences only. Every `Sign_*` operation returns a structured signature object rather than raw implicit bytes. `ResolvePolicyBundle` is a partial content-addressed lookup: every Compiler and Executor use of a policy field first obtains Π\_σ and verifies `H(canonical_json(Π_σ)) = σ`; resolution or hash failure is fail-closed. In canonical JSON, every schema-declared optional value uses explicit JSON `null`; omission is not equivalent to null, mathematical `⊥` is never serialized literally, non-finite numbers are rejected, and κ values are decimal-free integers in Score\_bp. h\_pre excludes α and γ by construction; the human signs the canonical encoding of α.payload, γ signs C\_payload plus the canonical α envelope, and id(C) binds C\_payload plus the canonical α and γ envelopes. No hash circularity.

**Commit-store contract.** A conforming substrate satisfying `Π_σ.commit_store_policy` exposes `put_once(id(C), transit(C))`, which succeeds only when id(C) is absent, and `get(id(C))`, which returns the identical committed bytes. Overwrite and delete operations are rejected. This substrate-independent append-only/non-overwrite/non-delete invariant gives P-IMM its persistence component; S3-class Object Lock is one possible implementation, not a framework requirement.

**Executor verification.** On load of `transit(C) = (id(C), C_payload, α, γ, implementation_extension_map)`, the Executor verifies:

```text
Π_σ = ResolvePolicyBundle(σ)
H(canonical_json(Π_σ)) == σ                                           # policy-bundle binding
alignment_record.intent_ref == intent_ref                              # exact Intent binding
alignment_record.hypothesis_set_ref == hypothesis_set_ref              # active H_set binding
alignment_record.decision ∈ {ALIGNED, EXCEPTION_APPROVED}              # pre-Plan admission
RegisteredRouteAndTasks(route_id, task_refs, Π_σ)                       # route/task admission
EffectScopeWithinRoute(effect_scope, route_id, task_refs, Π_σ)          # no authority widening
H(concat(C_payload, canonical_signature_envelope(α),
         canonical_signature_envelope(γ))) == id(C)                      # tamper detection
VerifySig_compiler(compiler_pubkey, γ,
 H(concat(C_payload, canonical_signature_envelope(α)))) == true          # compiler attestation
α.payload.h_pre == H(C_payload)                                          # exact payload binding
VerifySig_user(key(α.payload.signer_key_id), α.signature,
               H(canonical_json(α.payload))) == true                     # human attestation
α.timestamp_proof.statement.timestamp_subject ==
 H(concat(canonical_json(α.payload),
          canonical_signature(α.signature)))                             # exact signed approval
VerifyTimestampProof(α.timestamp_proof, Π_σ.approval_timestamp_policy,
 H(canonical_json(α.timestamp_proof.statement)))                         # trusted approval time
AuthorizedAt(α.payload.signer_key_id, α.timestamp_proof.statement.trusted_signed_at,
             α.payload.trust_manifest_hash, Π_σ.trust_history_root)      # historical authority
((implementation_extension_map = null ∧ extensions_hash = null) ∨
 H(canonical(implementation_extension_map)) = extensions_hash)            # extension availability
```

If any verification fails, the GGC is rejected and no adjacency table is constructed. The canonical-form chain keeps `C_payload`, `h_pre`, and the `concat(C_payload, canonical_signature_envelope(α), canonical_signature_envelope(γ))` identity preimage distinct.

**Compiler attestation γ.** γ is a Compiler signature distinct from human approval α. It attests that the Compiler admitted the α-bound payload under the pinned policy. Separate key custody prevents a compromised human key from forging γ or bypassing Compiler admission, but it does not make an authorized human key harmless: an attacker holding such a key can approve a malicious payload that is structurally valid, and an honest Compiler may attest it if every admission rule passes.

#### Trust model and TCB statement

- Compiler keys live in a hardware-isolated trust anchor (HSM, TEE, or equivalent) — separate from any human-held signing key.
- Compiler attestation γ is verifiable by the Executor using a trusted-public-key list resolved through `Π_σ.trust_history_root`.
- A compromised authorized human key can approve a malicious but structurally admissible payload; separate Compiler custody still prevents forging γ or bypassing admission checks.
- A compromised Compiler can produce γ-valid GGCs over arbitrary content; mitigation is HSM/TEE custody, signed Compiler binary, and remote attestation of the Compiler runtime where the threat model warrants.
- Multi-party approval thresholds for high-stakes commits (e.g., 2-of-3 PM signatures on α) are **not** supported by the v9.3 α contract, which binds exactly one `signer_key_id` and one signature (§3.10, A.5) and is enforced as singular by P-CADM step 11. Generalizing α to a signed set with an explicit threshold, and updating the Executor verification step and P-CADM accordingly, is future work.
- See §8.2 for the threat-model limitations explicitly listed as future-work hardening; §7.7.4 records the author-reported closure of the v7.1 key-custody deviation while preserving the separate v9.3 alignment limit.

**Executor hash verification and graph closure.** On load, the Executor:

1. Receives `transit(C) = (id(C), C_payload, α, γ, implementation_extension_map)`
2. Resolves `Π_σ = ResolvePolicyBundle(σ)`, verifies `H(canonical_json(Π_σ)) = σ`, and rejects resolution or hash failure
3. Verifies that the alignment record binds the exact Intent and active `H_set`, has decision `ALIGNED` or `EXCEPTION_APPROVED`, and carries a valid exact-Intent human exception when applicable
4. Verifies that route\_id and task\_refs resolve through the pinned registries and effect\_scope does not exceed their admitted scope
5. Verifies `H(concat(C_payload, canonical_signature_envelope(α), canonical_signature_envelope(γ))) == id(C)` — tamper detection
6. Verifies γ against the Compiler trust anchor — Compiler attestation
7. Verifies `α.payload.h_pre` against C\_payload and verifies α.signature over `H(canonical_json(α.payload))`; recomputes timestamp\_subject from `canonical_json(α.payload)` plus `canonical_signature(α.signature)`; verifies the carried timestamp statement and proof signature over `H(canonical_json(α.timestamp_proof.statement))` and verifies the authority under `Π_σ.approval_timestamp_policy`; then proves that signer\_key\_id was authorized at `α.timestamp_proof.statement.trusted_signed_at` under trust\_manifest\_hash and `Π_σ.trust_history_root` — historical human attribution
8. Verifies that implementation\_extension\_map is null exactly when extensions\_hash is null, or hashes the carried map and matches extensions\_hash
9. Loads the identical transit bytes from the non-overwrite commit store governed by `Π_σ.commit_store_policy` and rejects a missing or byte-divergent record
10. Obtains and verifies the latest authenticated lifecycle head for the exact registry\_id bound by `Π_σ.lifecycle_head_policy`, or verifies an explicitly pinned offline checkpoint under that policy
11. Constructs scheduling state from E\_exec while preserving the complete immutable `top(C) = (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ)` projection
12. Exposes zero graph-mutation APIs — no `create_node`, no `create_edge`, no `modify_topology`
13. Requires every tool call to reference an existing node ID from `V` and every material effect to remain inside effect\_scope — violations are rejected and logged
14. Keeps Planner and Compiler credentials unavailable to the Executor — it cannot invoke planning or recompile
15. Retains E\_audit for traceability while excluding it from scheduling

This is not a parser. The executor enforces that only a hash-verified, Compiler-attested, human-attributed topology can run. No prompt, no delegation, no runtime agent decision can bypass that chain.

**Planner rejection loop.** When Compiler.static rejects G\_proposed, the rejection payload includes the violated constraint ID, the position in G\_proposed, and the policy-bundle pin σ. The planner re-plans up to a bounded number of attempts N (default 3). On the N-th failure, the loop escalates to human re-scope — the Compiler refuses further admission attempts until a PM acknowledges the failure and resets the loop. This prevents infinite re-plan loops.

### 3.11 OutcomeBundle and Typed Route-Governed Artifact Progression

DODGE does not make an autonomous post-execution progression decision. If the user intends to research a hypothesis, create a specification, implement code, or progress every approved hypothesis, that Intent must pass `H_set` alignment and be planned, compiled, approved, and executed through the applicable registered route. Artifact progression is therefore part of the GGC, not a choice performed after it runs.

**OutcomeBundle.** Let C be a GGC and `τ_r` its execution trace for run r. At run finalization, or at an explicitly authenticated checkpoint for a nonterminal run, the Executor emits a content-addressed OutcomeBundle `O_r`:

```text
O_r = {
  outcome_bundle_id,
  ggc_id: id(C),
  run_id: r,
  intent_ref,
  hypothesis_set_ref,
  alignment_record_hash,
  route_id,
  task_refs,
  effect_scope_hash,
  trace_ref: H(canonical(τ_r)),
  activation_log_ref,
  node_outcomes,
  artifact_refs,
  evidence_refs,
  lifecycle_head_ref,
  finalized_at
}

outcome_bundle_id = H(canonical(O_r without outcome_bundle_id))
```

Each `node_outcomes` entry records the committed node ID, terminal status, authoritative execution-attempt ID when completed, and terminal event hash. Each `artifact_refs` entry records the artifact type, schema reference, producing node, governed target, content hash, and authoritative `OUTPUT_ADMITTED` event hash. The bundle contains references and hashes rather than silently reinterpreting outputs.

**No authority inheritance.** `O_r` proves what happened under C; it does not authorize another Plan, effect, route, or execution. A later Intent may cite `outcome_bundle_id` as evidence, but it must pass the current `H_set` alignment check and the full IPCE lifecycle. An OutcomeBundle cannot amend `H_set`, widen effect scope, or bypass HITL.

**Typed artifact progression.** The domain method, route registry, standard-task registry, and artifact-schema registry declare the legal path from one artifact class to another. In DODGE-NBM4 and ship-mlp, a compiled route may progress through Notes, Napkins, RFCs, specifications, tests, sprint artifacts, and code. The Compiler verifies that every planned task is registered, every produced artifact type and schema is allowed at that route position, every dependency edge is legal, and every material effect stays inside the bound effect scope. The Executor then creates only those committed artifacts and records them in `O_r`.

**Epistemic layers remain descriptive.** L3 hypotheses, L2 specifications, and L1 code-conformance evidence remain different claim types, but they do not require a special transformation object or a separate lifecycle. Typed route edges and trace references preserve provenance across them. DODGE governs whether the user’s announced Intent follows an admitted path; it does not decide which approved hypothesis the user should pursue.

### 3.12 GGC Lifecycle and Supersession (with Signed Attestation Chain)

A GGC is immutable once committed. It cannot be mutated. Market evidence does not change a GGC. But product development is not a single execution — market evidence arrives, hypotheses are falsified, plans evolve. DODGE handles this through an append-only attested commit DAG.

#### Lifecycle states

```text
COMPILED → EXECUTED → OBSERVED → CONFIRMED    ↘
                              ↘ WEAKENED      ↘
                              ↘ INVALIDATED   ↘ ARCHIVED
                              ↘ SUPERSEDED → [new GGC C']
```

**ARCHIVED.** A GGC in any of CONFIRMED, WEAKENED, INVALIDATED, or SUPERSEDED may transition to ARCHIVED, a retention state that retires the commit from operational use while preserving it in the put-once store and its lifecycle chain. The transition is authorized and chained exactly as every other transition is, under `Π_σ.lifecycle_authorization_policy` with `successor_id = null`. ARCHIVED is terminal: v9.3 defines no transition out of it, and archival is not a route back to executability.

**Signed transition and authenticated-head chain.** Every lifecycle transition is authorized under `Π_σ.lifecycle_authorization_policy` and chained through the previous authenticated registry head:

```text
transition_i = {
  id_C,
  registry_id,
  sequence,
  prev_head_hash,
  from_state,
  to_state,
  evidence_bundle_hash,
  successor_id,
  actor_key_id,
  trust_manifest_hash,
  signed_at
}

transition_sig_i = Sign_actor(H(canonical(transition_i)))
transition_hash_i = H(concat(canonical(transition_i),
                             canonical_signature(transition_sig_i)))

head_i = {
  id_C, registry_id, sequence, transition_hash_i,
  prev_head_hash, registry_key_id, registry_time
}
head_sig_i = Sign_registry(H(canonical(head_i)))
head_hash_i = H(concat(canonical(head_i), canonical_signature(head_sig_i)))

prev_head_hash_0 = H(canonical_json({domain_separator: "DODGE-LIFECYCLE-GENESIS",
                                    id_C: id(C), registry_id}))
prev_head_hash_i = head_hash_(i-1)  for i ≥ 1
```

Lifecycle is an append-only signed event log keyed by id(C). Immediately after `put_once(id(C), transit(C))` succeeds, the registry MUST create `transition_0` with `sequence = 0`, `from_state = null`, `to_state = COMPILED`, `successor_id = null`, and `prev_head_hash = prev_head_hash_0`, then issue authenticated `head_0`; `Π_σ.lifecycle_authorization_policy` authorizes the initialization actor. No commit is executable before head\_0 exists and verifies. `registry_id` MUST equal the authoritative identity in `Π_σ.lifecycle_head_policy`, and `registry_key_id` MUST validate under that policy’s effective registry-key history. `signed_at` is a registry-authenticated inclusion time or a trusted timestamp, not an unverified actor assertion; the registry requires `|signed_at - registry_time| ≤ Δ_max` (delta max), where `Δ_max` is pinned by the lifecycle-head policy. The registry verifies the actor’s role under `Π_σ.lifecycle_authorization_policy` and resolves the actor key through the transition’s trust-manifest hash and `Π_σ.trust_history_root`. Revocation invalidates signatures whose trusted signed\_at is at or after the declared effective time; earlier valid transitions remain valid unless a compromise determination is explicitly backdated. Ordinary key rotation is not retroactive.

**Anti-rollback rule.** Before execution, the Executor obtains the latest authenticated head for the exact `(id(C), registry_id)` authorized by `Π_σ.lifecycle_head_policy` and verifies the entire head/transition chain to the domain-separated genesis. Verification requires `head_i.sequence = transition_i.sequence`, strict sequence increments, `transition_i.from_state` equal to the preceding `to_state`, matching predecessor hashes, valid actor and registry signatures, and authorized transitions. A stale sequence, divergent head, invalid signature, discontinuous state, or alternate registry is rejected. If a fresh registry head is unavailable, online execution fails closed. An explicitly offline mode may proceed only against a separately pinned authenticated checkpoint under that policy and must state that freshness beyond that checkpoint is not established.

**Supersession binding.** A transition to SUPERSEDED MUST carry non-null `successor_id`; every other transition MUST carry `successor_id = null`. The referenced successor transit object MUST resolve from the governed commit store, validate cryptographically, satisfy `successor_id = id(C′)`, and carry `C′.supersedes_id = id(C)`. This bidirectional check binds the exact predecessor inside the successor’s C\_payload even if the lifecycle registry later becomes unavailable.

**Evidence bundle.** When market evidence arrives, it is structured as an evidence bundle B = { source, classification ∈ {confirms, weakens, invalidates, supersedes}, confidence, evidence\_hash, classifier\_id }. Evidence does not mutate the GGC; it generates a state transition and, where warranted, a new candidate-graph pipeline producing C′ with `supersedes_id = id(C)`. Evidence classification is human-attributed or AI-with-HITL; classifier identity is recorded.

**Executor enforcement.** After latest-head and chain verification, the Executor MUST refuse to execute every INVALIDATED, SUPERSEDED, or ARCHIVED GGC. v9.3 defines no override transition that restores executability; any renewed work requires a distinct valid successor GGC and its own lifecycle chain.

### 3.13 Schema Governance — DODGE Applied to Σ Itself

DODGE’s correctness rests on Σ being correctly authored. Wrong Σ silently corrupts the entire pipeline — a misclassified stage, a wrong cardinality ceiling, a missing artifact type, all silently propagate through every downstream GGC. **Σ must itself be governed.**

**Σ as governed artifact.** Σ is a versioned, signed, evidence-bound artifact. Σ revision triggers a Σ-meta-DODGE pipeline: the proposed revision is reviewed for method coherence; PMs and method stewards ratify it via HITL; a Σ-Compiler validates totality of f, finiteness and acyclicity of every F(a), completeness of Path(F(a))-indexed L bounds, `B_min ≤ B_max`, cardinality consistency, and compatibility of registered routes, standard tasks, and artifact schemas with the domain types and relationships they reference; the result is a signed Σ-commit whose canonical hash is referenced by `Π_σ.domain_schema` in downstream GGCs.

**Recursion bottom.** The Σ-meta-DODGE pipeline is itself governed by a fixed bootstrap Σ\_meta — a small, hand-authored, immutable method schema that defines what a valid Σ is. Σ\_meta is not itself governed by DODGE; it is the bootstrap trust anchor. This is the standard recursion-termination pattern for self-bootstrapping governance systems, including signed supply-chain frameworks and root-key systems.

**Σ revision propagation.** When Σ revises, GGCs pinning the old σ continue to resolve their original hash-verified Π\_σ and remain valid for execution under the old schema. New candidate pipelines admit only the new σ. Migration is explicit — there is no silent re-interpretation of a committed GGC under a changed schema.

### 3.14 Prompt-Intake Governance — Gating Interpretation Before Intent (v9.3, author-reported extension)

*Sections 3.14–3.16 document governance surfaces that operate in the author’s private reference substrate but were not part of the v9.2 model. They are additive: no formal property in §4 depends on them, and their status is author-reported implementation-derived mechanism, not independently accessible evidence. They are included because each closes a governance surface the IPCE lifecycle alone leaves open.*

The v9.2 scope boundary states that exploratory conversation invoking no Executor remains outside DODGE, and that governance begins when an executable Intent is checked against `H_set`. That boundary leaves one failure source ungoverned: the step in which an AI system *forms* its interpretation of a user request. A misread prompt does not need to defeat any downstream gate — it arrives at Plan already wrong, and every subsequent check then faithfully governs the wrong work. The reference substrate closes part of this surface with a **prompt-intake gate** (G-64).

**Mechanism.** On every action-requesting prompt, and before the transport layer admits any non-logger tool action, the agent must author and log a typed `PromptIntentGateDecision` to the session evidence ledger (SEL, G-63). The record carries the interpreted intent as one sentence, a bounded execution scope, explicit assumptions, identified gaps, an integer intent-confidence score, the prompt’s content hash, and a checkpoint identity minted by the intake transport. The transport is fail-closed: tool execution is mechanically blocked until a matching typed record exists for the newest pending intake, so the gate is a precondition for action rather than a convention.

**Decision bands.** Given a base threshold θ and safety margin m (the substrate pins θ = 0.90, m = 0.02), the decision is banded: at or above θ + m the turn auto-continues; strictly between θ and θ + m the agent must stop and obtain explicit human confirmation; at or below θ the agent must redirect and ask the user to rephrase or decide. The margin band exists because a self-assessed score near the threshold is exactly where self-serving rounding would otherwise occur.

**Score arbitration.** Because the confidence score is produced by the same class of model whose interpretation it grades, the substrate adds two self-inflation controls. First, an optional second scorer from a different model family evaluates the same prompt; the final logged score is the *minimum* of the two, and a parse failure of the secondary scorer degrades to the primary score under a typed disagreement status rather than silently. Second, the transport layer carries its own score ceiling: the assistant cannot log a higher confidence than the intake marker admits, which closes the channel where an agent inflates its own gate score after the fact.

**Relationship to the `H_set` alignment check.** The prompt-intake gate and the hypothesis-alignment check (G-6) are distinct and composable, and conflating them would be a category error. The intake gate scores *interpretation fidelity* — whether the system understood what was asked — and runs on every prompt, including ones that never become executable Intents. The alignment check scores *direction fidelity* — whether the requested outcome matches the ratified `H_set` — and runs pre-Plan on executable Intents only. A conforming composition runs intake first and alignment second; a high-confidence interpretation of a hypothesis-misaligned request must still be blocked by G-6. In the reference substrate the intake gate is implemented and live across three agent harnesses while the alignment check remains unimplemented (§7.7.4), which is why v9.3 documents them as separate objects rather than presenting one as a partial realization of the other.

**Stage-decision evidence.** Downstream of intake, the substrate’s Dispatcher pipeline appends a typed stage-decision record (G-65) to SEL as each IPCE stage completes — route, planner, compiler, executor — carrying a PROCEED or BLOCK decision, the governed path, a rationale, and a content digest of the stage output. Stage-decision records extend the audit trail from the commit boundary into the pipeline’s interior, so a post-hoc auditor can reconstruct not only what was committed but which stage admitted or refused each intermediate artifact.

**Non-claims.** Confidence scores are model-self-assessed; their calibration is unestablished and no calibration study is reported (the H1–H6 discipline of §7.3 applies). The gate’s enforcement boundary is tool execution on the governed surface: it cannot prevent an agent from *saying* ungoverned things, only from *doing* ungoverned things, and a harness that does not deliver the intake transport is outside its reach. These limits are structural, and v9.3 names them rather than claiming the surface closed.

### 3.15 Bounded Planner Rejection Loop (v9.3, author-reported extension)

The v9.2 model specifies that the Compiler rejects inadmissible plans but is silent on what happens next. Two failure modes live in that silence: an unbounded repair loop in which the Planner replans indefinitely at token cost with no convergence guarantee, and repair-by-widening in which successive replans quietly grow scope until one passes. The reference substrate pins a **planner rejection loop** (G-66): a Compiler rejection returns a typed, machine-readable repair payload naming the violated checks; the Planner may replan against that payload at most a fixed number of times (the substrate pins three); and exhaustion escalates to HITL with the accumulated structured repair guidance rather than admitting further self-repair. Replans are validated against the same pinned policy bundle as the original proposal, so the loop cannot relax admission to terminate — termination is achieved by the bound, not by weakening checks. The loop converts Compiler rejection from an unspecified retry surface into a governed protocol with a human backstop.

### 3.16 Release-Claim Governance — Gating What the System May Say About Itself (v9.3, author-reported extension)

Governance systems have a characteristic self-referential failure: overclaiming their own status. “Demonstrated” quietly becomes “enforced”, “checked in a test” becomes “governed in production”, and the claims escalate faster than the mechanisms. DODGE’s validation sections (§7) handle this with authorial discipline; the reference substrate additionally makes the discipline executable through a **conformance ledger and release-claim gate** (G-67).

**Mechanism.** The conformance ledger is a machine-readable record binding each acceptance criterion and conformance case to a status and an evidence reference, with named deviations that carry their own closure evidence. The release-claim gate is an executable check that scans declared claim surfaces — release notes, grant narratives, marketing assets — against a registry of blocked claim phrases (for example, unqualified “full conformance” or “100%” wording). The gate admits a blocked phrase only while the ledger predicate is green: every mandatory criterion green, every named deviation closed, and the admitting policy itself HITL-approved. While any deviation is open, the gate blocks the wording itself, not merely the release.

**Why this belongs in the framework.** The claim gate is the same forcing-function pattern as the Compiler, applied one level up: just as an illegal graph cannot become a GGC, an unsupported claim cannot appear on a governed claim surface. It is the mechanism by which §7.7’s distinction between author-reported status and established conformance is enforced against the author rather than merely promised by the author. This section is itself subject to that discipline: v9.3’s descriptions of substrate mechanisms remain author-reported, and the ledger governing this manuscript’s own claim wording is scoped to the v7.1 implementation contract, not to v9.3 conformance.

* * *

## 4\. Formal Properties: Bounded Topology, Invariance, and Replay

*This section presents formal propositions and proof sketches. Full mechanized proofs are deferred to a companion technical report. P-BLTS, P-EDGE, T4a, and T4b are stated over the graph-shape/schema projection. P-HALIGN, P-ERE, P-CTI, P-CADM, P-OUT, P-AUD, and P-IMM use the implementation model because Intent/`H_set` binding, route and effect authority, activation mode, Executor admissibility, output enforcement, compiler attestation, auditability, commit persistence, and lifecycle freshness require additional bound fields and substrate contracts.*

### 4.1 Notation

| Symbol | Meaning |
| --- | --- |
| H_set | Versioned, content-addressed, human-ratified set of product hypotheses used as the Intent-alignment authority boundary; distinct from cryptographic H(...) |
| Align(I, H_set, policy) | Pre-Plan alignment check producing ALIGNED, LOW_MATCH, or EXCEPTION_APPROVED with exact Intent, H_set, evaluator, score, threshold, and exception bindings |
| Σ = (S, A, f, F, L, R, c_candidate, c_eligible, B_min, B_max, Φ, Ψ) | Domain-method schema: stages, types, finite acyclic field schemas, path bounds, relationships, candidate/eligible cardinalities, population bounds, predicate language, and structural constraints |
| Σ_meta | Bootstrap meta-schema for Σ-governance |
| Π | Complete canonical policy bundle named in §3.10 and Appendix A.1 |
| σ | Content-addressed identifier H(canonical_json(Π)); σ has no addressable policy fields |
| Π_σ | Policy bundle returned by ResolvePolicyBundle(σ) after verifying H(canonical_json(Π_σ)) = σ |
| canonical(x) | Shorthand for canonical_json(x) over admitted JSON values |
| f: A → S | Total stage assignment |
| Path(F(a)) | Finite set of typed nested paths induced by finite, acyclic, nonrecursive F(a) |
| L | Path-level scope-bound function (maximum collection length, maximum string length, closed enums) |
| Φ | Typed pure predicate language with bounded aggregation (Appendix A) |
| shape(G) | Finite graph-shape projection (V, V_root, E_exec, E_audit, λ_V, λ_E) |
| top(C) | Complete committed-topology projection (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ) |
| T_legal(Σ) | Set of all schema-legal graph-shape projections under Σ |
| G_admissible(Σ) | Full graphs whose shape lies in T_legal and whose non-shape annotations pass admission |
| G_proposed | Raw planner output (may be malformed and inadmissible) |
| G_candidate | Successful result of partial compile_static_Σ(G_proposed), in G_admissible with shape(G_candidate) ∈ T_legal |
| G_approved | Human-ratified topology selected from G_candidate, with only §3.9-permitted label/predicate edits, compiled to GGC |
| G_eligible(r) | Predicate-eligible subgraph in run r under context K_r |
| V_ready(r, t) | Eligible nodes whose mandatory predecessors are COMPLETED at time t |
| C_min | Minimal commit tuple used for exposition in §3.10. No property in §4 is stated over C_min: P-BLTS, P-EDGE, T4a, and T4b are stated over the graph-shape/schema projection, and the remaining properties over the implementation model C_plus |
| C_plus | Implementation GGC model binding Intent, H_set, alignment, route, tasks, effect scope, graph, policy, approval, and attestation |
| route_id / task_refs / effect_scope | Commit-bound registered route, ordered standard-task references, and finite authorized material-effect scope |
| O_r | OutcomeBundle for run r: content-addressed result and evidence references with no authority for another execution |
| χ | Commit-bound activation-control record declaring mode, K commitment, and replay policy |
| K_r | Total per-activation-edge decision context for run r; each entry is source-bound VALUE(source_ref_e, x_e) or SOURCE_INELIGIBLE |
| K_log | Content-addressed append-only activation-decision log (Mode B) |
| ν | Canonical planner-provided commit-time field map; runtime Worker outputs remain trace-bound external values |
| Score_bp / κ | Versioned integer basis-point domain {0, ..., 10000} and the total per-execution-edge confidence map into it |
| h_pre | Pre-commit hash: H(C_payload), where C_payload includes Intent, H_set, alignment, route, tasks, effect scope, V, V_root, both edge sets, λ_V, λ_E, ν, ρ, κ, β, σ, μ, χ, supersedes_id, and extensions_hash; excludes α and γ |
| id(C) | Content-addressed commit identity over C_payload, α, and γ |

### 4.2 P-BLTS — Bounded Legal Topology Space

**Proposition P-BLTS.** Under a finite artifact universe A, a finite edge-semantic universe Σ\_edge, and finite per-type upper bounds B\_max(a), the number of distinct legal graph shapes |T\_legal(Σ)| is finite when node identifiers are derived from the canonical finite slot set defined below.

**Proof sketch.** Let U = {(a, i) | a ∈ A and 1 ≤ i ≤ B\_max(a)}. Because A is finite and every B\_max(a) is finite, U is finite. Node identifiers are derived from U, so every legal node set V is a subset of U and every explicit root set V\_root is a subset of V. Every legal typed edge set is a subset of U × U × Σ\_edge, which is finite. Therefore the number of candidate typed graph shapes, including root designation, is at most:

```text
2^(2 · |U|) · 2^(|U|² · |Σ_edge|)
```

before applying R, c\_candidate, stage order, acyclicity, reachability, and Ψ. Those constraints only reduce the set. Runtime c\_eligible postconditions do not define candidate graph shape. Hence |T\_legal(Σ)| < ∞. ∎

**Assumptions required.** (i) |A| < ∞; (ii) |Σ\_edge| < ∞; (iii) B\_max(a) < ∞ and 0 ≤ B\_min(a) ≤ B\_max(a) for all a ∈ A; (iv) node identifiers use the canonical slots in U; (v) no dynamically typed nodes are introduced at runtime. Finite L bounds are not required for graph-shape finiteness, although they are required for DODGE’s content-scope claims.

**Reachability and uniqueness conditions.** P-CADM separately rejects duplicate node identifiers and schedulable nodes unreachable through E\_exec. Those conditions provide structural cleanliness and Executor reachability; they are not needed for finiteness because B\_max already bounds the finite slot set U.

**What P-BLTS does not claim.** P-BLTS does not claim that the same intent produces the same candidate graph or that G\_admissible is finite. Predicate constants and node content may range over non-finite semantic domains, and the Planner is LLM-driven; κ is separately finite under Score\_bp. P-BLTS claims only that `shape(G_candidate) ∈ T_legal(Σ)` and |T\_legal(Σ)| < ∞ under the assumptions above.

### 4.3 P-CTI — Commit Topology Invariance (Property, not Theorem)

**Property P-CTI.** For a fixed GGC C consumed by a graph-closed Executor, every execution run r preserves `top(C) = (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ)` exactly. No node, root designation, execution edge, audit edge, label, or activation predicate is added, removed, or changed.

**This is a property, not a novel theorem.** It follows by construction from the Executor’s definition: the API exposes no topology-mutation operation; scheduling state is constructed from verified E\_exec; E\_audit, λ\_V, λ\_E, and ρ remain immutable committed data; and all tool calls must reference existing node IDs ∈ V. The engineering contribution is the admission chain that makes this property mandatory for governed execution, not invariance in isolation.

**Assumptions required.** (i) Executor is graph-closed by construction and preserves the full committed projection; (ii) Π\_σ resolves and hash-verifies from σ; (iii) γ verifies, and α’s human signature plus carried timestamp proof verify under `Π_σ.approval_timestamp_policy`, the exact trust manifest, and effective authorization at timestamp\_proof.statement.trusted\_signed\_at; (iv) the transit bytes, including the verified implementation\_extension\_map, match the put-once store record governed by `Π_σ.commit_store_policy`; (v) lifecycle-head freshness and chain validity are established under `Π_σ.lifecycle_head_policy`; (vi) tool calls are scoped to existing node IDs; and (vii) Planner and Compiler credentials are unavailable to the Executor at runtime.

### 4.4 P-ERE — Eligibility Replay Equivalence

**Note on eligibility, readiness, and execution.** This model separates `G_eligible(r)` (the predicate-induced subgraph, a function of C and total per-edge K), `V_ready(r,t)` (the time-indexed node set released after mandatory predecessors complete), and `G_executed(r)` (eligible nodes that actually reached COMPLETED). P-ERE-A/B claim repeatability of **G\_eligible**. Readiness and completion depend on transient failures, timeouts, and Worker reliability, which are separable runtime concerns outside replay equivalence. A node that is eligible in two runs but fails or remains BLOCKED in one is a reliability event; when that node is an activation source, the absence of its required decision context terminates the run as `ACTIVATION_CONTEXT_INCOMPLETE` rather than producing a contradictory eligibility result. Reliability properties are identified as future work (P-REL, §8.3).

**Proposition P-ERE-A (Strict Eligibility Replay Equivalence).** Let C be a valid GGC with χ.activation\_mode = A and a K\_commitment resolving to a total, consistency-valid K — every activation source has exactly one PRECOMMITTED source record, every outgoing activation edge has either a source-bound `VALUE(source_ref_e, x_e)` from that record whose exact committed-ρ projection verifies or `SOURCE_INELIGIBLE` for an ineligible source, and each compared run passes the Mode A activation-integrity checks. If all predicates in ρ are members of Φ (total, pure, side-effect-free), then for any two such runs r₁, r₂ of Executor(C, K):

```text
G_eligible(r₁) = G_eligible(r₂)
```

**Proof sketch.** Traverse the committed E\_exec DAG in topological order. The eligibility of each activation source u is therefore fixed before an outgoing edge e = (u, v) is interpreted. Consistency-valid K supplies `SOURCE_INELIGIBLE` exactly when u is ineligible, making e false without predicate evaluation; otherwise it supplies the same source-bound VALUE in both runs. Verification fixes the admitted source-output hash, exact `refs(ρ(e))` projection, and x\_e, while purity of Φ makes eval(ρ(e), x\_e) identical. The declared roots and all mandatory-predecessor decisions are also identical, so induction yields the same eligibility decision for every node. Because E\_eligible and the restricted λ\_V, λ\_E, and ρ mappings are deterministic restrictions of the same committed C under equal vertex decisions and K, the complete G\_eligible tuples are equal. ∎

**Proposition P-ERE-B (Practical Eligibility Replay Equivalence).** Let C be a valid GGC with χ.activation\_mode = B and let K\_log be a **content-addressed replay log** containing one terminal `VALUE` or `SOURCE_INELIGIBLE` decision for every activation edge, produced under the replay policy pinned by χ. For any replay run r\_replay reading decisions from the trace-bound K\_log:

```text
G_eligible(r_replay) = G_eligible(r_original)
```

**Proof sketch.** Mode B replay reads the tagged activation-edge decisions from K\_log rather than recomputing them. Since K\_log is content-addressed and read-only, K\_replay = K\_original, including every `SOURCE_INELIGIBLE` sentinel. The topological induction from P-ERE-A therefore yields G\_eligible(r\_replay) = G\_eligible(r\_original). ∎

**Mode C is acknowledged and explicitly forfeits the replay claim.** If activation values are recomputed via LLM on each run (no commit, no log), G\_eligible may vary across runs. If any required value is missing, the run records `ACTIVATION_CONTEXT_INCOMPLETE` and no P-ERE conclusion is drawn. P-CTI still holds — topology is invariant; only the eligible subgraph may differ. **Mode B is the realistic default**.

**Assumptions required.** (i) K (Mode A) or K\_log (Mode B) contains exactly one typed terminal decision for every activation edge and is consistency-valid with source eligibility; (ii) every VALUE for e = (u, v) binds source\_node\_id = u, a verifiable admitted source record, the exact canonical ordered `refs(ρ(e))` projection, and a total x\_e; Mode A has exactly one PRECOMMITTED source record per activation-source node and all outgoing VALUE decisions for that node share its origin and output hashes, while Mode B/C applies the same invariant per source execution attempt; (iii) any source recomputed in Mode A matches its sole precommitted source-output hash, otherwise that run terminates with `ACTIVATION_INTEGRITY_MISMATCH` before a G\_eligible/P-ERE conclusion; (iv) all φ ∈ Φ; (v) Executor predicate evaluation is deterministic over its input; (vi) no clock, randomness, or external state inside predicates.

**What P-ERE does not claim.** P-ERE does not claim that (a) LLM content within nodes (artifacts, analyses, recommendations) is identical across runs — node output content may differ; (b) execution success of eligible nodes is identical across runs — that is a reliability property (P-REL future work), not a replay-equivalence property. P-ERE claims only that the *eligible* subgraph induced by K is repeatable.

### 4.5 P-CADM — Compiler Admissibility

**Proposition P-CADM.** A sound DODGE Compiler first resolves `Π_σ = ResolvePolicyBundle(σ)` and rejects unless `H(canonical_json(Π_σ)) = σ`. It accepts G\_approved and produces GGC C only if the pre-Plan authority chain and G\_approved satisfy all of the following:

1. All node types λ\_V(v) ∈ A
2. All stage assignments f(λ\_V(v)) valid
3. Every e = (u, v) ∈ E\_exec ∪ E\_audit satisfies (λ\_V(u), λ\_V(v), λ\_E(e)) ∈ R; every inter-stage edge is stage-forward, and every intra-stage edge uses a semantic permitted by R
4. E\_exec forms a DAG: inter-stage execution edges are stage-forward, and intra-stage execution edges pass secondary topological sort within each stage
5. Every artifact-type population satisfies `B_min(a) ≤ |V_a| ≤ B_max(a)`, and every relationship multiplicity satisfies c\_candidate(R) on both outgoing and incoming sides for present endpoints
6. All `activates` edges carry φ ∈ Φ, well-typed against source node output schema, with predicate scope restricted to immediate source-node fields (Option A); all `requires` and `derives_from` edges carry ρ(e) = ⊤; no other scheduler-visible edge semantic is admitted; κ is total on E\_exec and every score is an integer in Score\_bp under `Π_σ.score_domain_version`
7. **V\_root ⊆ V is present and commit-bound; every root has E\_exec indegree zero; Ψ authorizes its root types and cardinality; every schedulable v ∈ V is reachable from V\_root via E\_exec; and E\_audit never establishes Executor reachability**
8. **Node identifiers unique within V**
9. Every F(a) is finite, acyclic, and nonrecursive; L is defined with finite bounds for every variable-length path in Path(F(a)); ν is canonical, typed by F, and all planner-provided values in ν satisfy the committed path bounds at compile time
10. The delta from the β-bound G\_candidate to G\_approved satisfies §3.9: any structural or predicate-structure edit has a new β\_payload bound to the revised candidate hash; any predicate-value edit preserves the predicate AST and changes only a constant inside the corresponding β\_payload.safe\_ranges interval
11. HITL approval record α is present as a structured object; α.payload binds h\_pre = H(C\_payload), signer\_key\_id, and trust\_manifest\_hash; α.signature is cryptographically valid over `H(canonical_json(α.payload))`; α.timestamp\_proof.statement is a structured object binding timestamp\_authority\_id, trusted\_signed\_at, and timestamp\_subject, while α.timestamp\_proof.signature authenticates `H(canonical_json(α.timestamp_proof.statement))`; timestamp\_subject equals `H(concat(canonical_json(α.payload), canonical_signature(α.signature)))`; the timestamp proof and authority verify under `Π_σ.approval_timestamp_policy`; and the signer was authorized at trusted\_signed\_at under that trust manifest and `Π_σ.trust_history_root`
12. Triage record β is present; β\_payload references G\_candidate, binds safe ranges, role\_config, both report hashes, the role-tagged Advocate/Skeptic statement hashes, triage\_context\_hash, and verdict ∈ {Adopt, Trial, Watch}; the supplied reports hash to the bound values; triage\_context\_hash recomputes from the exact candidate hash, safe ranges, role configuration, and `Π_σ.triage_policy`; all role pin references resolve in μ; each attestation signer equals the corresponding role\_config signer\_key\_id and is role-authorized; Advocate and Skeptic attest their respective role-tagged report/context statements; Judge attests H(canonical(β\_payload)); and the role configuration satisfies the diversity requirements in that policy
13. `Π_σ = ResolvePolicyBundle(σ)` succeeds and satisfies `H(canonical_json(Π_σ)) = σ`; Π\_σ contains the domain-schema reference, route registry, standard-task registry, artifact-schema registry, hypothesis-alignment policy, hypothesis-exception policy, F, Path(F), c\_candidate, c\_eligible, B\_min, B\_max, L, Ψ, the Φ grammar version, score-domain version, triage policy, approval-timestamp policy, lifecycle-authorization policy, lifecycle-head/freshness policy, trust-history root, and commit-store policy
14. χ declares activation mode A, B, or C; its K commitment and replay-policy fields are valid for the declared mode
15. supersedes\_id is either null or a well-formed, non-self predecessor identifier; for non-null values the Compiler resolves predecessor C, verifies its transit object under C.σ, resolves `Π_{C.σ} = ResolvePolicyBundle(C.σ)` and verifies `H(canonical_json(Π_{C.σ})) = C.σ`, verifies C’s authenticated latest lifecycle head, and admits supersession only when `Π_{C.σ}.lifecycle_authorization_policy` authorizes it—C′.σ cannot retroactively grant authority over C
16. intent\_ref and hypothesis\_set\_ref resolve and hash-verify; the alignment record binds those exact references and the evaluator configuration required by `Π_σ.hypothesis_alignment_policy`; its decision is `ALIGNED`, or it is `EXCEPTION_APPROVED` with a valid human signature, exact-Intent and active-`H_set` binding, scope, and expiry admitted under `Π_σ.hypothesis_exception_policy`; `LOW_MATCH` is rejected
17. route\_id resolves in `Π_σ.route_registry`; every task\_ref resolves in `Π_σ.standard_task_registry` and is legal for that route position; every planned artifact type and schema resolves through `Π_σ.artifact_schema_registry` and is compatible with Σ; effect\_scope is finite and no wider than the route/task-authorized targets and effects
18. implementation\_extension\_map is a finite canonical JSON object or null; extensions\_hash is null exactly when the map is null and otherwise equals H(canonical(implementation\_extension\_map)); after all checks pass, Compiler produces `γ = Sign_compiler(H(concat(C_payload, canonical_signature_envelope(α))))`, `id(C) = H(concat(C_payload, canonical_signature_envelope(α), canonical_signature_envelope(γ)))`, and transit(C) carrying the verified map

**Completeness note.** P-CADM proves that accepted GGCs satisfy the declared Intent/`H_set`, route, task, artifact-schema, effect-scope, topology, and attestation constraints. It does not cover worker-generated output admission, semantic correctness, strategic soundness, or market validity of the human-ratified hypotheses.

**Rejection payload.** When any condition fails, the Compiler emits a rejection payload: { violated\_constraint\_id, position\_in\_G\_proposed, sigma\_version, suggested\_repair }. The planner uses this payload to re-plan up to N attempts; on N-th failure, the loop escalates to human re-scope.

#### 4.5.1 P-OUT — Runtime Output Admissibility

**Property P-OUT.** For every Worker output o emitted for node v, the Executor admits o to durable storage and records its content hash in the trace only if o conforms to the committed output field schema F(λ\_V(v)) and every applicable Path(F(λ\_V(v)))-indexed L bound. A rejected output causes v to transition to FAILED; mandatory dependents whose eligibility is already resolved become BLOCKED and are not added to V\_ready, while activation targets needing that eligible source’s rejected value yield `ACTIVATION_CONTEXT_INCOMPLETE`. For each completed node in a run, only the authoritative `OUTPUT_ADMITTED` event of `successful_attempt_r(v)` establishes terminal COMPLETED status; a later attempt cannot establish a second successful completion. An ineligible source emits no Worker output and instead contributes `SOURCE_INELIGIBLE` to its outgoing activation decisions.

**Boundary.** P-OUT is an Executor property, not part of Compiler admissibility P-CADM. It constrains runtime content admission but does not make Worker content deterministic or guarantee completion.

### 4.6 P-EDGE — Edge Semantic Biconditional

**Proposition P-EDGE.** For every committed edge e ∈ E\_exec:

```text
ρ(e) ∈ Φ  ⟺  λ_E(e) = activates
ρ(e) = ⊤  ⟺  λ_E(e) ∈ {requires, derives_from}
```

**Proof.** Enforced by P-CADM step 6. The Compiler rejects any `activates` edge without φ ∈ Φ, rejects any `requires` or `derives_from` edge carrying a nontrivial predicate, and rejects any other scheduler-visible edge semantic. ∎

### 4.7 T4a, T4b — Acyclicity and M:N Boundedness

**T4a (Inter-stage Acyclicity).** If all inter-stage edges satisfy f(λ\_V(u)) < f(λ\_V(v)), the inter-stage subgraph is acyclic.

**Proof.** A cycle would require a sequence v₁ → v₂ → … → v₁ with strictly increasing stage indices at each step — impossible in a strict total order. ∎

**Note.** T4a applies to inter-stage edges only. Intra-stage execution-edge acyclicity is separately guaranteed by P-CADM step 4 (secondary topological sort). Global execution-graph acyclicity of E\_exec follows from T4a plus P-CADM step 4; E\_audit is excluded and may contain schema-authorized same-stage evidence cycles.

**T4b (M:N Boundedness).** For any relationship R: aᵢ → aⱼ with candidate cardinality c\_candidate(R) = (min\_out, max\_out, min\_in, max\_in), the total number of edges across the relationship in any T ∈ T\_legal is bounded by:

```text
|E(R)| ≤ min(max_out · B_max(aᵢ), max_in · B_max(aⱼ))
```

**Proof.** There are at most B\_max(aᵢ) source nodes; each may have at most max\_out outgoing edges of type R. There are at most B\_max(aⱼ) target nodes; each may have at most max\_in incoming edges of type R. Total edges are bounded by both — the tightest bound is the minimum. ∎

**T4b does not eliminate M:N.** Multiple aᵢ nodes may each connect to the same aⱼ node, and a single aᵢ node may connect to multiple aⱼ nodes. M:N relationships are bounded in multiplicity, not structurally eliminated.

### 4.8 P-AUD — Auditability

**Proposition P-AUD.** For every execution trace τ\_r admitted as valid by the trusted append-only audit channel for Executor(C), with run identifier r, there exists one C, unique except with negligible hash-collision probability, such that:

- the structural projection of τ\_r is contained in top(C)
- α attests human ratification of the exact C\_payload, including Intent, `H_set`, alignment record, route, tasks, effect scope, top(C), ν, κ, β, σ, μ, χ, and supersedes\_id; its carried timestamp proof authenticates the exact human signature at trusted\_signed\_at, and trust\_manifest\_hash supports historical authorization verification
- γ attests Compiler-mediated production
- σ identifies the schema, alignment/exception policies, route/task/artifact registries, and remaining policy bundle resolved as Π\_σ; μ pins the model/tool versions; K\_log (Mode B) pins the activation context
- the transit bytes match the put-once commit-store record for id(C)
- every lifecycle transition affecting C is signed, authorized under `Π_σ.lifecycle_authorization_policy`, and included in the verified latest authenticated-head chain

**Required trace-event content.** Uniqueness of the C-projection requires that *every* trace event carry sufficient identity metadata to anchor it to a specific commit and run. The Executor MUST emit every trace event with the following fields:

```text
trace_event = {
  id_C:           id(C),                  # commit hash — anchors event to exact commit
  run_id:         r,                      # run identifier — distinguishes replays
  intent_ref:     committed Intent reference,
  hypothesis_set_ref: committed H_set reference,
  route_id:       committed registered route,
  executor_id:    executor_pubkey_hash,   # which Executor instance produced the event
  gamma_ref:      H(canonical_signature_envelope(γ)), # Compiler attestation reference
  event_seq:      monotonic integer,      # event ordering within run
  execution_attempt_id: attempt_id (when applicable),
  event_type:     enum {NODE_ELIGIBLE, NODE_READY, NODE_EXECUTED, NODE_SKIPPED,
                        NODE_FAILED, NODE_BLOCKED, OUTPUT_ADMITTED,
                        ACTIVATION_INTEGRITY_MISMATCH,
                        ACTIVATION_CONTEXT_INCOMPLETE, ...},
  node_id:        v ∈ V (when applicable),
  content_hash:   admitted output hash (for OUTPUT_ADMITTED),
  K_log_ref:      content-addressed pointer into K_log (when applicable),
  timestamp:      ISO 8601,
  ...              # event-type-specific payload
}
```

Without these fields, two distinct GGCs with overlapping topology could produce trace events that project equivalently. With these fields, each validated event is deterministically associated with a commit, Intent, `H_set`, route, and run after audit-channel admission. For each node in a run, at most one execution attempt may establish terminal COMPLETED status; for every `v ∈ V_executed(r)`, that attempt is `successful_attempt_r(v)` and carries exactly one authoritative `OUTPUT_ADMITTED` event binding `(run_id, node_id, execution_attempt_id)`. Retries before success remain legal and non-authoritative; a second success after terminal completion is rejected or recorded as a runtime protocol violation. A Mode B VALUE must reference that authoritative event hash and content\_hash. The `executor_id` field is an identifier, not provenance proof by itself; authenticity and integrity depend on the trusted audit channel or an equivalent authenticated-event mechanism.

Every valid OutcomeBundle O\_r binds id(C), run\_id, Intent, `H_set`, alignment, route, tasks, effect-scope hash, trace hash, node outcomes, artifact output events, and lifecycle head. Its content-addressed identity therefore provides a compact audit index over the execution without creating new authority.

**Assumptions required.** The audit channel authenticates Executor origin and preserves event integrity; logs are retained and append-only; identifiers are stable; Intent, `H_set`, alignment/exception, route, task, artifact-schema, and effect-scope references resolve and verify; Π\_σ resolves and hash-verifies from σ; α’s human signature and carried timestamp proof are verifiable under `Π_σ.approval_timestamp_policy` and the exact trust manifest, and γ is verifiable against effective trust history; evidence and OutcomeBundle references are retrievable; K\_log is content-addressed; the commit store satisfies `Π_σ.commit_store_policy`; the latest authenticated lifecycle head is available or an offline checkpoint is explicitly pinned under `Π_σ.lifecycle_head_policy`; every event carries the required identity fields above; canonical serialization is unambiguous and injective over admitted values; H remains collision-resistant.

### 4.9 P-IMM — Commit Immutability, Persistence, and Anti-Rollback

**Proposition P-IMM.** Assume (i) canonical serialization is unambiguous and injective over admitted values, signature encodings are unambiguous, concatenation is length-delimited, and H is collision-resistant; (ii) Π\_σ resolves and hash-verifies from σ; (iii) transit(C) carries the implementation\_extension\_map whose canonical hash equals the identity-bound extensions\_hash, and the commit store satisfies `Π_σ.commit_store_policy` by implementing put-once, byte-identical retrieval, and rejection of overwrite and deletion; and (iv) the lifecycle registry supplies an authenticated latest head whose complete transition/head chain is verified under `Π_σ.lifecycle_authorization_policy`, `Π_σ.lifecycle_head_policy`, and `Π_σ.trust_history_root`. Then a committed payload or carried extension map cannot be changed under the same id(C), its stored bytes cannot be overwritten or deleted through the conforming store interface, and an Executor cannot silently roll lifecycle state back to an older authenticated head.

**Proof sketch.** If C′ ≠ C, injective canonical serialization and unambiguous length-delimited encoding yield distinct identity preimages; equality id(C′) = id(C) would require a collision in H except with negligible probability. Any change to a non-null implementation\_extension\_map changes its canonical hash and therefore the extensions\_hash committed in C\_payload; withholding the map makes transit verification fail. The put-once store preserves the admitted transit bytes and rejects destructive mutation. Each lifecycle head signs its sequence, transition hash, and prior-head hash; verification against the registry’s latest authenticated head detects truncation, reordering, divergence, and rollback. If latest-head freshness cannot be established, online execution fails closed; explicitly offline execution is bounded by its pinned authenticated checkpoint. ∎

### 4.10 P-HALIGN — Hypothesis-Aligned Admission

**Property P-HALIGN.** For every execution run r admitted under GGC C, C binds an exact Intent reference, an active human-ratified `H_set` reference, and an alignment record whose decision is `ALIGNED` or `EXCEPTION_APPROVED`. An `EXCEPTION_APPROVED` record additionally carries a valid human authorization bound to the exact Intent, active `H_set`, scope, and expiry. No `LOW_MATCH` Intent is admitted to Plan, Compile, or Execute.

**Construction argument.** The pre-Plan alignment gate emits a content-addressed record before Planner access. Plan accepts only admitted records. P-CADM conditions 16–17 require the Compiler to resolve and verify the bound Intent, `H_set`, alignment/exception evidence, registered route, standard tasks, typed artifact schemas, and effect scope before producing γ. The Executor verifies those bindings from C before constructing runtime state. Therefore a direct low-match or unaligned path would require a gate, Compiler, signature, or hash-verification failure rather than an ordinary execution path.

**User-sovereignty boundary.** P-HALIGN claims fidelity to the user’s ratified direction, not that `H_set` is correct. A human may authorize any hypothesis by ratifying a new `H_set` version or an exact-Intent exception. Agents may propose but cannot perform either authority-changing act.

**Epistemic-layer note.** Typed routes may connect L3 hypothesis artifacts, L2 specifications, and L1 conformance artifacts while preserving their distinct claim semantics through schemas and trace edges. Correct code does not prove a market hypothesis true, and a ratified hypothesis does not prove an implementation correct; no special transformation object is required to preserve that distinction.

* * *

## 5\. Domain Instantiation: DODGE-NBM4 for Product Management

### 5.1 Domain Selection Rationale

Product management is selected as the primary proof-of-concept domain for three reasons: (i) it is a primary intended audience for DODGE; (ii) it exhibits multi-stage artifact dependencies, bounded M:N relationships among personas and jobs-to-be-done, human judgment requirements at material forks, and irreducible market uncertainty; and (iii) it has a documented method (NBM4 — Kozloff 2024) with artifact vocabulary suitable for a reference instantiation.

DODGE is parameterized over a domain-method schema Σ. Product management is the first instantiation; it is not the only valid one. Alternative product-development methods — Continuous Discovery (Torres, 2021), Lean Startup (Ries, 2011), Jobs-to-be-Done (Christensen et al., 2016) — yield alternative Σ encodings. A sketched second instantiation over RFC governance is provided in Appendix C.

**NBM4 self-citation disclosure.** NBM4 is authored by the present author (Kozloff, 2024). Its use here is as a domain instantiation vehicle, not as proof of product-management truth. The cited public overview documents the staged method and artifact vocabulary but does not publish the numerical relationship multiplicities in §5.4. Those cardinality values are illustrative DODGE-NBM4 defaults calibrated by the author’s practice during Σ encoding; domain practitioners adopting DODGE should derive bounds from their own method documentation.

### 5.2 NBM4 Stage Set

The reference NBM4 instantiation used here defines six ordered stages. DODGE’s formal properties do not depend on this stage count.

The reference stage set is:

| Stage ID | Name | Epistemic purpose |
| --- | --- | --- |
| s₁ | Idea | Initialize product vision, market hypothesis, risk register |
| s₂ | Customer | Discover customer segments, pains, jobs-to-be-done |
| s₃ | Value Suggestion | Propose features, value propositions, prioritization |
| s₄ | Value Test | Validate hypotheses against prototype/pilot evidence |
| s₅ | Product | Define production-ready specifications and roadmap |
| s₆ | Go to Market | Define channel strategy and launch plan |

Stage ordering S = {s₁ < s₂ < s₃ < s₄ < s₅ < s₆} is total. All inter-stage DODGE edges must satisfy `f(λ_V(u)) < f(λ_V(v))`.

#### 5.2.1 Two σ-Pinned Profiles and Structural Constraints Ψ\_NBM4

DODGE-NBM4 defines two distinct profiles, each with its own canonical Π bundle and therefore its own σ. `Σ_NBM4-full` requires `B_min(ProductVision) = 1` and sets `B_min(TargetSegment5W) = 0` as the inactive alternative root. `Σ_NBM4-customer-value` requires `B_min(TargetSegment5W) = 1` and sets `B_min(ProductVision) = 0`. Both profiles share compatible B\_max values; inactive alternative roots remain optional rather than simultaneously mandatory. The worked voyage in §5.6 pins `Σ_NBM4-customer-value`, commits `V_root = {target_segment_1}` with `target_segment_1: TargetSegment5W`, and includes the required TargetSegment5W → PersonaProfile → JTBDAsIs/UserJobStoriesAsIs/Pain → PainPriority → ProductFeatureUJS → ValueMap relationships. Each profile’s Ψ\_NBM4 authorizes only its selected root configuration and requires canonical slot-derived node identifiers, root E\_exec indegree zero, rejection of nodes outside V\_root with E\_exec indegree zero, uniqueness, E\_exec reachability from V\_root, stage legality, and secondary DAG validation for intra-stage execution edges. The relationship tables in §5.4 and Appendix B.2 are selected readable projections, not an exhaustive machine-readable Σ\_NBM4 bundle.

### 5.3 NBM4 Artifact Type Universe

The reference instantiation uses the following artifact-type universe. These names are sufficient to make the examples and cardinality tables self-contained; external adopters would substitute the artifact universe of their own product-development method.

| ID | Artifact type | Stage |
| --- | --- | --- |
| A01 | ProductVision | Idea |
| A02 | RiskiestHypotheses | Idea |
| A03 | MarketHypothesis | Idea |
| A04 | LeanCanvas | Idea |
| A05 | TargetSegment5W | Customer |
| A06 | CompetitorSnapshot | Customer |
| A07 | InterviewGuide | Customer |
| A08 | PersonaProfile | Customer |
| A09 | EmpathyMap | Customer |
| A10 | CustomerInterviewNotes | Customer |
| A11 | PainAnalysis | Customer |
| A12 | PainEvidenceBundle | Customer |
| A13 | JTBDAsIs | Customer |
| A14 | UserJobStoriesAsIs | Customer |
| A15 | SegmentPriority | Customer |
| A16 | Pain | Customer |
| A17 | PainPriority | Value Suggestion |
| A18 | ProductFeatureUJS | Value Suggestion |
| A19 | FeaturePriorities | Value Suggestion |
| A20 | PrototypeTestPlan | Value Test |
| A21 | ValueMap | Value Suggestion |
| A22 | ValuePropositionCanvas | Value Suggestion |
| A23 | ChannelCanvas | Go to Market |
| A24 | GTMLaunchPlan | Go to Market |

### 5.4 Key Relationship Cardinalities

| Relationship | Source | Target | c_candidate | c_eligible | Edge semantic |
| --- | --- | --- | --- | --- | --- |
| Persona → JTBD | A08 | A13 | (1, 5, 1, 3) | (1, 5, 1, 3) | derives_from |
| Persona → Pain | A08 | A16 | (1, 10, 1, 5) | (1, 10, 1, 5) | derives_from |
| Pain → PainPriority | A16 | A17 | (1, 1, 1, 1) | (1, 1, 1, 1) | derives_from |
| PainPriority → Feature | A17 | A18 | (0, 12, 1, 1) | (0, 12, 0, 1) | activates |
| Feature → ValueMap | A18 | A21 | (1, 1, 1, 12) | (1, 1, 1, 12) | derives_from |
| LeanCanvas → RiskiestHypotheses | A04 | A02 | (0, 1, 0, 1) | — (audit-only) | evidence_for |
| ProductVision → LeanCanvas | A01 | A04 | (0, 1, 0, 1) | (0, 1, 0, 1) | requires |

PainPriority and ProductFeatureUJS use the item-node model. Each PainPriority carries scalar fields `pain_id`, `priorityScore`, and `rationale`; each ProductFeatureUJS carries `feature_id`, `user_job_story`, and `acceptance_criteria`. The primary activation predicate is `source.outputs.priorityScore ≥ 15`, so feature candidates sourced from different prioritized pains can activate independently. `B_max(A18) = 12` caps the total ProductFeatureUJS node count for a commit; no nested feature array multiplies that bound.

### 5.5 Selected Readable Projection of F and L

The following table is a selected readable projection of field paths and scope bounds used by the worked example:

| Artifact | Path | L bound |
| --- | --- | --- |
| PersonaProfile | description | max_string_length: 2000 |
| PersonaProfile | top_pain_summaries | max_collection_length: 5 |
| PainAnalysis | observations | max_collection_length: 10 |
| PainAnalysis | observations[*].evidence_text | max_string_length: 500 |
| PainPriority | rationale | max_string_length: 500 |
| ProductFeatureUJS | user_job_story | max_string_length: 1000 |
| ProductFeatureUJS | acceptance_criteria | max_collection_length: 8 |
| ProductFeatureUJS | acceptance_criteria[*].text | max_string_length: 300 |
| ValueMap | value_propositions | max_collection_length: 5 |

`PersonaProfile.top_pain_summaries` is a five-item human-readable summary and is not the authoritative Pain collection; Pain item nodes and R08 edges carry that topology, with a separate maximum of 10 outgoing Pain edges per Persona. A PersonaProfile node whose `description` exceeds 2000 characters is rejected at compile time even if the graph shape is otherwise legal. A ProductFeatureUJS node with 9 acceptance criteria is rejected by L even though it is a single legal feature node.

This excerpt alone does not establish complete DODGE-NBM4 content-scope conformance. A conforming Σ\_NBM4 profile MUST bind a complete finite F/L table for every variable-length typed path. A full conformance claim additionally requires a cited, content-addressed, machine-readable bundle included in Π\_σ with `H(canonical_json(Π_σ)) = σ`; no such independently retrievable bundle is cited in this manuscript version.

### 5.6 PM Example: The Governed Voyage

A PM begins a B2B SaaS product discovery cycle. Intent: “Identify top features from customer pain discovery.”

**Hypothesis alignment and Plan.** The active `H_set` contains human-ratified hypotheses `HYP-SEGMENT-B2B-01` (the declared B2B segment has unresolved workflow pain) and `HYP-PAIN-TO-VALUE-01` (features derived from validated pains may create customer value). The pre-Plan check binds the exact Intent and `H_set` hash, records both matched hypothesis IDs, and returns `ALIGNED`. Plan selects the registered NBM4 customer-discovery-to-feature route, its standard tasks, typed Persona/Pain/PainPriority/ProductFeatureUJS/ValueMap artifacts, and the governed effect targets for this run. A low-match Intent such as “launch an unrelated consumer game” would stop before this plan existed unless the PM ratified an `H_set` amendment or an exact-Intent exception.

**Tier 1 — Schema.** The slice commits `V_root = {target_segment_1}` with `target_segment_1: TargetSegment5W` and constrains downstream nodes to Stage 2 and Stage 3 artifact types. AI cannot generate ProductFeatureUJS nodes before PainPriority — schema rejects it. A PersonaProfile.description longer than 2000 characters is rejected even if topology is otherwise legal.

**Tier 2 — Cardinality.** The selected profile requires one TargetSegment5W root, permits up to 3 Personas and up to 10 Pain nodes per Persona, requires every present Persona to connect to JTBDAsIs and UserJobStoriesAsIs nodes, requires every present JTBDAsIs to connect to a UserJobStoriesAsIs node, requires every ProductFeatureUJS to connect to a ValueMap, and sets `B_max(A18) = 12`. A Planner proposing a thirteenth ProductFeatureUJS node is rejected even if its individual relationship multiplicities are otherwise legal.

**Tier 3 — Scored Edges.** The Planner produces the complete G\_proposed: 1 TargetSegment5W root; 2 PersonaProfile nodes; 2 JTBDAsIs nodes; 2 UserJobStoriesAsIs nodes; 12 Pain nodes; 12 corresponding PainPriority nodes; 12 candidate ProductFeatureUJS nodes; and 12 candidate ValueMap nodes. The root connects to both Personas; each Persona connects to one JTBDAsIs, one UserJobStoriesAsIs, and six Pain nodes; each JTBDAsIs connects to its paired UserJobStoriesAsIs; every Pain connects to one PainPriority; every PainPriority proposes one Feature; and every Feature connects one-to-one to its own ValueMap. Compiler.static admits this complete 55-node proposal to G\_candidate after schema, population, relationship-cardinality, Φ, and L checks. Each feature edge carries `source.outputs.priorityScore ≥ 15` against its own PainPriority source. Under preview values, three Feature–ValueMap pairs are projected eligible and nine projected ineligible; no runtime node is yet classified SKIPPED.

**Tier 4 — Triage.** The hypothetical panel uses Anthropic-family (Advocate), OpenAI-family (Skeptic), and Google-family (Judge) models with distinct prompt families. Each role’s model\_pin\_ref and prompt\_pin\_ref resolve to immutable μ entries. The Skeptic flags the edge sourced from PainPriority #4 because its previewed `priorityScore` is 14, one point below the proposed threshold. The Advocate and Skeptic sign their respective role-tagged statement hashes, each binding its report hash to the exact `triage_context_hash`; the Judge signs `β_payload` with verdict Watch. β is attached to G\_candidate.

**Tier 5 — HITL.** The PM reviews the plan. The triage packet declared safe-range \[13, 17\] for the flagged predicate before review. The PM changes only that edge’s threshold from 15 to 14 — within the signed range, classified as a predicate-value edit, and requiring re-validation but not re-triage. The approved plan projects four eligible Feature–ValueMap pairs and eight ineligible pairs under the preview values. The PM signs `H(canonical_json(α_payload))`, where the structured α\_payload binds h\_pre, signer\_key\_id, and trust\_manifest\_hash. The authorized timestamp authority then signs the timestamp statement over that exact human signature, producing the complete α envelope.

**Compiler.full.** Validates all P-CADM conditions including exact Intent/`H_set` alignment, route and standard-task registration, typed artifact schemas, effect scope, reachability, and unique IDs. Computes γ over `H(concat(C_payload, canonical_signature_envelope(α)))`. Emits C with `id(C) = H(concat(C_payload, canonical_signature_envelope(α), canonical_signature_envelope(γ)))`.

**Execution.** The Executor verifies γ, α, the put-once commit-store record, and the latest authenticated lifecycle head before constructing scheduling state. In the illustrated run, total K\_r records one tagged `VALUE` decision for every PainPriority → ProductFeatureUJS activation edge; the Executor evaluates each predicate in Mode B and logs every decision to K\_log. Four Features and their four one-to-one ValueMaps become eligible and execute successfully; eight Features and their eight ValueMaps are SKIPPED. Pairing each Feature with its own ValueMap preserves the R13 eligible minimum for every eligible Feature; a single ValueMap shared by all 12 Features would not. The complete committed `top(C)` projection is preserved exactly. LLM content in each Feature node may differ across runs; Mode B claims eligibility replay from K\_log, not content repeatability.

**OutcomeBundle.** At run finalization, the Executor emits `O_r` binding the GGC and run IDs, Intent and `H_set` references, alignment record, route and tasks, effect-scope hash, trace and K\_log references, all node terminal statuses, and content-addressed references to the four completed Feature–ValueMap pairs. The eight skipped pairs remain visible as committed but ineligible outcomes. `O_r` grants no authority to create specifications or code. If the PM announces that Intent, it re-enters the same alignment, Plan, Compile, and Execute lifecycle through the applicable typed route.

**Outcome.** Not a guaranteed successful product: a user-directed, hypothesis-aligned, structurally admitted, domain-constrained, adversarially reviewed, PM-ratified, Compiler-attested execution record and OutcomeBundle. If the product fails because the market shifted, the retained Intent, `H_set`, GGC, OutcomeBundle, and authenticated lifecycle chain record what was authorized, why, by whom, what executed, and what evidence subsequently confirmed, weakened, or invalidated it.

That is the contribution. Not predicting the sea. Governing the voyage.

* * *

## 6\. Tier Composition and Control Coverage

DODGE provides one pre-Plan authority control plus five graph-governance controls for six gaps exhibited by the target class of ungoverned AI execution systems.

| Gap | Controlled by |
| --- | --- |
| G0 — Executable Intent detached from the user’s declared product direction | Pre-Plan H_set alignment; human-only amendment or exact-Intent exception |
| G1 — Artifact types and field schemas unconstrained | Tier 1: Domain-Method Schema + F/L |
| G2 — Artifact populations and relationship multiplicities unbounded | Tier 2: B_min/B_max + c_candidate/c_eligible |
| G3 — Activation logic opaque | Tier 3: κ + ρ/Φ |
| G4 — Plan confidence unexamined before HITL | Tier 4: Adversarial Triage |
| G5 — Candidate topology and predicates not human-ratified | Tier 5: Mandatory HITL |

Within this decomposition, omitting the alignment gate or a governance tier removes its corresponding control. Whether that omission increases outcome defects is tested empirically rather than established by the composition argument.

* * *

## 7\. Adversarial Validation Method and Author-Reported Implementation Status

*Sections 7.1-7.6 present the validation design. Section 7.7 reports scoped status from the author’s private repository; the underlying artifacts are not independently accessible with this manuscript. Empirical hypotheses H1-H6 remain future work; no empirical outcome results are reported.*

### 7.1 Claims Addressed by Formal Argument

| Claim | Evidence form | Manuscript status |
| --- | --- | --- |
| P-HALIGN: Hypothesis-aligned admission | Gate/Compiler/Executor construction argument (§4.10) | Conditional property specified; implementation demonstration pending |
| P-BLTS: \|T_legal(Σ)\| < ∞ | Formal proof sketch (§4.2) | Proof sketch stated; mechanization future work |
| P-CTI: Topology invariance | Construction argument (§4.3) | Conditional property stated; implementation correctness required |
| P-ERE-A/B: Replay equivalence | Proof sketches (§4.4) | Proof sketches stated; mechanization future work |
| P-CADM: Compiler admissibility | Enumerated admission contract (§4.5) | Soundness condition specified; author-reported implementation status separate |
| P-OUT: Runtime output admissibility | Executor contract (§4.5.1) | Conditional property specified |
| P-EDGE: Biconditional | Follows from P-CADM step 6 (§4.6) | Direct consequence of the admission contract |
| P-AUD: Auditability | Trace/store/lifecycle chain (§4.8) | Conditional proposition stated |
| P-IMM: Immutability, persistence, anti-rollback | Identity, store, and registry argument (§4.9) | Conditional proof sketch stated |
| T4a/T4b: Acyclicity, M:N bound | Proof sketches (§4.7) | Proof sketches stated |

### 7.2 Claims Requiring Implementation Demonstration

**Author-reported repository mechanism checks (DODGE v7.1)** means that the author reports a fail-closed check, test, or governed live-path artifact for the named mechanism in the private ship-mlp repository. The artifacts are not independently accessible with this manuscript. This status does **not** mean direct conformance to the revised v9.3 tuple, β/σ/χ/V\_root shapes, or the current §7.5 TC numbering. The v9.3 alignment limit in §7.7.4 applies to every row. Literal lowercase `dogdd` repository identifiers are retained where they are the actual artifact names.

| Claim | Test | Falsification | Status |
| --- | --- | --- | --- |
| Pre-Plan H_set alignment is mandatory | Submit low-match Intent; attempt Plan without alignment; forge H_set amendment or exact-Intent exception; attempt OutcomeBundle replay as authority | Any unaligned, low-match, agent-amended, or OutcomeBundle-authorized Intent enters Plan or Execute | Not yet implemented in the author-reported private substrate; this is a v9.3 alignment requirement |
| Compiler rejects illegal graphs | Feed adversarial planner outputs violating schema, cardinality, L, Φ, acyclicity, missing HITL, missing γ, etc. | Any illegal graph accepted | Author-reported v7.1 check: typed reject set covers malformed/duplicate/disconnected graphs, missing approval, issuer/authority faults, non-pure predicates, and field-bound widening; v9.3 schema-shape mapping pending |
| Route, task, artifact-schema, and effect-scope binding | Attempt an unregistered route/task, illegal artifact schema, or effect outside the compiled scope | Compiler or Executor admits scope widening | Author-reported analogous route/path checks exist; direct v9.3 registry and payload binding remains pending |
| OutcomeBundle is evidence-only | Present an OutcomeBundle directly to Plan or Execute without a fresh Intent and alignment record | New authority is inferred from prior results | Not yet implemented as the v9.3 OutcomeBundle contract |
| Executor is graph-closed | Attempt runtime node creation and mutation of roots, E_exec, E_audit, λ_V, λ_E, or ρ; attempt tool calls with non-V node IDs | Executor accepts any committed-topology mutation | Author-reported v7.1 check covers node/edge mutation and unknown-node rejection; direct full-top(C) coverage is pending |
| Runtime output admission enforces L | Submit a Worker output exceeding a committed field bound | Over-bound output is stored or a dependent is released | Author-reported v7.1 check: per-effect field-bound authorization rejects an over-bound write; the v9.3 BLOCKED/ACTIVATION_CONTEXT_INCOMPLETE state mapping is pending |
| Material edit rules enforced | Make structural and predicate-value edits; verify Compiler triggers re-triage on material; admits non-material within safe-range | Re-triage skipped on material edit | Author-reported v7.1 check: material-edit classification and safe-range rejection exist; direct mapping to v9.3 β_payload and predicate-AST rules is pending |
| Hash + signature/approval verification on load | Tamper with C; remove α; present a correctly formed γ with an invalid or untrusted Compiler signature | Modified or unauthorized GGC executes | Author-reported v7.1 mapping: the older check API rejects untrusted issuer references; RFC-0240 records Ed25519 invalid-signature and key-custody status; direct mapping to the v9.3 timestamp-proved α envelope, historical trust-manifest authorization, and carried extension map is pending |
| Mode B replay | Run identical C with K_log replay twice; verify identical G_eligible | Activation diverges under replay | Author-reported v7.1 check: content-addressed K_log replay and a Mode C-as-Mode B invalid-claim flag; direct mapping to staged K_{r,t}, χ, admitted-source output identity, and exact committed-ρ projection binding is pending |
| Lifecycle integrity and freshness | Modify/reorder a transition, substitute a registry, use a revoked role key, or present a stale head | Modified, unauthorized, alternate-registry, or rolled-back state appears current | Author-reported v7.1 check covers hash-linked tamper detection, terminal-state refusal, a v7.1-specific governed-override mechanism, and RFC-0240 signatures; that override is not admissible under v9.3, while effective-dated role authorization, trust-history validation, authoritative registry/head-signer binding, latest-head freshness, and anti-rollback also remain mapping gaps |

### 7.3 Claims Requiring Empirical / User-Study Evidence

| Claim | Hypothesis ID | Study design | Baseline |
| --- | --- | --- | --- |
| Adversarial triage reduces defect rate | H1 | Seeded structural defects; measure PM detection rate with vs without Tier 4 | PM review without triage |
| Triage diversity matters | H2 | Same-model panel vs multi-model panel; measure Reject precision/recall | Same-model panel |
| DODGE reduces structural process failures | H3 | PM task completion study with vs without DODGE constraints | Unconstrained LLM agent; LangGraph + HITL |
| DODGE improves audit reconstruction | H4 | GGC + τ + K_log + lifecycle chain vs LangGraph checkpoint; auditors reconstruct who-approved-what | LangGraph checkpoint baseline |
| Field-level L bounds reduce semantic scope creep | H5 | Measure feature/feature-acceptance counts with vs without L | Topology cardinality only |
| Hypothesis-aligned IPCE preserves Intent-to-effect traceability | H6 | Verify that every executed effect and typed artifact resolves to an admitted Intent, active H_set, alignment decision, compiled route/task, schema, effect scope, HITL approval, GGC, trace event, and OutcomeBundle reference | Direct agent execution without H_set alignment or compiled route authority |

H1–H6 are the manuscript’s explicitly testable outcome hypotheses. Motivational observations are not reported results, and the §7.7 evidence discharges none of them.

### 7.4 Baseline Systems

1. Bare LLM agent (no governance)
2. Prompt-constrained agent (NBM4 in system prompt)
3. LangGraph workflow with HITL interrupts
4. Temporal workflow with replay
5. Agentproof-style verification of an existing workflow
6. DODGE Tier 1 only (ablation)
7. DODGE Tiers 1+2 (ablation)
8. DODGE Tiers 1+2+3 (ablation)
9. DODGE Tiers 1+2+3+4 (ablation)
10. Full DODGE (`H_set` alignment + registered route/tasks/schemas + all five graph-governance tiers + γ + L + lifecycle chain + OutcomeBundle)

### 7.5 Adversarial Conformance Test Cases

| TC | Attack | Expected |
| --- | --- | --- |
| TC-1 | ProductFeatureUJS node at Stage 2 | Schema rejection |
| TC-2 | 13 ProductFeatureUJS nodes when B_max(A18)=12 | Instance-bound rejection |
| TC-3 | Activation predicate: “ask the LLM whether this pain is important” | Φ rejection |
| TC-4 | Back-edge from Feature to Persona | Stage-forward rejection |
| TC-5 | Missing HITL approval record α | HITL proof rejection |
| TC-6 | activates edge without predicate | P-EDGE rejection |
| TC-7 | Intra-stage cycle A→B→A within Stage 3 | Intra-stage DAG rejection |
| TC-8 | Triage verdict = Reject, no new triage for modified plan | Triage proof rejection |
| TC-9 | Runtime attempt to spawn a node or alter V_root, E_exec, E_audit, λ_V, λ_E, or ρ | Executor rejection + violation log |
| TC-10 | Tool call referencing node ID not in V | Executor rejection + violation log |
| TC-11 | Missing γ; α present but no Compiler attestation | γ-verification rejection |
| TC-12 | Correctly formed γ bears an invalid signature or a signature from a Compiler key outside the trusted effective key set | Cryptographic trust-anchor rejection |
| TC-13 | Schedulable node unreachable from the root set through E_exec | P-CADM reachability rejection |
| TC-14 | Duplicate node ID in V | P-CADM uniqueness rejection |
| TC-15 | PersonaProfile.description exceeds L bound | Field-level scope rejection |
| TC-16 | Same-model-family triage panel | Diversity-requirement rejection |
| TC-17 | Structural edit to G_approved without new β | Material-edit re-triage rejection |
| TC-18 | Predicate-value edit outside declared safe range | Material-edit rejection |
| TC-19 | Modified lifecycle transition record (chain tamper) | Lifecycle-chain rejection |
| TC-20 | Mode C run claimed under Mode B replay claim | Replay claim flagged invalid; exploratory execution is not rejected on this basis |
| TC-21 | LOW_MATCH Intent sent directly to Planner without human H_set amendment or exact-Intent exception | Pre-Plan alignment rejection |
| TC-22 | Agent-authored H_set mutation, threshold reduction, or exception presented as human authority | Hypothesis-authority rejection |
| TC-23 | OutcomeBundle supplied as authority for a new Plan, route, effect, or execution | Fresh-Intent/IPCE-required rejection |

### 7.6 What Evidence Would Falsify DODGE

DODGE’s core claims are falsified if:

- Any TC-1 through TC-19 or TC-21 through TC-23 passes the responsible alignment gate, Compiler, Executor, commit-store, or lifecycle-registry surface
- TC-20 is accepted as a valid Mode B replay claim
- Mode A or Mode B replay produces different G\_eligible under identical C and K (or K\_log)
- The Executor accepts a modified or unauthorized GGC without valid α and γ under the effective trusted-key policy
- A prior system is shown, with primary-source support, to directly satisfy five or more axes in the seven-axis substance grid (§2.3)

**Author-reported implementation-status note.** The author reports that the private repository’s `dogdd-v7-1-conformance.test.mjs` executes twenty fail-closed suite rows, but its TC numbering and semantics are not the same as this revised §7.5 table, and its `PAPER_ATTACK_MAP` retains an explicit `owned-gap` row. It does not cover TC-21 through TC-23 as defined here. Therefore this repository-local status is not a direct assertion that every v9.3 conformance case is green. A refreshed v9.3 crosswalk, suite, and independently accessible evidence package are required before making that claim.

### 7.7 Author-Reported Implementation Status and Alignment Boundary

*This section reports status from the author’s private repository, not independently accessible implementation evidence or empirical outcome evidence. It identifies which v7.1 mechanisms the author reports and where direct conformance to the revised v9.3 formal model remains unproven. It does not claim that a reader can inspect the current repository suite or that the suite directly enforces every v9.3 condition in Sections 3–4 or every attack in §7.5.*

#### 7.7.1 Evidence provenance

The status base is the author’s private ship-mlp repository and is not publicly accessible in this version. Repo-relative paths below identify internal artifacts but are not reader-retrievable citations. No public repository release, immutable commit, archived artifact, or ancillary arXiv evidence package is cited; §7.7 therefore records author-reported repository-local status only.

Within that scope, the author reports that DODGE v7.1 checks were produced through RFC-0220 and RFC-0235, then extended by RFC-0240. The private machine-readable ledger at `.0-mlp/5_governance/ledgers/dogdd/rfc-0235-conformance-ledger.jsonc` is reported as `status: GREEN` as of 2026-07-06 and as recording the former live-path and asymmetric-key-custody deviations as CLOSED. It also records a now-retired L3-to-L2 projection experiment that is outside the current model and supplies no evidence for v9.3. These repository-local assertions do not independently establish v7.1 behavior or conformance to v9.3.

#### 7.7.2 Mechanisms Reported by the Author

The author reports that the private conformance surface mechanically asserts:

- **Full commit binding.** The author reports that the `GovernedGraphCommit` evidence schema binds its v7.1 commit fields — graph, per-node λ with field-level bounds, per-node ρ flags, v7.1 κ and β subschemas, plus α, γ, σ, μ, route-plan state, authority envelope, and commit-time lifecycle/evidence references. The per-node ρ flags are reported as an implementation surrogate and do not directly realize the v9.3 per-edge function `ρ : E_exec → Φ ∪ {⊤}`. The reported canonical projection hash of implementation-specific fields is analogous to `extensions_hash`, but direct carriage and verification of the corresponding implementation\_extension\_map under the v9.3 transit contract are not established; §7.7.4 scopes the remaining alignment gap.
- **Compiler admission (`compile.check`).** The author reports typed, fail-closed rejections for open-ended plans, malformed graphs, duplicate and disconnected nodes, missing α, untrusted Compiler issuer references, stale or path-widened authority, unsupported routes, non-pure activation predicates (`COMPILE_PHI_NON_PURE` for LLM/clock/randomness/external-state sources), unbounded aggregation, non-immediate-predecessor field references, field-bound widening (`COMPILE_FIELD_BOUND_WIDENING`), and contradictory authority.
- **Executor admission (`execute.check`).** The author reports graph-closed admission that accepts only the current signed commit; typed rejections for tampered, stale, missing-α, untrusted-anchor, and non-current commits; `EXECUTE_TOPOLOGY_MUTATION` and `EXECUTE_NODE_NOT_IN_V` for closure violations; per-effect path and field-bound authorization (`EXECUTE_EFFECT_NOT_AUTHORIZED`); and an ordering guarantee that every admission rejection occurs before runtime adjacency/state construction.
- **Replay and lifecycle.** The author reports that content-addressed `K_log` build/replay produces identical v7.1 active-node sets across declared routes and that replay-mode tags flag Mode C-as-Mode B replay assertions as invalid without rejecting the underlying exploratory execution on that basis. A hash-linked lifecycle chain is reported to detect edit/reorder tamper, carry evidence classifications, refuse terminal states, and admit a v7.1-specific governed-override path; that override does not satisfy v9.3’s unconditional INVALIDATED/SUPERSEDED/ARCHIVED refusal rule. RFC-0240 is reported as adding Ed25519 signature and key-custody checks. Mapping these surfaces to v9.3 G\_eligible, staged K\_{r,t}, χ, effective-dated authorization, authenticated heads, and anti-rollback remains pending.
- **Triage, edits, collapse, and Σ-meta.** The v7.1 surfaces are reported to enforce model/prompt-family diversity, safe ranges, edit classification, runtime-cardinality-collapse records, and governed σ-meta revisions. Their β verdict vocabulary and field shapes, κ meaning, and σ representation differ from v9.3 β\_payload, cardinality functions, and complete-policy bundle, so this is author-reported analogous mechanism status rather than tuple-level conformance.
- **The v7.1 TC suite.** The author reports that `dogdd-v7-1-conformance.test.mjs` contains twenty suite rows and a separate paper-attack map. The suite TC IDs do not carry the same meanings as this paper’s current TC-1 through TC-23, and the paper-attack map is reported to contain an explicit `owned-gap` row. Full trace reconstruction and multiple fail-closed checks are reported, but direct current-paper coverage is not claimed.
- **Prompt-intake gate (v9.3, §3.14).** The author reports a live fail-closed prompt-intake gate across three agent harnesses: every action prompt requires a typed `PromptIntentGateDecision` logged to SEL before any non-logger tool action is admitted, with banded thresholds, optional second-family score arbitration under a lower-score-wins rule, a transport-carried score ceiling that prevents post-hoc score inflation, and a downstream planning gate requiring a typed `IntentPlanningDecision` before write, compile, or execute effects. This mechanism is upstream of the v9.3 `H_set` alignment contract and does not implement it.
- **Stage-decision ledgers and planner rejection loop (v9.3, §3.14–§3.15).** The author reports append-only route/planner/compiler/executor stage-decision ledgers populated by live governed voyages, and a bounded planner rejection loop in which typed Compiler rejection payloads admit at most three replans before HITL escalation with structured repair guidance.

#### 7.7.3 Author-Reported Claim-Gate Behavior

The author reports that v7.1 release wording is governed by a machine-readable conformance ledger and an executable claim gate. At the time of writing, the private ledger is reported as GREEN, both former deviations are reported as CLOSED, and its policy is reported to permit full DODGE v7.1 claim wording while the green predicate remains satisfied. That private machine decision is scoped to the v7.1 implementation contract and its own suite semantics; it is not independently inspectable here and does not establish that the revised v9.3 formal tuple or §7.5 table is implemented. This paper therefore records the author-reported green v7.1 status while retaining an explicit v9.3 realignment limit.

#### 7.7.4 Author-Reported Closed v7.1 Deviations and Open v9.3 Alignment Limit

The author reports that the private ledger records the two deviations reported by the prior manuscript version as CLOSED. A third item recorded under RFC-0240 WI-34 — an L3-to-L2 projection experiment — is retired as outside the current model rather than closed as a deviation, supplies no evidence for v9.3, and is therefore not counted here (§7.7.1, D.3):

| Former deviation | Closure mechanism reported by the author | Reported v7.1 status |
| --- | --- | --- |
| Live-path substrate unification | RFC-0240 WI-30R wires the governed Dispatcher path through compile.check → GovernedGraphCommit → execute.check | CLOSED |
| Cryptographic key custody | RFC-0240 WI-33 adds Ed25519 signature envelopes, custody, rotation, revocation, and invalid-signature evidence for α, γ, and lifecycle records | CLOSED |

One manuscript-to-implementation alignment limit remains open: **v9.3 formal-model and suite realignment**. The author reports that the v7.1 schema does not directly encode the v9.3 `H_set` initialization and human-ratification record, pre-Plan alignment/exception contract, Intent and `H_set` GGC bindings, registered route/task/artifact-schema references, finite effect scope, OutcomeBundle contract, full `top(C)` projection, commit-time ν map, B\_min/B\_max, complete finite F/Path/L bundle, role-to-μ references, context-bound three-role triage attestations, supersedes\_id, complete-policy σ/Π\_σ resolution, χ, source-bound VALUE provenance, timestamp-proved α envelope, or carried implementation\_extension\_map. Its per-node ρ flags are reported as a v7.1 implementation surrogate rather than the v9.3 per-edge ρ function; κ and verdict vocabularies differ from Score\_bp and the v9.3 verdict contract; staged K\_{r,t}, the put-once commit store, unconditional terminal-state refusal, effective-dated lifecycle authorization, authenticated latest head, anti-rollback checks, and TC-21 through TC-23 are not directly asserted as v9.3 specifies. Until a refreshed schema projection, content-addressed Σ\_NBM4 bundle, test crosswalk, suite, and immutable public evidence package are cited, §7.7 remains an author-reported status account, not direct evidence of v7.1 behavior or full v9.3 conformance.

* * *

## 8\. Conclusion and Future Work

### 8.1 Summary

This paper introduced **Domain-Ordered Directed Graph Execution (DODGE)**, a hypothesis-aligned IPCE architecture with a five-tier graph-governance stack parameterized over a domain-method schema Σ. In a conforming implementation, every executable Intent first aligns with the active human-ratified `H_set` or carries an exact human-approved exception. Open-ended AI planning is not admissible to the graph-closed Executor until registered routes, standard tasks, typed artifact schemas, effect scope, topology, triage, and HITL evidence become a compiler-attested Governed Graph Commit. Execute returns a non-authorizing OutcomeBundle. The contribution is this conjunction, not novelty in any individual primitive.

No surveyed comparator directly satisfies five or more of the seven defined axes (§2.3); reviewers can falsify that bounded conjunction claim by naming and sourcing a qualifying system.

DODGE is parameterized over a domain-method schema Σ. NBM4 is the primary reference method, with two profiles whose policy bundles are content-addressed by σ; DODGE-RFC is sketched in Appendix C. The formal properties remain conditional on their stated `H_set`, alignment/exception, route/task/artifact registry, schema, effect-scope, Executor, activation-context, storage, registry, audit-channel, and cryptographic assumptions.

The author reports repository-local DODGE v7.1 mechanism checks and a green v7.1 ledger, but the underlying private artifacts are not independently accessible in this version. Direct v9.3 conformance remains unestablished because the revised tuple, schema bundle, lifecycle/store contracts, and test meanings have not been mapped and publicly cited (§7.7).

We do not claim deterministic outcomes, deterministic LLM content, unique graph generation from intent, empirical improvement, or direct v9.3 implementation conformance. Mode B is the practical default. Mechanized proofs, a cited complete Σ\_NBM4 bundle, a refreshed v9.3 implementation crosswalk, and empirical studies remain future work.

### 8.2 Limitations

**Single concrete domain instantiation.** DODGE is parameterized over a domain-method schema Σ; NBM4 is the primary domain method instantiated here; DODGE-RFC in Appendix C is a sketch with an operational-status note (C.6), not a fully worked example. A worked second instantiation with empirical observations remains future work.

**Empirical validation pending.** All H1–H6 are study designs, not reported results. The §7.7 author-reported status describes analogous v7.1 mechanisms but supplies neither independently accessible implementation evidence nor outcome evidence or direct v9.3 conformance.

**Alignment is not truth.** `H_set` and the alignment score express fidelity to the user’s ratified direction, not market validity or product quality. A poorly framed `H_set` can faithfully govern the wrong strategy. Human amendment and exact-Intent exception authority preserve user sovereignty but also remain trusted decision points.

**Initialization and drift.** The first executable cycle depends on a human-ratified initial `H_set`; DODGE-NBM4 proposes structured PM interviewing, but this process is not yet implemented or empirically validated. Stale hypotheses, ambiguous matches, evaluator drift, and exception overuse require monitoring and explicit version changes rather than silent agent adaptation.

**v9.3 implementation alignment pending.** The author reports private live-path and key-custody closure, but the landed schema and suite do not directly encode or test the v9.3 `H_set` and alignment gate, human-only amendment/exception authority, Intent/`H_set`/route/task/artifact-schema/effect-scope GGC bindings, OutcomeBundle, full top(C), commit-time ν, B\_min/B\_max, complete F/Path/L, role-to-μ references and context-bound three-role attestations, supersedes\_id, per-edge ρ, complete-policy σ/Π\_σ resolution, χ with staged source-bound K\_{r,t}, the Score\_bp κ contract, a timestamp-proved α envelope, a carried implementation\_extension\_map, the put-once store, unconditional terminal-state refusal, effective-dated lifecycle authorization, authoritative authenticated heads, anti-rollback, or revised §7.5 semantics. Direct v9.3 conformance therefore remains unestablished (§7.7.4).

**Complete NBM4 content-scope bundle not cited.** Appendix B is a selected readable projection. Until a content-addressed machine-readable F/L bundle covering every variable-length typed path is cited and included in Π\_σ, whose canonical hash is σ, this manuscript does not establish complete DODGE-NBM4 content-scope conformance.

**Triage quality depends on panel.** Adversarial triage is a confidence filter, not a soundness oracle. The diversity requirement (≥2 model families) is a necessary but not sufficient condition for panel calibration.

**Φ expressiveness ceiling.** Bounded aggregation extends Φ, but Φ remains intentionally restricted: no transitive-predecessor field references (Option A scope), no unbounded aggregation, no LLM calls inside predicates. Sufficiently complex activation logic still requires lifting into the source node’s output computation.

**TCB and threat model.** A compromised Compiler key allows forged γ; mitigation requires isolated custody, signed Compiler binaries, rotation, revocation, and runtime attestation where warranted. A compromised authorized human key can approve a malicious but structurally valid payload; it cannot forge γ or bypass Compiler checks, but an honest Compiler may attest the payload if all checks pass. Multi-party approval thresholds are not supported by the v9.3 α contract and are future work (§3.10). Schema corruption is mitigated by Σ-meta-DODGE governance (§3.13), but Σ\_meta, `Π_σ.trust_history_root`, the commit store, lifecycle registry, and freshness source remain trust anchors. The author reports Ed25519 custody closure for v7.1 under RFC-0240 WI-33; that private repository-local record is not independently accessible or an archived security assessment and does not prove revised v9.3 alignment.

**Eligible cardinality lower bounds are runtime postconditions.** In Mode B/C they are evaluated only after total K defines final E\_eligible. `ACTIVATION_CONTEXT_INCOMPLETE` yields no c\_eligible conclusion; a defined lower-bound violation triggers §3.5.1.

**Mode C does not support replay.** Runs whose activation values are recomputed via LLM each time forfeit P-ERE-B; topology invariance still holds.

### 8.3 Future Work

**Priority 1 — Empirical validation.** Execute H1-H6 from §7.3: PM user study with full ablation baseline matrix, audit reconstruction study, triage diversity comparison, and field-level L scope-creep study.

**Priority 2 — v9.3 implementation alignment and public evidence pin.** Extend the reference schema and runtime for `H_set` initialization/ratification, pre-Plan alignment and human-only amendment/exception authority, Intent/`H_set`/route/task/artifact-schema/effect-scope GGC bindings, OutcomeBundle, full top(C), commit-time ν, B\_min/B\_max, complete F/Path/L, role-to-μ references and context-bound three-role attestations, supersedes\_id, per-edge ρ, complete-policy σ/Π\_σ resolution, χ and staged source-bound K\_{r,t}, Score\_bp κ, a timestamp-proved α envelope, a carried implementation\_extension\_map, the put-once store, unconditional terminal-state refusal, effective-dated lifecycle authorization, authoritative authenticated heads, anti-rollback, and revised TC semantics. Publish the complete Σ\_NBM4 bundle, refresh the crosswalk and suite, and cite an immutable public evidence package.

**Priority 3 — Second worked domain instantiation.** Promote Appendix C DODGE-RFC from sketch to worked example with empirical observations from ship-mlp governance.

**Priority 4 — Mechanized proofs.** Formalize P-HALIGN, P-BLTS, P-ERE-A/B, P-CADM, T4a, and T4b in a proof assistant such as Coq, Lean 4, or Agda.

**Priority 5 — Φ extensions.** Evaluate bounded transitive-predecessor references, temporal predicates over execution traces, and user-defined typed aggregations.

**Priority 6 — Σ-meta-DODGE operationalization.** Complete a reference Σ\_meta bootstrap and migration tooling for external adopters.

**Priority 7 — Reliability property P-REL.** Define conditions under which G\_executed approaches G\_eligible: bounded-retry semantics, idempotency requirements on Worker outputs, timeout policies, and supersession behavior for partially failed execution.

**Priority 8 — Prompt-intake gate calibration (new in v9.3).** Measure the calibration of self-assessed intent-confidence scores (§3.14) against human-judged interpretation correctness across model families; evaluate the dual-evaluator lower-score-wins rule against single-evaluator baselines; and determine whether the margin-band confirmation stop measurably reduces misinterpreted-execution incidents. Until such a study exists, the intake gate’s thresholds are engineering choices, not validated calibration points.

* * *

## References

Bai, Y., et al. (2022). Constitutional AI: Harmlessness from AI Feedback. *arXiv:2212.08073*. [https://arxiv.org/abs/2212.08073](https://arxiv.org/abs/2212.08073). DOI: [https://doi.org/10.48550/arXiv.2212.08073](https://doi.org/10.48550/arXiv.2212.08073).

Beck, K. (2002). *Test-Driven Development: By Example*. Addison-Wesley. [https://dl.acm.org/doi/10.5555/579193](https://dl.acm.org/doi/10.5555/579193).

Bench-Capon, T. J. M., & Dunne, P. E. (2007). Argumentation in artificial intelligence. *Artificial Intelligence*, 171(10-15), 619-641. DOI: [https://doi.org/10.1016/j.artint.2007.05.001](https://doi.org/10.1016/j.artint.2007.05.001).

Cardelli, L. (1996). Type systems. *ACM Computing Surveys*, 28(1), 263-264. DOI: [https://doi.org/10.1145/234313.234418](https://doi.org/10.1145/234313.234418).

Chen, P. P.-S. (1976). The entity-relationship model — toward a unified view of data. *ACM Transactions on Database Systems*, 1(1), 9-36. DOI: [https://doi.org/10.1145/320434.320440](https://doi.org/10.1145/320434.320440).

Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Know your customers’ jobs to be done. *Harvard Business Review*, 94(9), 54-62. [https://hbr.org/2016/09/know-your-customers-jobs-to-be-done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done).

Cleland-Huang, J., Gotel, O., Huffman Hayes, J., Mäder, P., & Zisman, A. (2014). Software traceability: Trends and future directions. *Future of Software Engineering Proceedings (FOSE 2014)*, 55-69. DOI: [https://doi.org/10.1145/2593882.2593891](https://doi.org/10.1145/2593882.2593891).

Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009). *Introduction to Algorithms* (3rd ed.). MIT Press. [https://mitpress.mit.edu/9780262533058/introduction-to-algorithms/](https://mitpress.mit.edu/9780262533058/introduction-to-algorithms/).

Dung, P. M. (1995). On the acceptability of arguments and its fundamental role in nonmonotonic reasoning, logic programming and n-person games. *Artificial Intelligence*, 77(2), 321-357. DOI: [https://doi.org/10.1016/0004-3702(94)00041-X](https://doi.org/10.1016/0004-3702\(94\)00041-X).

Gotel, O. C. Z., & Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. *Proceedings of the First International Conference on Requirements Engineering*, 94-101. DOI: [https://doi.org/10.1109/ICRE.1994.292398](https://doi.org/10.1109/ICRE.1994.292398).

Irving, G., Christiano, P., & Amodei, D. (2018). AI safety via debate. *arXiv:1805.00899*. [https://arxiv.org/abs/1805.00899](https://arxiv.org/abs/1805.00899). DOI: [https://doi.org/10.48550/arXiv.1805.00899](https://doi.org/10.48550/arXiv.1805.00899).

Kahn, A. B. (1962). Topological sorting of large networks. *Communications of the ACM*, 5(11), 558-562. DOI: [https://doi.org/10.1145/368996.369025](https://doi.org/10.1145/368996.369025).

Kozloff, M. (2024). The NBM4: Your Guide to Innovative Business Models & Products. *NBM4.com*. [https://nbm4.com/articles/nbmf-guide-intro/](https://nbm4.com/articles/nbmf-guide-intro/ "https://nbm4.com/articles/nbmf-guide-intro/"). Accessed 2026-07-11.

Kozloff, M. (2026). *ship-mlp Architecture Blueprint v0.7.1*. Private DRAFT repository artifact superseding v0.7; no public archival metadata is cited in this version.

LangChain. (2026). *LangGraph documentation*. [https://docs.langchain.com](https://docs.langchain.com/). Accessed 2026-07-09.

Marri, S. R. (2026). Constitutional Spec-Driven Development: Enforcing Security by Construction in AI-Assisted Code Generation. *arXiv:2602.02584*. [https://arxiv.org/abs/2602.02584](https://arxiv.org/abs/2602.02584). DOI: [https://doi.org/10.48550/arXiv.2602.02584](https://doi.org/10.48550/arXiv.2602.02584).

McCann, A. L. (2026). Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation. *arXiv:2605.01037*. [https://arxiv.org/abs/2605.01037](https://arxiv.org/abs/2605.01037). DOI: [https://doi.org/10.48550/arXiv.2605.01037](https://doi.org/10.48550/arXiv.2605.01037).

Microsoft. (2026). *AutoGen documentation*. [https://microsoft.github.io/autogen/stable/](https://microsoft.github.io/autogen/stable/). Accessed 2026-07-09.

Morris, D. H., Valles, L., & Hosseini Ghomi, R. (2026). GraphFlow: An Architecture for Formally Verifiable Visual Workflows Enabling Reliable Agentic AI Automation. *arXiv:2605.14968*. [https://arxiv.org/abs/2605.14968](https://arxiv.org/abs/2605.14968). DOI: [https://doi.org/10.48550/arXiv.2605.14968](https://doi.org/10.48550/arXiv.2605.14968).

National Institute of Standards and Technology. (2015). *Secure Hash Standard (SHS)*. FIPS PUB 180-4. DOI: [https://doi.org/10.6028/NIST.FIPS.180-4](https://doi.org/10.6028/NIST.FIPS.180-4).

Nau, D., Cao, Y., Lotem, A., & Muñoz-Avila, H. (1999). SHOP: Simple Hierarchical Ordered Planner. *Proceedings of IJCAI-99*, 968-973. [https://www.ijcai.org/Proceedings/99-2/Papers/043.pdf](https://www.ijcai.org/Proceedings/99-2/Papers/043.pdf).

Nau, D., Au, T.-C., Ilghami, O., Kuter, U., Murdock, J. W., Wu, D., & Yaman, F. (2003). SHOP2: An HTN Planning System. *Journal of Artificial Intelligence Research*, 20, 379-404. DOI: [https://doi.org/10.1613/jair.1141](https://doi.org/10.1613/jair.1141).

Newman, Z., Meyers, J. S., & Torres-Arias, S. (2022). Sigstore: Software signing for everybody. *Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security*. DOI: [https://doi.org/10.1145/3548606.3560596](https://doi.org/10.1145/3548606.3560596). Project overview: [https://www.sigstore.dev/](https://www.sigstore.dev/).

Object Management Group. (2014). *Business Process Model and Notation (BPMN) Version 2.0.2*. OMG Document formal/2014-01-02. [https://www.omg.org/spec/BPMN/2.0.2/](https://www.omg.org/spec/BPMN/2.0.2/).

OpenAI. (2026). *Agents SDK documentation*. [https://openai.github.io/openai-agents-python/](https://openai.github.io/openai-agents-python/). Accessed 2026-07-09.

OpenAI. (2026). *Structured Outputs documentation*. [https://developers.openai.com/api/docs/guides/structured-outputs](https://developers.openai.com/api/docs/guides/structured-outputs). Accessed 2026-07-09.

OpenSSF. (2026). *SLSA specification v1.2*. [https://slsa.dev/spec/v1.2/](https://slsa.dev/spec/v1.2/). Accessed 2026-07-09.

Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). *Value Proposition Design: How to Create Products and Services Customers Want*. Wiley. [https://www.wiley.com/en-us/Value%2BProposition%2BDesign%3A%2BHow%2Bto%2BCreate%2BProducts%2Band%2BServices%2BCustomers%2BWant-p-9781118968055](https://www.wiley.com/en-us/Value%2BProposition%2BDesign%3A%2BHow%2Bto%2BCreate%2BProducts%2Band%2BServices%2BCustomers%2BWant-p-9781118968055).

Piskala, D. B. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. *arXiv:2602.00180*. [https://arxiv.org/abs/2602.00180](https://arxiv.org/abs/2602.00180). DOI: [https://doi.org/10.48550/arXiv.2602.00180](https://doi.org/10.48550/arXiv.2602.00180).

Reynolds, J. C. (1974). Towards a theory of type structure. *Programming Symposium*, 408-425. DOI: [https://doi.org/10.1007/3-540-06859-7\_148](https://doi.org/10.1007/3-540-06859-7_148).

Ries, E. (2011). *The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown Business. [https://theleanstartup.com/](https://theleanstartup.com/).

Rosen, J., & Rosen, S. (2026). From Agent Loops to Deterministic Graphs: Execution Lineage for Reproducible AI-Native Work. *arXiv:2605.06365*. [https://arxiv.org/abs/2605.06365](https://arxiv.org/abs/2605.06365). DOI: [https://doi.org/10.48550/arXiv.2605.06365](https://doi.org/10.48550/arXiv.2605.06365).

Rundgren, A., Jordan, B., & Liusvaara, I. (2020). *JSON Canonicalization Scheme (JCS)*. RFC 8785. [https://www.rfc-editor.org/rfc/rfc8785](https://www.rfc-editor.org/rfc/rfc8785). DOI: [https://doi.org/10.17487/RFC8785](https://doi.org/10.17487/RFC8785).

The Apache Software Foundation. (2026). *Apache Airflow documentation*. [https://airflow.apache.org/docs/](https://airflow.apache.org/docs/). Accessed 2026-07-09.

The Dagster Authors. (2026). *Dagster documentation*. [https://docs.dagster.io](https://docs.dagster.io/). Accessed 2026-07-09.

The GitHub Spec Kit Authors. (2026). *Spec Kit documentation*. [https://github.github.com/spec-kit/](https://github.github.com/spec-kit/). Accessed 2026-07-09.

The Guardrails AI Authors. (2026). *Guardrails AI documentation*. [https://guardrailsai.com](https://guardrailsai.com/). Accessed 2026-07-09.

The Prefect Authors. (2026). *Prefect documentation*. [https://docs.prefect.io](https://docs.prefect.io/). Accessed 2026-07-09.

Temporal Technologies. (2026). *Temporal workflow documentation*. [https://docs.temporal.io](https://docs.temporal.io/). Accessed 2026-07-09.

Torres, T. (2021). *Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value*. Product Talk LLC. [https://www.producttalk.org/continuous-discovery-habits/](https://www.producttalk.org/continuous-discovery-habits/).

Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R., & Cappos, J. (2019). in-toto: Providing farm-to-table guarantees for bits and bytes. *USENIX Security Symposium*. [https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias).

Wasowski, J. (2026). Stop writing specs. Start writing facts. The entire SDD movement is already obsolete. *Medium*. [https://medium.com/@wasowski.jarek/stop-writing-specs-start-writing-facts-the-entire-sdd-movement-is-already-obsolete-9045f7061e26](https://medium.com/@wasowski.jarek/stop-writing-specs-start-writing-facts-the-entire-sdd-movement-is-already-obsolete-9045f7061e26).

Wang, S., Hou, X., Zhao, Y., Cheng, X., & Wang, H. (2026). AgentFlow: Building Agent Dependency Graphs for Static Analysis of Agent Programs. *arXiv:2607.01640*. [https://arxiv.org/abs/2607.01640](https://arxiv.org/abs/2607.01640). DOI: [https://doi.org/10.48550/arXiv.2607.01640](https://doi.org/10.48550/arXiv.2607.01640).

Xavier, M., Vaisakh M A, Jolly, M., & Xavier, M. (2026). Agentproof: Static Verification of Agent Workflow Graphs. *arXiv:2603.20356*. [https://arxiv.org/abs/2603.20356](https://arxiv.org/abs/2603.20356). DOI: [https://doi.org/10.48550/arXiv.2603.20356](https://doi.org/10.48550/arXiv.2603.20356).

Yue, Y., et al. (2026). From Static Templates to Dynamic Runtime Graphs: A Survey of Workflow Optimization for LLM Agents. *arXiv:2603.22386*. [https://arxiv.org/abs/2603.22386](https://arxiv.org/abs/2603.22386). DOI: [https://doi.org/10.48550/arXiv.2603.22386](https://doi.org/10.48550/arXiv.2603.22386).

## Appendix A: Formal Definitions, Notation, and Φ Grammar

### Definition A.1 (Domain-Method Schema)

A domain-method schema is the machine-checkable encoding of a domain method. It is a tuple Σ = (S, A, f, F, L, R, c\_candidate, c\_eligible, B\_min, B\_max, Φ, Ψ) where:

- S = {s₁ < s₂ < … < sₙ} is a finite totally ordered stage set
- A is a finite artifact type universe
- f: A → S is a total stage assignment
- F maps every a ∈ A to a finite, acyclic, nonrecursive typed output-field schema
- Path(F(a)) is the finite set of addressable nested typed paths induced by F(a), including collection-element projections
- L: (a ∈ A, path ∈ Path(F(a))) → ScopeBound is total; every variable-length string or collection path has a finite bound
- R ⊆ A × A × Σ\_edge is the set of legal typed relationship schemas, Σ\_edge = {derives\_from, evidence\_for, activates, requires}
- c\_candidate: R → (ℕ × ℕ) × (ℕ × ℕ) gives outgoing and incoming bounds on candidate edges (min\_out, max\_out, min\_in, max\_in)
- R\_exec = {r ∈ R | semantic(r) ∈ {requires, derives\_from, activates}}
- c\_eligible: R\_exec → (ℕ × ℕ) × (ℕ × ℕ) gives per-endpoint outgoing and incoming runtime postconditions over final E\_eligible after total K; incomplete activation context yields no conclusion
- B\_min, B\_max: A → ℕ give artifact-type population bounds with 0 ≤ B\_min(a) ≤ B\_max(a) < ∞
- Φ is the typed activation predicate language defined below
- Ψ is the static structural-constraint set: legal root types and cardinality, root `E_exec` in-degree zero, rejection of non-root nodes with `E_exec` in-degree zero, `E_exec` reachability from V\_root, node-identifier uniqueness, required fields, and stage-local ordering rules. Every in-degree condition in Ψ is counted over `E_exec` alone (A.10)

Legal edge condition: (aᵢ, aⱼ, σ\_edge) ∈ R only if f(aᵢ) < f(aⱼ) (for inter-stage σ\_edge ∈ {activates, derives\_from, evidence\_for, requires}) or f(aᵢ) = f(aⱼ) (for intra-stage σ\_edge ∈ {activates, requires, derives\_from, evidence\_for}). Secondary DAG validation applies to intra-stage E\_exec = {activates, requires, derives\_from}; `evidence_for` remains audit-only and is excluded from scheduler acyclicity checks.

Let Π be the canonical policy bundle containing S, A, f, complete F and Path(F), L, R, c\_candidate, c\_eligible, B\_min, B\_max, Φ and its grammar version, the κ score-domain version, Ψ, the route registry, standard-task registry, artifact-schema registry, hypothesis-alignment policy, hypothesis-exception policy, triage policy, approval\_timestamp\_policy, lifecycle-authorization policy, lifecycle-head/freshness policy, trust-history root, and commit-store policy. Define `canonical(x) := canonical_json(x)` over admitted JSON values and `σ = H(canonical_json(Π))`. σ is only the content-addressed identifier; it has no addressable policy fields. `ResolvePolicyBundle(σ)` is a partial lookup returning Π\_σ, and every Compiler or Executor use requires `H(canonical_json(Π_σ)) = σ`; resolution or hash failure is rejected.

### Definition A.1.1 (Hypothesis Set and Alignment Record)

`H_set = (set_id, version, hypotheses, ratification, content_hash)` is finite, versioned, content-addressed, and human-ratified. Every hypothesis has a stable identifier and typed statement. `ratification` binds the authorized human decision, trusted time, and applicable trust manifest. `content_hash = H(canonical(H_set without content_hash))`.

For Intent I, `Align(I, H_set, Π_σ.hypothesis_alignment_policy)` produces `alignment_record = {intent_ref, hypothesis_set_ref, matched_hypothesis_ids, alignment_score, alignment_threshold, evaluator_pins, decision, exception_ref}`. `decision ∈ {ALIGNED, LOW_MATCH, EXCEPTION_APPROVED}`. `EXCEPTION_APPROVED` requires a human-signed exception bound to the exact Intent hash, active `H_set` hash, authorized scope, and expiry under `Π_σ.hypothesis_exception_policy`. Plan rejects `LOW_MATCH`, a missing record, an agent-authored amendment or exception, evaluator-pin mismatch, stale `H_set`, or any hash/signature failure.

### Definition A.2 (Φ Grammar — full)

```text
segment     ::= attr_name | attr_name "[*]"
field_path  ::= "source" "." "outputs" "." segment ("." segment)*
constant    ::= string_literal | integer_literal | decimal_literal | boolean_literal | enum_literal
typed_atom  ::= field_path op constant
count_agg   ::= "count" "(" field_path op constant ")" op nat
                -- bounded aggregation over single typed array field;
                -- typing judgments require List[T] and yield Nat
φ           ::= typed_atom
              | count_agg
              | "(" φ ")"
              | φ ∧ φ
              | φ ∨ φ
              | ¬φ

op          ::= ≥ | ≤ | = | > | <
```

#### Typing rules

- Γ ⊢ field\_path : T iff field\_path resolves to a declared scalar output field of type T in the immediate source node’s schema
- Γ ⊢ constant : T iff the concrete literal is admitted by T
- Γ ⊢ field\_path op constant : Bool iff Γ ⊢ field\_path : T, Γ ⊢ constant : T, and op is defined on T
- Γ ⊢ projected\_path : List\[T\] iff the path contains one collection projection, resolves to a list of T values in the immediate source schema, and the projected collection has finite `L(...).max_collection_length`
- If Γ ⊢ projected\_path : List\[T\], Γ ⊢ constant : T, and op₁ is defined on T, then Γ ⊢ `projected_path op₁ constant` : List\[Bool\]
- If Γ ⊢ filter : List\[Bool\], then Γ ⊢ `count(filter)` : Nat; if Γ ⊢ n : Nat and op₂ is defined on Nat, then Γ ⊢ `count(filter) op₂ n` : Bool
- Γ ⊢ (φ) : Bool iff Γ ⊢ φ : Bool
- Γ ⊢ φ₁ ∧ φ₂ : Bool iff Γ ⊢ φ₁ : Bool and Γ ⊢ φ₂ : Bool (similarly for ∨ and ¬)

**Precedence (highest to lowest):** ¬, ∧, ∨. Parentheses override.

**Scope restriction (Option A):** field\_path references only the *immediate source node* of the edge. Transitive predecessors are not addressable. Aggregation across multiple upstream nodes must be lifted into the source node’s output computation.

**Decidability:** Every expression in Φ is total, pure, side-effect-free, and decidable in time linear in the expression size plus the field-evaluation cost.

### Definition A.3 (Candidate Graph)

G\_candidate = (V\_c, V\_root\_c, E\_exec\_c, E\_audit\_c, λ\_V, λ\_E, ν, ρ, κ), where V\_c uses identifiers derived from the finite canonical slot set U of §4.2, V\_root\_c ⊆ V\_c is the explicit candidate root set, ν is the canonical planner-provided partial field record map, κ: E\_exec\_c → Score\_bp is total under `Π_σ.score_domain_version = "basis-points-v1"`, E\_exec\_c carries edges labeled `{activates, requires, derives_from}` (scheduler-visible), and E\_audit\_c carries edges labeled `{evidence_for}` (audit-only). G\_candidate is schema-legal if it satisfies P-CADM steps 1–8 and the compile-time clause of step 9 (excluding HITL/triage proofs which apply to G\_approved → C).

### Definition A.4 (Triage Record)

`role_config` maps Advocate, Skeptic, and Judge to `{model_pin_ref, prompt_pin_ref, signer_key_id}`, with every pin reference resolving to an immutable μ entry. Let `triage_policy_hash = H(canonical_json(Π_σ.triage_policy))` and `triage_context_hash = H(canonical({g_candidate_hash, safe_ranges, role_config, triage_policy_hash}))`; the lowercase canonical key names are normative. Advocate and Skeptic each sign `H(canonical({role, report_hash, triage_context_hash}))` for their own role and canonical report. β\_payload = (verdict, concerns, judge\_rationale, advocate\_report\_hash, skeptic\_report\_hash, advocate\_statement\_hash, skeptic\_statement\_hash, triage\_context\_hash, g\_candidate\_hash, safe\_ranges, role\_config, timestamp). The Judge signs H(canonical(β\_payload)). β contains β\_payload, both reports, and all three role attestations. Verification recomputes both report hashes, triage\_context\_hash, and role-tagged statement hashes; requires each attestation signer to equal the corresponding role\_config signer\_key\_id; requires each key to be authorized for that role; and validates diversity under `Π_σ.triage_policy`.

### Definition A.5 (Human Approval Record)

C\_payload = canonical\_json({intent\_ref, hypothesis\_set\_ref, alignment\_record, route\_id, task\_refs, effect\_scope, V, V\_root, E\_exec, E\_audit, λ\_V, λ\_E, ν, ρ, κ, β, σ, μ, χ, supersedes\_id, extensions\_hash}); h\_pre = H(C\_payload); α\_payload = {h\_pre, signer\_key\_id, trust\_manifest\_hash}; user\_signature = Sign\_user(H(canonical\_json(α\_payload))); timestamp\_subject = H(concat(canonical\_json(α\_payload), canonical\_signature(user\_signature))); timestamp\_statement = {timestamp\_authority\_id, timestamp\_subject, trusted\_signed\_at}; timestamp\_signature = Sign\_timestamp\_authority(H(canonical\_json(timestamp\_statement))); timestamp\_proof = {statement: timestamp\_statement, signature: timestamp\_signature}; α = {payload: α\_payload, signature: user\_signature, timestamp\_proof}. α\_payload and timestamp\_statement remain structured objects in storage; cryptographic operations use their canonical byte encodings. Verification first resolves and hash-verifies Π\_σ, then requires α.payload.h\_pre = H(C\_payload), α.signature validity over H(canonical\_json(α.payload)), exact timestamp\_subject recomputation from canonical\_json(α.payload) and canonical\_signature(α.signature), timestamp-statement signature and authority validity over H(canonical\_json(α.timestamp\_proof.statement)) under `Π_σ.approval_timestamp_policy`, trust\_manifest\_hash resolution under `Π_σ.trust_history_root`, and signer authorization at α.timestamp\_proof.statement.trusted\_signed\_at. h\_pre excludes α and γ.

### Definition A.6 (Compiler Attestation)

γ = Sign\_compiler(H(concat(C\_payload, canonical\_signature\_envelope(α)))). The Compiler signing key resides in a trust anchor separate from human keys.

### Definition A.7 (Governed Graph Commit — minimal and implementation)

```text
C_min  = (intent_ref, hypothesis_set_ref, alignment_record, route_id, task_refs,
          effect_scope, V, V_root, E, λ_V, λ_E, ρ, α, σ, μ)
C_plus = (intent_ref, hypothesis_set_ref, alignment_record, route_id, task_refs,
          effect_scope, V, V_root, E_exec, E_audit, λ_V, λ_E, ν, ρ, κ,
          β, α, γ, σ, μ, χ, supersedes_id, extensions_hash,
          implementation_extension_map)

C_payload = canonical_json({intent_ref, hypothesis_set_ref, alignment_record,
             route_id, task_refs, effect_scope, V, V_root, E_exec, E_audit,
             λ_V, λ_E, ν, ρ, κ, β, σ, μ, χ, supersedes_id, extensions_hash})
id(C) = H(concat(C_payload, canonical_signature_envelope(α),
                 canonical_signature_envelope(γ)))
transit(C) = (id(C), C_payload, α, γ, implementation_extension_map)
```

`supersedes_id` is JSON null or, when non-null, resolves to an already-stored predecessor C whose identity, α, and γ validate under C.σ; `Π_{C.σ} = ResolvePolicyBundle(C.σ)` must satisfy `H(canonical_json(Π_{C.σ})) = C.σ`, and the predecessor’s authenticated latest head plus `Π_{C.σ}.lifecycle_authorization_policy` must permit supersession. The successor’s policy cannot retroactively authorize that transition. `implementation_extension_map` is a finite canonical JSON object or null and is carried in transit(C); `extensions_hash = H(canonical(implementation_extension_map))` when the map is present and JSON null otherwise. The Executor rejects a missing map for a non-null hash, a non-null map for a null hash, or any hash mismatch. The extension map is identity-bound through extensions\_hash in C\_payload; no future lifecycle record hash is committed inside C. Authoritative lifecycle registry identity and registry-key policy are bound through `Π_σ.lifecycle_head_policy`. Successful put-once storage is followed by the mandatory authenticated `null → COMPILED` transition/head defined in §3.12.

### Definition A.8 (Graph-Closed Executor)

An executor X is graph-closed with respect to C if: (i) X accepts only `transit(C) = (id(C), C_payload, α, γ, implementation_extension_map)` whose identity verifies as `H(concat(C_payload, canonical_signature_envelope(α), canonical_signature_envelope(γ))) == id(C)`, whose carried extension map verifies against extensions\_hash, and whose bytes equal `get(id(C))` from the put-once store governed by `Π_σ.commit_store_policy`; (ii) X resolves `Π_σ = ResolvePolicyBundle(σ)` and verifies `H(canonical_json(Π_σ)) = σ`; (iii) X verifies the exact Intent, active `H_set`, admitted alignment/exception record, registered route and tasks, artifact schemas, and finite effect scope bound into C; (iv) X verifies γ over `H(concat(C_payload, canonical_signature_envelope(α)))` against the effective Compiler trust set and verifies α’s human signature over `H(canonical_json(α.payload))`, exact timestamp\_subject from `canonical_json(α.payload)` plus `canonical_signature(α.signature)`, timestamp-statement signature and authority over `H(canonical_json(α.timestamp_proof.statement))` under `Π_σ.approval_timestamp_policy`, signer authorization at α.timestamp\_proof.statement.trusted\_signed\_at under the exact trust manifest, and `Π_σ.trust_history_root`; (v) X verifies the latest authenticated lifecycle head for the exact registry authorized by `Π_σ.lifecycle_head_policy`, or an explicitly pinned offline checkpoint under that policy; (vi) X constructs scheduling state from E\_exec while preserving `top(C) = (V, V_root, E_exec, E_audit, λ_V, λ_E, ρ)`; (vii) X exposes no topology-mutation API; (viii) all tool calls reference node IDs ∈ V and all material effects remain inside effect\_scope; and (ix) X has no access to Planner or Compiler credentials.

### Definition A.9 (Commit-Bound Activation Context K and Modes)

For each activation edge e = (u, v), K(e) ∈ {`VALUE(source_ref_e, x_e)`, `SOURCE_INELIGIBLE`}. source\_ref\_e binds `{origin_kind, origin_id, source_node_id, source_output_hash, source_admission_event_hash, projection_paths, projection_hash}` and MUST satisfy `source_node_id = u`; `projection_paths = canonical_order(refs(ρ(e)))`, x\_e is the exact typed projection of the admitted source output at those paths, and `projection_hash = H(canonical({projection_paths, values: x_e}))`. K is total when every activation edge has exactly one entry and consistency-valid when `SOURCE_INELIGIBLE` occurs iff u is ineligible and VALUE occurs only when u is eligible and every source/projection hash verifies. Mode A admits exactly one PRECOMMITTED source record per activation-source node u, and all outgoing VALUE decisions for u carry that record’s same origin\_id, source\_output\_hash, and source\_admission\_event\_hash; if u is recomputed or executed, its admitted output hash must match that sole precommitted source\_output\_hash or the run terminates as `ACTIVATION_INTEGRITY_MISMATCH` without a G\_eligible/P-ERE conclusion. Mode B/C applies the same single-origin tuple invariant to all outgoing VALUE decisions from one source execution attempt. χ = (activation\_mode, K\_commitment, replay\_policy\_hash) is bound into C\_payload. Mode A requires a non-null commitment to total, consistency-valid K including those PRECOMMITTED source-admission records. Mode B (default) requires a replay policy that writes the tagged RUNTIME\_OUTPUT decisions to a content-addressed K\_log and binds its hash in the trace. Mode C has no K commitment and denies any replay claim. ρ itself is already bound in top(C) and C\_payload. See §3.7.

### Definition A.10 (Runtime Graph Sets and Statuses)

- **V\_root ⊆ V** is the explicit commit-bound root set. Every v ∈ V\_root has E\_exec indegree zero, and Ψ validates permitted root types and cardinality; nodes outside V\_root with E\_exec indegree zero are rejected. In-degree here and throughout Ψ is counted over E\_exec only; an incoming `evidence_for` edge does not raise a node’s in-degree and does not exempt it from this rule.
- **G\_eligible(r)** is defined only for total, consistency-valid K\_r. Its least vertex set V\_eligible contains V\_root and admits a non-root node v iff every incoming `requires` or `derives_from` predecessor is eligible and every incoming activation edge e = (u, v) has K\_r(e) = `VALUE(source_ref_e, x_e)` with u eligible, valid admitted-source provenance, an exact committed-ρ projection, and eval(ρ(e), x\_e) = true. `SOURCE_INELIGIBLE` makes its edge false without evaluating ρ. E\_eligible contains exactly those e = (u, v) ∈ E\_exec whose endpoints are eligible and satisfy `λ_E(e) ∈ {requires, derives_from} ∨ (λ_E(e) = activates ∧ K_r(e) = VALUE(source_ref_e, x_e) ∧ eval(ρ(e), x_e) = true)`. G\_eligible includes V\_eligible, E\_eligible, and the restricted λ\_V, λ\_E, and ρ mappings; E\_audit is excluded. It is a deterministic function of (C, K\_r).
- **K\_{r,t}** is the append-only partial Mode B decision context at time t. Roots and nodes with no unresolved incoming activation predicates may be considered before K\_r is total; an ineligible node appends `SOURCE_INELIGIBLE` for each outgoing activation edge, while an eligible source whose authoritative admitted output establishes terminal COMPLETED designates `successful_attempt_r(u)` and appends the corresponding source-bound VALUE decisions before its targets are considered.
- **V\_ready(r, t)** contains v when every incoming requires/derives\_from predecessor has status\_r,t = COMPLETED and every incoming activation decision is a valid source-bound VALUE whose predicate evaluates true. Any `SOURCE_INELIGIBLE` or false predicate resolves v as skipped. These monotone readiness decisions satisfy `V_ready(r,t) ⊆ V_eligible(r)` once K\_r is total.
- **V\_executed(r)** = {v ∈ V\_eligible(r) | status\_r(v) = COMPLETED}. For every `v ∈ V_executed(r)`, `successful_attempt_r(v)` is the unique execution attempt whose authoritative `OUTPUT_ADMITTED` event established terminal COMPLETED status. Retries before that success are legal and non-authoritative; no later attempt may establish a second successful completion for the same `(id(C), run_id, node_id)`. **G\_executed(r)** is the subgraph of G\_eligible(r) induced by V\_executed(r). It depends on runtime reliability and is not claimed to be a deterministic function of (C, K\_r).
- **BLOCKED** is the status of a node that cannot become ready because a mandatory predecessor failed. **ACTIVATION\_CONTEXT\_INCOMPLETE** is the terminal run condition in which an eligible activation source fails, is blocked, or omits a ρ-referenced value; affected targets are not released, final G\_eligible is undefined for that run, and P-ERE does not apply. An ineligible source instead yields `SOURCE_INELIGIBLE` and does not trigger this condition.

### Definition A.11 (OutcomeBundle)

For GGC C and run r with trace `τ_r`, `O_r = {outcome_bundle_id, ggc_id, run_id, intent_ref, hypothesis_set_ref, alignment_record_hash, route_id, task_refs, effect_scope_hash, trace_ref, activation_log_ref, node_outcomes, artifact_refs, evidence_refs, lifecycle_head_ref, finalized_at}` where `outcome_bundle_id = H(canonical(O_r without outcome_bundle_id))`. Every completed-node entry binds the authoritative execution-attempt and terminal event; every artifact reference binds its type, schema, governed target, content hash, producer node, and `OUTPUT_ADMITTED` event hash. O\_r is evidence only. It cannot authorize Plan or Execute, amend `H_set`, widen effect scope, or substitute for a fresh Intent and alignment record.

* * *

## Appendix B: NBM4 Artifact Schema — Cardinality and L Tables

Appendix B provides selected readable projections from the two NBM4 profiles used in §5. These illustrative defaults do not substitute for the complete content-addressed machine-readable Σ bundle required for a full conformance claim.

### B.1 Stage Assignments

| Stage ID | Stage name | Artifact IDs |
| --- | --- | --- |
| s₁ | Idea | A01 ProductVision; A02 RiskiestHypotheses; A03 MarketHypothesis; A04 LeanCanvas |
| s₂ | Customer | A05 TargetSegment5W; A06 CompetitorSnapshot; A07 InterviewGuide; A08 PersonaProfile; A09 EmpathyMap; A10 CustomerInterviewNotes; A11 PainAnalysis; A12 PainEvidenceBundle; A13 JTBDAsIs; A14 UserJobStoriesAsIs; A15 SegmentPriority; A16 Pain |
| s₃ | Value Suggestion | A17 PainPriority; A18 ProductFeatureUJS; A19 FeaturePriorities; A21 ValueMap; A22 ValuePropositionCanvas |
| s₄ | Value Test | A20 PrototypeTestPlan |
| s₅ | Product | Production-ready specification and roadmap artifacts produced through registered typed Product routes |
| s₆ | Go to Market | A23 ChannelCanvas; A24 GTMLaunchPlan |

### B.2 Candidate Relationship Cardinality Table

Relationship minima apply to present endpoint instances and do not create artifact instances; B\_min controls type-level mandatory presence.

| # | Source (stage) | Target (stage) | Semantic | min_out | max_out | min_in | max_in | Activation condition |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R01 | ProductVision (1) | LeanCanvas (1) | requires | 0 | 1 | 0 | 1 | — |
| R02 | ProductVision (1) | RiskiestHypotheses (1) | requires | 1 | 1 | 1 | 1 | — |
| R03 | LeanCanvas (1) | RiskiestHypotheses (1) | evidence_for | 0 | 1 | 0 | 1 | — |
| R04 | TargetSegment5W (2) | PersonaProfile (2) | requires | 1 | 5 | 1 | 3 | — |
| R05 | PersonaProfile (2) | EmpathyMap (2) | requires | 0 | 1 | 0 | 1 | — |
| R06 | PersonaProfile (2) | JTBDAsIs (2) | derives_from | 1 | 5 | 1 | 3 | — |
| R07 | PersonaProfile (2) | UserJobStoriesAsIs (2) | derives_from | 1 | 10 | 1 | 5 | — |
| R08 | PersonaProfile (2) | Pain (2) | derives_from | 1 | 10 | 1 | 5 | — |
| R09 | JTBDAsIs (2) | UserJobStoriesAsIs (2) | requires | 1 | 5 | 1 | 3 | — |
| R10 | Pain (2) | PainPriority (3) | derives_from | 1 | 1 | 1 | 1 | — |
| R11 | PainPriority (3) | ProductFeatureUJS (3) | activates | 0 | 12 | 1 | 1 | source.outputs.priorityScore ≥ 15 |
| R12 | ProductFeatureUJS (3) | FeaturePriorities (3) | requires | 0 | 1 | 0 | 12 | — |
| R13 | ProductFeatureUJS (3) | ValueMap (3) | derives_from | 1 | 1 | 1 | 12 | — |
| R14 | ValueMap (3) | ValuePropositionCanvas (3) | requires | 0 | 1 | 0 | 1 | — |
| R15 | ValuePropositionCanvas (3) | ChannelCanvas (6) | requires | 0 | 1 | 0 | 1 | — |

### B.3 Eligible Cardinality Overrides

For scheduler-visible relationships without an override, c\_eligible(R\_exec) = c\_candidate(R\_exec). After total K defines E\_eligible, the Executor validates these per-endpoint runtime postconditions. The activation relationship uses the following override so ordinary predicate skipping is not treated as a cardinality violation:

| # | c_candidate | c_eligible | Rationale |
| --- | --- | --- | --- |
| R11 | (0, 12, 1, 1) | (0, 12, 0, 1) | Zero feature edges may be eligible when no PainPriority reaches the threshold |

### B.4 Profile-Specific B\_min and Shared B\_max

The profiles share B\_max. Their mandatory alternative roots differ; all other B\_min values in this readable projection are zero, with conditional downstream presence governed by relationship minima and Ψ.

| ID | Artifact type | B_min full | B_min customer-value | B_max |
| --- | --- | --- | --- | --- |
| A01 | ProductVision | 1 | 0 | 1 |
| A02 | RiskiestHypotheses | 0 | 0 | 1 |
| A03 | MarketHypothesis | 0 | 0 | 1 |
| A04 | LeanCanvas | 0 | 0 | 1 |
| A05 | TargetSegment5W | 0 | 1 | 5 |
| A06 | CompetitorSnapshot | 0 | 0 | 10 |
| A07 | InterviewGuide | 0 | 0 | 5 |
| A08 | PersonaProfile | 0 | 0 | 3 |
| A09 | EmpathyMap | 0 | 0 | 3 |
| A10 | CustomerInterviewNotes | 0 | 0 | 50 |
| A11 | PainAnalysis | 0 | 0 | 30 |
| A12 | PainEvidenceBundle | 0 | 0 | 30 |
| A13 | JTBDAsIs | 0 | 0 | 15 |
| A14 | UserJobStoriesAsIs | 0 | 0 | 30 |
| A15 | SegmentPriority | 0 | 0 | 5 |
| A16 | Pain | 0 | 0 | 30 |
| A17 | PainPriority | 0 | 0 | 30 |
| A18 | ProductFeatureUJS | 0 | 0 | 12 |
| A19 | FeaturePriorities | 0 | 0 | 1 |
| A20 | PrototypeTestPlan | 0 | 0 | 1 |
| A21 | ValueMap | 0 | 0 | 12 |
| A22 | ValuePropositionCanvas | 0 | 0 | 1 |
| A23 | ChannelCanvas | 0 | 0 | 6 |
| A24 | GTMLaunchPlan | 0 | 0 | 1 |

### B.5 Selected Readable Projection of F and L

| Artifact | Path | max_collection_length | max_string_length | closed_enum |
| --- | --- | --- | --- | --- |
| ProductVision | statement | — | 1000 | — |
| RiskiestHypotheses | hypotheses | 5 | — | — |
| RiskiestHypotheses | hypotheses[*].claim_text | — | 500 | — |
| PersonaProfile | description | — | 2000 | — |
| PersonaProfile | top_pain_summaries | 5 | — | — |
| PainAnalysis | observations | 10 | — | — |
| PainAnalysis | observations[*].evidence_text | — | 500 | — |
| PainPriority | rationale | — | 500 | — |
| PainPriority | priorityScore | — | — | — (integer field, no L) |
| ProductFeatureUJS | user_job_story | — | 1000 | — |
| ProductFeatureUJS | acceptance_criteria | 8 | — | — |
| ProductFeatureUJS | acceptance_criteria[*].text | — | 300 | — |
| ValueMap | value_propositions | 5 | — | — |
| ChannelCanvas | channels | 6 | — | — |

A conforming `Σ_NBM4-full` or `Σ_NBM4-customer-value` MUST bind a complete finite F/L table covering every variable-length typed path. This selected projection alone does not establish complete DODGE-NBM4 content-scope conformance. Full conformance requires a cited, content-addressed, machine-readable bundle included in Π\_σ with `H(canonical_json(Π_σ)) = σ`; this manuscript version does not cite such a bundle.

### B.6 Activation Predicate Reference

R11 uses the typed scalar predicate `source.outputs.priorityScore ≥ 15`. The source is one PainPriority item node, so no array projection or derived aggregate is required and each candidate feature edge can activate independently.

PMs may override the threshold within the declared safe-range (e.g., \[13, 17\] for priorityScore) without triggering re-triage; structural changes to the predicate (new conjuncts, new field paths) are material and require re-triage per §3.9.

* * *

## Appendix C: DODGE-RFC — A Second Domain Instantiation (Sketch, with Operational-Status Note)

This appendix demonstrates DODGE’s domain-agnosticism by sketching a second instantiation over RFC governance for AI orchestration systems. The substrate is the author’s own ship-mlp infrastructure.

### C.1 Stage Set

| Stage ID | Name | Epistemic purpose |
| --- | --- | --- |
| t₁ | Draft | Initial RFC proposal; problem statement and open questions |
| t₂ | Review | Adversarial review; open questions resolved or escalated |
| t₃ | Trial | Limited-scope pilot; evidence accumulation |
| t₄ | Adopted | Ratified as standard; integrated into governance corpus |
| t₅ | Deprecated | Superseded by newer RFC; retained for institutional memory |

### C.2 Artifact Type Universe (sample)

| ID | Artifact Type | Stage | B_min | B_max |
| --- | --- | --- | --- | --- |
| AT01 | RFC | t₁ | 1 | 1 |
| AT02 | ProblemStatement | t₁ | 1 | 1 |
| AT03 | OpenQuestion | t₁ | 0 | 10 |
| AT04 | ReviewVerdict | t₂ | 1 | 5 |
| AT05 | ADR (decision-record) | t₂ | 1 | 5 |
| AT06 | PilotPlan | t₃ | 1 | 1 |
| AT07 | EvidenceBundle | t₃ | 1 | 10 |
| AT08 | RatificationDecision | t₄ | 1 | 1 |
| AT09 | SupersessionLink | t₅ | 0 | 3 |

### C.3 Sample Relationships and Cardinalities

| Source | Target | Semantic | c_candidate | c_eligible | Activation condition |
| --- | --- | --- | --- | --- | --- |
| RFC | ProblemStatement | derives_from | (1, 1, 1, 1) | (1, 1, 1, 1) | — |
| RFC | OpenQuestion | derives_from | (0, 10, 1, 1) | (0, 10, 1, 1) | — |
| RFC | ReviewVerdict | requires | (1, 5, 1, 1) | (1, 5, 1, 1) | — |
| OpenQuestion | ADR | activates | (0, 3, 1, 1) | (0, 3, 0, 1) | source.outputs.severity = "high" |
| ADR | PilotPlan | requires | (1, 1, 1, 5) | (1, 1, 1, 5) | — |
| PilotPlan | EvidenceBundle | derives_from | (1, 10, 1, 1) | (1, 10, 1, 1) | — |
| EvidenceBundle | RatificationDecision | activates | (0, 1, 0, 1) | (0, 1, 0, 1) | count(source.outputs.assessments[*].classification = "confirms") ≥ 3 |
| RatificationDecision | SupersessionLink | requires | (0, 3, 0, 3) | (0, 3, 0, 3) | — |

The RFC-domain L table sets `L(EvidenceBundle, assessments).max_collection_length = 10`, making the count aggregation finite.

The DODGE-RFC commit binds its sole RFC node in V\_root. Ψ\_RFC authorizes exactly one RFC root, rejects any other schedulable node with E\_exec indegree zero, and requires every ProblemStatement, OpenQuestion, ReviewVerdict, ADR, PilotPlan, EvidenceBundle, RatificationDecision, and SupersessionLink node to be reachable from V\_root through E\_exec; evidence\_for edges, if present, do not establish schedulability.

### C.4 Triage Roles in RFC Domain

Tier 4 roles are model-instantiated panel agents, not the humans whose positions they carry. This follows from §3.8: `β_payload` carries a role\_config with one Advocate, Skeptic, and Judge entry, each containing `model_pin_ref`, `prompt_pin_ref`, and `signer_key_id`, and every pin reference MUST resolve to an immutable entry in μ. A human principal cannot occupy a Tier 4 seat, because the panel’s model-family and prompt-family diversity requirement is defined over exactly those pins. The human parties named below supply input to the panel; they are not members of it.

- **Advocate** — a panel agent prompted to argue the strongest case for the submitted RFC as written: its scoring logic, threshold choices, cardinality decisions, and proposed topology. Its brief is sourced from the RFC author’s stated rationale, which enters as `triage_packet` input. The RFC author does not sit on the panel.
- **Skeptic** — a panel agent prompted to challenge the RFC: contest the problem statement, surface unaddressed open questions, question cardinality choices, and propose alternative architectures. Where a human counter-proposal reviewer or alternative-architecture proposer exists, their objections are supplied to the panel as `triage_packet` input rather than as a panel seat.
- **Judge** — a panel agent that produces the confidence verdict over G\_candidate (Adopt | Trial | Watch | Reject) and signs the canonical β\_payload containing the role-bound Advocate and Skeptic attestations, the verdict, and the reviewed safe ranges.

**Tier 4 and Tier 5 are held by different principals.** This is a consequence of the existing role types rather than an additional rule. Every Tier 4 role resolves to a model pin in μ (§3.8), whereas α is by definition a human approval record binding an approver identity (G-18). No human therefore occupies a Tier 4 seat, and the Tier 5 approver is necessarily disjoint from the panel that produced β. In the DODGE-RFC sketch the governance committee chair signs α at Tier 5 (C.5) and holds no Tier 4 role: the chair reviews the panel’s verdict and attached concerns as an input to ratification, and does not produce that verdict. Reading the chair as also serving as Judge would collapse Tier 4 into Tier 5 and let the ratifying human review their own panel verdict, defeating the independence §3.9 depends on.

The diversity requirement holds: at least two distinct model families and at least two distinct prompt families across the three role pins. The hypothetical illustration uses Anthropic-family (Advocate), OpenAI-family (Skeptic), and Google-family (Judge) models; a real evidence claim would identify exact immutable model and prompt pins through μ.

### C.5 GGC in RFC Domain

A DODGE-RFC GGC would ratify a specific RFC topology — proposed RFC + problem statement + review verdicts + open questions + ADRs + pilot plan — bound by HITL signature from the governance committee chair. In a conforming target instantiation, the Executor would be a GGC-only ratification pipeline that executes the trial pilot phase and produces an EvidenceBundle stream. ship-mlp is the candidate substrate for that target; Appendix C.6 and §7.7 do not establish that the current repository realizes this v9.3 Executor contract end to end.

**Comparison to NBM4 instantiation.** Different stage set (5 stages vs 6), different artifact types (RFCs and ADRs vs Personas and Features), different cardinalities (10 OpenQuestions per RFC vs a global bound of 12 ProductFeatureUJS nodes per NBM4 commit). Both use a human-ratified `H_set`, the same pre-Plan alignment and IPCE lifecycle, the same five graph-governance tiers, the same GGC structure C\_plus, typed registered routes, and non-authorizing OutcomeBundles.

**What this demonstrates.** DODGE-RFC uses the framework without modifying its schema-level definitions. P-BLTS, P-CADM, P-EDGE, and T4a/T4b apply when this finite Σ\_RFC satisfies their stated assumptions; P-CTI, P-ERE, P-OUT, P-AUD, and P-IMM additionally require the declared Executor, activation-context, commit-store, lifecycle-registry, audit-channel, and cryptographic assumptions. Domain-agnosticism is demonstrated by parameterization rather than by claiming assumption-free invariants. The framework is the pattern; Σ-instantiations are reference implementations.

### C.6 Author-Reported Operational Status of the DODGE-RFC Pattern in ship-mlp

The author reports that the private ship-mlp substrate runs recognizable instances of the five-tier graph validation pipeline over its own RFC corpus and evolution, including the conformance program described in §7.7. The underlying artifacts are not independently accessible with this manuscript. The reported mechanisms are:

- **Adversarial triage (Tier 4):** RFC candidates are triaged by independent multi-model Advocate/Skeptic/Judge panels (distinct model families and prompt families, no self-play), with scored verdicts, binding conditions, and loop-until-pass semantics; the RFC that authorized the §7.7 evidence work passed at a 9.5-threshold panel over multiple rounds.
- **HITL as a hard gate (Tier 5):** intent gates and plan gates fail-closed on every governed action; multiple human-in-the-loop stops during the conformance sprint were resolved by explicit human decisions recorded as evidence, including the scoped-deferral decision that the v7.1 ledger later records as closed by RFC-0240 WI-30R.
- **Typed evidence and claim governance:** stage decisions, gate decisions, and conformance status are typed, ledgered records; release-claim wording is gated mechanically (§7.7.3).
- **Governed routes:** multi-node route compilation with per-node effect authorization exists for RFC triage and code-review route families at the check-API layer.
- **Live stage-decision evidence (v9.3 addition):** as of 2026-07-16 the substrate’s dispatcher ledgers record on the order of 1,800 typed stage decisions (G-65) across route, planner, compiler, and executor stages for live voyages, and the live governed-run workflow consumes `compile.check` → `GovernedGraphCommit` → `execute.check` on that path; the standard-route registry carries seven registered routes and twenty-two standard tasks across RFC-triage, RFC-maintenance, code-review, and governance-maintenance families; Compiler rejections on this path follow the bounded planner rejection loop (§3.15).

**What C.6 does not claim.** This is an author-reported operational-status note, not independently accessible evidence or a full DODGE-RFC conformance claim. The private v7.1 ledger is reported as recording live-path substrate unification as closed under RFC-0240 WI-30R, but RFC-domain artifacts are not shown here to satisfy the revised v9.3 tuple and test mapping end to end, and no P-ERE replay claim is made for the RFC domain. Promotion of this appendix from sketch-with-operational-notes to a worked instantiation remains Priority 3 future work (§8.3).

A worked DODGE-RFC instantiation with empirical observations from running it against the ship-mlp RFC corpus is identified as Priority 3 future work (§8.3).

* * *

## Appendix D: Author-Reported Reference Implementation Substrate

**ship-mlp.** The author reports *ship-mlp* as DODGE’s primary reference substrate, combining current Intent/Plan/Compile/Execute vocabulary, registered routes and standard tasks, compiler-bound authorized paths, a graph-closed execute check, Claim-Check storage, isolated workers, and independent audit collection. These private implementation artifacts are not independently accessible with this manuscript. *ship-mlp Architecture Blueprint v0.7.1* (Kozloff, 2026) is a private DRAFT historical baseline; RFC-0240 subsequently superseded parts of that baseline for the live path and signature-envelope/key-custody mechanisms. The current v9.3 `H_set`, alignment, typed-route, and OutcomeBundle contracts remain design targets rather than independently established implementation claims.

### D.1 Vocabulary Cross-Reference

**Namespace note.** The `L1`/`L2` labels in this appendix are literal ship-mlp repository identifiers for that substrate’s own schema and law tiers (`schema/L1`, `schema/L2`), retained here because they are the actual artifact names, exactly as literal lowercase `dogdd` identifiers are retained in §7.2. They are **not** this paper’s epistemic layers L1–L4 (G-43–G-47), and no row below should be read through those glossary entries: “L1/L2 Laws” does not mean code-conformance and implementation-specification claims. The single occurrence of `SLSA L2` further below belongs to a third namespace again — the OpenSSF SLSA assurance levels — and is likewise unrelated to both.

DODGE’s framework-level terms map conceptually to the private Blueprint and later author-reported implementation status as follows. Rows marked `exact` identify claimed direct equivalence within that private lineage; rows marked as targets or projections require the v9.3 alignment work scoped in §7.7.4.

| DODGE framework term | ship-mlp Blueprint v0.7.1 / later status | Notes |
| --- | --- | --- |
| Σ (domain-method schema) | NBM4-DDT + L1/L2 Laws + CONSTITUTION.json + LawCompiler output | Σ is what the LawCompiler compiles into a CompiledLawSnapshot |
| T_legal(Σ) | space of typed TaskGraph shape projections admissible under the active PolicySet | conceptual P-BLTS mapping |
| G_proposed | Template Planner output (alpha); LLM Planner output (post-alpha) | raw planner output before Compiler.static |
| G_candidate | TaskGraph after Compiler.static admission | successful whole-proposal admission, pre-triage; v9.3 does not define silent filtering |
| G_approved | TaskGraph + VoyageAuthorization + CompiledExecutionAuthorization, post-Compiler.full | human-ratified and Compiler-attested |
| C_min (exposition tuple) | minimal VoyageCommit projection | used to introduce the commit shape in §3.10; §4’s properties are stated over the graph-shape projection or C_plus, not over C_min |
| C_plus (implementation model) | VoyageCommit target framework projection | conceptual v9.3 mapping; v7.1 lacks several first-class v9.3 fields and contracts listed in §7.7.4 |
| h_pre (non-circular pre-commit hash) | H(C_payload), where C_payload is JCS-canonical commit payload with α and γ excluded | blueprint A2; §3.10 |
| id(C) over C_payload, α, and γ | VoyageCommit.commit_id over JCS canonicalization | exact for the v7.1 identity pattern, not the revised payload shape |
| α (human approval envelope) | VoyageAuthorization.signature + LawAcceptanceRecord quorum signatures | Historical Blueprint v0.7.1 target: two-level ES256 over JCS; the author-reported v7.1 implementation under RFC-0240 WI-33 uses Ed25519; direct v9.3 binding of h_pre and trust_manifest_hash in the human-signed payload plus a carried approval-timestamp proof over that exact signature is not established |
| γ (compiler attestation, signs H over C_payload and α) | CompiledExecutionAuthorization.signature (per node) + Compiler-sealed DAG | Historical Blueprint v0.7.1 target uses ES256; the author-reported v7.1 implementation under RFC-0240 WI-33 uses Ed25519 and records trusted-issuer checks |
| σ / Π_σ (policy-bundle identity and resolved bundle) | law_version target projection (JCS hash of CompiledLawSnapshot plus policy/trust references) | v7.1 does not directly bind v9.3 complete F/Path/L, B_min/B_max, hypothesis-alignment/exception policies, route/task/artifact registries, Score_bp version, lifecycle authorization, trust history, store policy, or the fail-closed ResolvePolicyBundle contract |
| μ (addressable immutable pins) | model_artifact_pin in VoyageCommit + WorkOrder | target mapping for model, prompt, tool, and binary pin references; role-to-μ resolution remains v9.3 alignment work |
| χ (activation control) | replay-mode tag + activation-context policy target projection in VoyageCommit/WorkOrder | conceptual v9.3 mapping; v7.1 has replay tags but no first-class χ bound as defined here |
| supersedes_id | successor/predecessor lifecycle references | v9.3 requires a nullable first-class C_payload field; direct v7.1 mapping is not established |
| extensions_hash / implementation_extension_map | Derived JCS projection hash and the corresponding directly bound route-plan, authority, and immutable lifecycle/evidence registry-identity fields | framework mapping abstraction; direct transit carriage and hash verification of the v9.3 map are not established, lifecycle records append only after id(C) exists, and literal schema fields with these names are not required |
| K (activation context) | input_slot_refs (content_refs) + execution_metadata in WorkOrder/WorkReceipt | Mode B in DODGE ↔ Claim-Check pattern in blueprint; admitted-source execution/output identity and exact committed-ρ projection binding remain v9.3 alignment work |
| Mode A (pre-committed K) | activation values inlined into VoyageCommit | dormant in alpha — Template Planner has no activation predicates |
| Mode B (replay-logged K) | encrypted blob store + content_ref + content_hash | realistic default; blueprint A3 Claim-Check |
| Mode C (re-evaluated K) | not used in alpha | post-alpha, if introduced, explicitly forfeits replay claim |
| Executor (graph-closed) | TEN + WorkerAdapter + Temporal over verified VA + CEA | TEN steps 1–11 in blueprint §11 |
| Φ (activation predicate language) | edge activation conditions on TaskGraph | alpha: empty (deterministic Template Planner); post-alpha: ADR-LLM-Planner-1 formalizes against Appendix A grammar |
| F/Path/L content scope | per-artifact field bounds in NBM4-DDT artifact schemas | complete finite nonrecursive path coverage and a cited content-addressed bundle remain unestablished for v9.3 |
| Triage role configuration and attestations | panel_config attested in LawAcceptanceRecord | The author reports v7.1 diversity checks; role-to-μ references and role-tagged report/context attestations bound through triage_context_hash remain v9.3 alignment work |
| Material edit taxonomy (structural / predicate-structure / predicate-value-in-safe-range) | edit-classification table for VA/CEA amendments | Blueprint v0.7.1 carries the B2 design target through its v0.7 lineage |
| Lifecycle attestation and authenticated-head chain | VoyageCommit state-transition chain with signatures | v9.3 effective-dated role policy, trust-history proof, latest authenticated head, and anti-rollback checks remain alignment work |
| Σ-meta-DODGE (§3.13 recursive schema governance) | LAW-CHANGE-SOP.md + LawCompiler + LawAcceptanceRecord pipeline | exact: blueprint’s law-governance pipeline IS Σ-meta-DODGE; CONSTITUTION.json is Σ_meta bootstrap |
| H_set alignment and OutcomeBundle | PM-interview initialization, Intent/Plan checks, route-plan state, governed execution evidence | v9.3 requires human-ratified versioned H_set, fail-closed pre-Plan alignment, human-only amendment/exception authority, exact GGC bindings, and a non-authorizing OutcomeBundle; direct implementation alignment is pending |
| Independent AuditCollector | AuditCollector pulling from Model Gateway / Tool Proxy / Runtime Supervisor (worker has zero knowledge) | blueprint A4; exact |
| DODGE-RFC (sketched Σ_RFC, Appendix C) | ship-mlp’s own RFC governance over .0-mlp/1_idea/9_rfcs/ | recursive self-instantiation — substrate uses DODGE-RFC for its own evolution; operational status in C.6 |

#### D.1.1 Author-Reported Private Check-API Artifacts

The author reports the following private artifact families in the ship-mlp repository. No public archival metadata is cited in this version; these rows identify claimed implementation surfaces rather than independently reproducible evidence:

| Role | Landed artifact family |
| --- | --- |
| GGC schema (C_plus binding) | GovernedGraphCommit L2 evidence schema, version 2, with v7.1 κ/β shapes and per-node ρ flags; those flags are a surrogate, not v9.3 per-edge ρ, and the schema lacks the broader v9.3 field/policy contracts inventoried in §7.7.4 |
| Compiler admission | compile.check API with the full typed reject set (§7.7.2) |
| Executor admission | execute.check API with graph-closure, per-effect authorization, and pre-runtime rejection ordering |
| Compiler skill boundary | CompilerSkillManifest L2 schema with forbidden-capability negative evals; pilot compiler-skill package with failing-evals-first audit trail |
| Replay | K_log build/replay runner with replay-claim mode tags |
| Lifecycle | hash-linked GovernedGraphCommit lifecycle transition chain with evidence-bundle classification and v7.1 attested overrides; those overrides are not v9.3-conforming |
| Triage evidence | β diversity/safe_ranges evidence schema with policy cross-validation; direct Π_σ resolution remains v9.3 alignment work |
| Material edits | material-edit taxonomy classifier with per-class admission predicates |
| Runtime cardinality | v7.1 RuntimeCardinalityCollapse governed evidence record; v9.3 generalizes the contract to lower/upper per-endpoint violations |
| Σ-meta | SigmaMetaRevision governed revision pipeline |
| Conformance suite | v7.1 twenty-row suite with a separate paper-attack map; its TC semantics do not match revised v9.3 §7.5, and the map retains one explicit owned-gap row |
| Claim governance | machine-readable conformance ledger + executable release-claim gate (§7.7.3, §3.16) |
| Prompt-intake gate (v9.3) | PromptIntentGateDecision skill and logger with banded thresholds, second-family score arbitration, transport score ceiling, and fail-closed tool blocking; transport adapters for three agent harnesses (§3.14) |
| Planning gate (v9.3) | post-intake IntentPlanningDecision requirement for write/compile/execute effects; the PLAN_NOT_REQUIRED bypass requires a human-signed approval block |
| Stage-decision evidence (v9.3) | append-only route/planner/compiler/executor DogddStageDecision ledgers populated by live governed voyages (G-65) |
| Planner rejection loop (v9.3) | typed Compiler rejection payload with bounded replans (three) and HITL escalation carrying structured repair guidance (§3.15) |
| Artefact Traceability Graph (v9.3) | derived repository-wide typed graph index with relationship vocabulary and registered query presets (G-68); capability/worker/skill node admission in progress under a triaged RFC |

### D.2 What is Implementation-Bound vs Framework-Invariant

DODGE’s definitions do not require the specific substrate choices in the private Blueprint, but each property still depends on its stated structural, Executor, activation-context, commit-store, lifecycle-registry, audit-channel, and cryptographic assumptions. Alternative substrates satisfying those contracts are admissible. The Blueprint choices are historical DRAFT design targets, not architectural prerequisites of DODGE or an authoritative statement of the later reported implementation.

#### Historical Blueprint design targets that DODGE does not require

- Temporal as the orchestration adapter
- gVisor / Firecracker microVMs as the worker isolation primitive
- RFC 8785 JSON Canonicalization Scheme (JCS) as the canonicalization rule
- Blueprint v0.7.1 specifies ES256 over JCS; the v7.1 implementation status reported under RFC-0240 uses Ed25519
- Cosign + Rekor + SLSA L2 as the supply-chain attestation chain
- S3-class encrypted Object Lock (or equivalent immutable blob store) as the Claim-Check substrate

##### What DODGE requires that any substrate must provide

- Content-addressed canonical serialization that is deterministic, unambiguous, and injective over the admitted value domain; RFC 8785 JCS is one realization
- Two cryptographic key custody domains (one for human signers, one for Compiler attestation; separability is the invariant, not the scheme); the private v7.1 ledger is reported as recording Ed25519 custody closure, while direct v9.3 payload alignment remains unproven (§7.7.4)
- A graph-closed execution surface that preserves the complete top(C) projection and exposes no topology-mutation API
- A put-once commit store that returns byte-identical transit objects and rejects overwrite and deletion; Object Lock is one possible realization
- An audit channel sourced from outside the worker process (pull-model AuditCollector is one realization; signed receipts from a mediator are another)
- An append-only lifecycle registry with effective-dated authorization, trust-history validation, an authenticated latest head, chain verification, and anti-rollback enforcement

### D.3 Status of the Implementation

The author reports repository-local DODGE v7.1 mechanism checks for the Compiler, Executor, replay, lifecycle, and evidence surfaces described in §7.7. The private artifacts are not independently accessible with this manuscript. Literal lowercase `dogdd` names remain in the reported repository paths and test identifiers. This section preserves the distinction between that private implementation status and revised v9.3.

As of 2026-07-06, the private conformance ledger is reported as GREEN and as recording former live-path and key-custody deviations as CLOSED through RFC-0240 WI-30R and WI-33. A third historical projection experiment recorded under WI-34 is outside the current model and is not counted as v9.3 evidence. The author also reports typed fail-closed check APIs, a twenty-row v7.1 suite, an executable release-claim gate, and trace-reconstruction surfaces.

This author-reported status is not a direct v9.3 conformance claim. Missing alignment includes the human-ratified `H_set`, pre-Plan alignment and exception authority, Intent/`H_set`/route/task/artifact-schema/effect-scope GGC bindings, OutcomeBundle, full top(C), commit-time ν, B\_min/B\_max, complete F/Path/L, role-to-μ references and context-bound three-role attestations, supersedes\_id, complete-policy σ/Π\_σ resolution, χ and staged source-bound K\_{r,t}, per-edge ρ, Score\_bp κ, the timestamp-proved α envelope, the carried implementation\_extension\_map, the put-once store, unconditional terminal-state refusal, effective-dated lifecycle authorization, authenticated latest head, anti-rollback checks, and revised §7.5 semantics. A refreshed schema projection, content-addressed Σ\_NBM4 bundle, crosswalk, suite, and immutable public evidence package are required before stronger wording. This private repository status does not discharge H1–H6.

### D.4 Substrate Governance Surfaces Beyond the Framework (v9.3)

The reference substrate operates several governance surfaces that the DODGE formal model does not define and that §4’s properties do not depend on. v9.3 inventories them here for two reasons: they are part of the operational reality any reader of §7.7 or C.6 is implicitly relying on, and several are candidate future framework contracts. All rows are author-reported; none are independently accessible evidence.

| Surface | Author-reported description | Relation to the framework |
| --- | --- | --- |
| Prompt-intake transport adapters | Hook-delivered adapters for three agent harnesses (session-start, prompt-submit, pre-tool, and stop events) rendering one shared PromptIntakeResponse contract; non-logger tool calls are mechanically blocked until typed gate evidence exists for the newest pending intake | Delivery layer for §3.14; harness-portability of the gate is a substrate property, not a framework requirement |
| SEL ledger family | Dated append-only ledgers for gate decisions, planning decisions, and stage decisions, each row typed and hash-referenced | Realizes G-63 and G-65; a future framework contract could bind SEL references into GGC evidence_refs |
| Route-plan state store | Per-session route-plan state records that the live path consumes as Compiler input, with post-turn synchronization checks that fail closed when sync is disabled | Substrate realization of the Plan-to-Compile handoff; the v9.3 model does not specify a session state store |
| Artefact Traceability Graph | Repository-wide derived graph index over governed artifacts with a typed relationship vocabulary and registered query presets; admission of capability, worker, and skill nodes is in progress under a triaged RFC | Realizes G-68; extends A₇-style traceability from committed executions to the full artifact population |
| WiP Board | A queryable registry of declared work-scope intentions with session-start, heartbeat, and session-end states, used to detect stalled or abandoned scopes and to arbitrate parallel sessions claiming overlapping scope | Concurrency governance between human-agent sessions; the framework model is single-lifecycle and does not address scope contention |
| Session lifecycle artifacts | Per-session governed records and closure receipts binding a session’s gate decisions, planning decisions, and produced artifacts | Session-scoped audit envelope around IPCE runs; complements, but is not, the per-run OutcomeBundle contract |
| Release-claim surfaces | The conformance ledger, blocked-phrase registry, and executable claim gate of §3.16 | Governs claims about the system; a framework-level claim-governance contract is future work |
| Route amortization practice | Routes are registered after observed repeated traffic rather than speculatively, and recompiled on policy or schema drift, so ratification cost is paid once per route rather than once per run | Operational economics of G-61/G-69; no empirical cost measurements are reported |

Two structural observations follow from this inventory. First, the substrate governs *sessions and claims* in addition to *executions*: the intake gate, planning gate, WiP Board, and claim gate all operate on surfaces the v9.2 model never reaches, which is consistent with the substrate’s practice of building ship-mlp by ship-mlp — each newly governed surface was added where an ungoverned failure actually occurred. Second, every one of these surfaces follows the same two-part pattern the framework’s Compiler establishes: a typed record requirement plus a fail-closed admission check. That recurrence suggests the pattern, not any single gate, is the framework’s transferable core; formalizing the session-scope and claim-scope instances as framework contracts is future work.

* * *

## Appendix E: Change History

### E.1 Changes in v9.3

This revision leaves the v9.2 formal model, formal properties, substance-axis grid, and conformance-case table unchanged; every reference to “the v9.3 model” therefore denotes the v9.2 formal model under its new version number. What v9.3 adds is descriptive coverage of governance surfaces that already operate in the author’s private reference substrate but that earlier versions did not document: prompt-intake governance (§3.14), the bounded planner rejection loop (§3.15), release-claim governance (§3.16), typed stage-decision evidence, glossary rows G-63 through G-69, an updated operational-status note for DODGE-RFC (C.6), and a new substrate-surface inventory (D.4). All additions are author-reported implementation-derived material and carry no new formal or empirical claims.

### E.2 Version Lineage Since v1

The summaries below are derived from the retained version files in the manuscript’s working folder and their adversarial-triage records. Dates are taken from each file’s recorded metadata where present; versions before v8.5 carry no per-file dates, and the lineage’s earliest recorded timestamp is the working folder’s creation on 2026-05-17. Versions v1 through v7.1 were titled *“Shipping Better MLPs Faster: A Governed Graph Commit Architecture for Domain-Ordered AI-Assisted Product Development”*; the v8 series retitled the paper around the framework itself.

| Version | Date | Headline changes |
| --- | --- | --- |
| v1 | 2026-05-17 (folder) | Initial draft: Governed Graph Commit concept, DOGDD governance-layer stack, deterministic-bounded-space claim (§4), NBM4 instantiation with cardinality appendix, adversarial validation methodology. |
| v2 | — | Revision under the first four-model adversarial triage round (Copilot, Gemini, GPT-5 Pro, Opus reviews retained alongside); section structure unchanged. |
| v3 | — | Second triage-response revision; structure unchanged. |
| v4 | — | Consolidation pass; minor growth, structure unchanged. |
| v5.1 | — | Major expansion (roughly doubled): §4 reframed from a determinism proof to Bounded Topology, Invariance, and Replay (the bounded-topology / commit-invariance / replay-equivalence property family); §6 became Layer Composition and Gap Closure. |
| v5.2 | — | Targeted fixes feeding the third adversarial triage round (five-reviewer panel including CPO-persona reviews). |
| v6 | — | Post-triage upgrade: Φ predicate grammar formalized (Appendix A), field-level L tables (Appendix B), DOGDD-NBM4 naming, new Appendix C sketching DOGDD-RFC as a second instantiation; separate “is-arXiv-ready” triage performed. |
| v7 | — | New Appendix D: reference-implementation substrate cross-reference to the private ship-mlp Blueprint; external feasibility review recorded 2026-06-10. |
| v7.1 | — | The implementation-contract version: the revision the substrate’s conformance program (RFC-0220, RFC-0235, RFC-0240) targets and the version its checks and ledger still cite; P-CRE restated over G_eligible. |
| v8.1 | — | arXiv-preparation restructure: retitled to Domain-Ordered Directed Graph Governance for AI-Assisted Product-Hypothesis Formation; Reader’s Guide and Glossary introduced; §7 became Validation Method and Implementation Evidence with a §7.7 conformance-evidence section; C.6 operational-status note; substance-axis comparator grid; supply-chain apparatus positioning (Sigstore, in-toto); a LaTeX build of this version exists. |
| v8.2 | — | DOGDD renamed to DODGE: “Governance” became “Execution” across the title and stack. |
| v8.3 | — | Subtitle added: A Scoped Architecture Paper with Formal Proof Sketches and Author-Controlled Implementation Evidence. |
| v8.4 | — | Subtitle dropped; claims-wording tightening. |
| v8.5 | 2026-07-10 | Note frontmatter adopted; minor edits. |
| v8.6 | 2026-07-10 | Prose pass; no structural change. |
| v8.7 | 2026-07-10/11 | Largest v8 hardening: P-OUT (runtime output admissibility) added; P-IMM extended to persistence and anti-rollback; runtime cardinality protocol reframed from “collapse” to “violation”; σ-pinned profiles Ψ_NBM4 (§5.2.1); §7.1 reworded from “Claims Supportable by Formal Proof” to “Claims Addressed by Formal Argument”. |
| v8.8 | 2026-07-11 | Alignment-limit bookkeeping refresh (§7.7.4). |
| v8.9 | 2026-07-11 | §6 reframed from “Gap Closure” to “Control Coverage”; Score_bp basis-points confidence contract introduced. |
| v9.0 | 2026-07-11 | Epistemic-honesty reframe: implementation-evidence language downgraded throughout to author-reported implementation status (§7, C.6, Appendix D); §7.5 renamed to Adversarial Conformance Test Cases. |
| v9.1 | 2026-07-12 (pub. 07-14) | Largest conceptual leap: hypothesis alignment (H_set), IPCE lifecycle vocabulary, P-HALIGN, the OutcomeBundle contract, route/standard-task registries, five-tier validation pipeline naming, numbered G-N glossary (60 rows), and conformance cases TC-21–TC-23 (alignment bypass, hypothesis-authority, OutcomeBundle-authority attacks); retitled to Compile-Time Governance for Hypothesis-Aligned AI Execution. The header version field lagged at 8.9 (corrected in v9.2). |
| v9.2 | 2026-07-15 | Logical-soundness audit pass: glossary topologically reordered and expanded to 62 rows, abstract G-N cross-reference tags, governance “Layer” disambiguated to “Tier” (keeping epistemic L1–L4), C_plus and citation fixes, namespace notes for the three L1/L2 label families. |
| v9.3 | 2026-07-16 | Substrate-derived documentation additions; formal model unchanged (E.1). |

* * *