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.

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.

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.

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.

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.

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

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:

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:

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:

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:

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:

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:

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

χ = {
  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:

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.

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:

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:

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:

Π_σ = 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:

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

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:

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

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:

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):

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:

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:

ρ(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:

|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:

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 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.

5.4 Key Relationship Cardinalities

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:

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.

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

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.

7.3 Claims Requiring Empirical / User-Study Evidence

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

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):

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. DOI: 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.

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.

Cardelli, L. (1996). Type systems. ACM Computing Surveys, 28(1), 263-264. DOI: 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.

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.

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.

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/.

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.

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.

Irving, G., Christiano, P., & Amodei, D. (2018). AI safety via debate. arXiv:1805.00899. https://arxiv.org/abs/1805.00899. DOI: 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.

Kozloff, M. (2024). The NBM4: Your Guide to Innovative Business Models & Products. NBM4.com. 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. 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. DOI: 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. DOI: https://doi.org/10.48550/arXiv.2605.01037.

Microsoft. (2026). AutoGen documentation. 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. DOI: 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.

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.

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.

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. Project overview: 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/.

OpenAI. (2026). Agents SDK documentation. 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. Accessed 2026-07-09.

OpenSSF. (2026). SLSA specification 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.

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. DOI: 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.

Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business. 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. DOI: 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. DOI: https://doi.org/10.17487/RFC8785.

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

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

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

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

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

Temporal Technologies. (2026). Temporal workflow documentation. 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/.

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.

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.

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. DOI: 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. DOI: 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. DOI: 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)

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)

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

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.

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:

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 Ψ.

B.5 Selected Readable Projection of F and L

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

C.2 Artifact Type Universe (sample)

C.3 Sample Relationships and Cardinalities

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.

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:

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.

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.