Shipping Better MLPs Smarter

July 08, 2026

Idea and draft by Michael Kozloff

Adversary triage by ChatGPT, Claude, Gemeni, Grok, Microsfot 365 Copilot. Final publication by ChatGPT.

A Governed Graph Commit Architecture for Domain-Ordered AI-Assisted Product Development

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

Author: Michael Kozloff Acknowledgements: Developed in dialogue with Claude (Anthropic), GPT-5.5 Pro (OpenAI), Microsoft Copilot, Grok, and Gemini 3.1 (Google) as adversarial reviewers across multiple draft revisions. AI assistance contributed to argument stress-testing and prose refinement; all inventive contributions are the sole work of the author. Status: Draft v0.8 — Pre-publication. Bumped from v0.7.1 to absorb two update tracks. Track E — implementation evidence (E1–E6): (E1) new §7.7 reports the first completed implementation-conformance evidence block: all twenty adversarial test cases TC-1–TC-20 (§7.5) are now mechanically asserted, with typed rejection codes, in the ship-mlp reference implementation’s paper-indexed conformance suite, scoped to the check-API layer; (E2) the claim boundary is itself machine-enforced — a machine-readable conformance ledger plus an executable release-claim gate block unqualified conformance wording structurally (§7.7.3); (E3) three named deviations between the reference implementation and this paper’s full requirement set are declared explicitly (live-path substrate unification; cryptographic key custody; SpecSeed handoff — §7.7.4); (E4) §7.2’s implementation-demonstration claims table carries a v8 status column; (E5) Appendix D.3 is rewritten to the current implementation status and D.1.1 lists the landed check-API artifacts; (E6) §8.2/§8.3 limitations and future-work priorities are updated accordingly, and Appendix C gains an operational-status note (C.6). Track P — plain-language companion (P1–P2): (P1) a reading guide after the abstract maps every formal object (GGC, Σ, Φ, α, β, γ, L, κ) to product-management language; (P2) marked “In plain terms” companions accompany each major section so the paper is readable by product leaders without a formal-methods background. No formal property, definition, proof sketch, or claim from v7.1 is changed by Track P; it is an additive explanatory register. 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.

Abstract

This paper makes no empirical claim that DOGDD ships products better or faster. The title is a statement of purpose, not a theorem. What the paper contributes is an architectural forcing function for governing AI-assisted product-hypothesis formation, with proof sketches of structural properties, a validation methodology, and — new in v8 — a first completed implementation-conformance evidence block from the ship-mlp reference implementation.

AI-driven product development workflows commonly allow execution topology to emerge dynamically through agent delegation, tool calls, and content-conditioned branching. This produces execution graphs that are unauditable before execution, non-replayable for learning, and ungovernable at material decision points. No governance framework can make product outcomes deterministic — markets shift, wars happen, customers change. The goal is not certainty. The goal is structural soundness: eliminating known failure modes before execution, encoding domain best practice as compiler constraints, and ensuring human judgment governs every material decision fork.

This paper introduces Domain-Ordered Directed Graph Governance (DOGDD), a framework parameterised over a domain methodology Σ, whose central architectural claim is enforced production: open-ended AI planning is not executable. It must first be transformed — through a domain-bounded, cardinality-constrained, scored, adversarially triaged, human-ratified, compiler-validated pipeline — into a Governed Graph Commit (GGC). Only the GGC is executable. Most systems achieve topology invariance by removing freedom at execution time. DOGDD achieves it by forcing all freedom to be expressed, bounded, and ratified before execution. This is the architectural distinction.

DOGDD combines five governance layers — domain-ordered artifact schema with field-level scope bounds, ERD-style cardinality bounds, scored edge enumeration with a typed bounded-aggregation predicate language, adversarial confidence triage, and mandatory human-in-the-loop approval — to produce the GGC. The paper defines the GGC at two precision levels: a minimal formal model C_min = (V, E, λ, ρ, α, σ, μ) used for proofs, and an implementation model C_plus = (V, E_exec, E_audit, λ, ρ, κ, β, α, γ, σ, μ) where γ is a compiler attestation distinct from α (human approval). The executor consuming a GGC is graph-closed: it cannot add or remove nodes or edges at runtime, and verifies both γ and α before constructing its immutable adjacency table.

We formalise sufficient conditions for DOGDD to bound the legal topology space before execution (P-BLS), guarantee topology invariance after commit (P-TI), guarantee commit-replay equivalence under a commit-bound activation context K with three operational modes A/B/C (P-CRE-A and P-CRE-B), and admit only structurally well-formed commits (P-COMP). The realistic default operating mode is Mode B — activation values are computed at runtime and replay-logged in a content-addressed log. Proof sketches are provided; mechanised proofs are identified as future work. We do not claim deterministic LLM content generation, deterministic product outcomes, or unique graph generation from natural-language intent.

Implementation evidence status (NEW in v8). The ship-mlp reference implementation now mechanically asserts all twenty adversarial test cases from §7.5 in a paper-indexed conformance suite with typed rejection codes, backed by a machine-readable conformance ledger and an executable release-claim gate. This evidence is explicitly scoped: it demonstrates the compiler/executor/evidence contracts at the check-API layer, under three named deviations (live-path substrate unification, asymmetric key custody, and the SpecSeed handoff — §7.7.4). We deliberately do not claim unqualified or full conformance; the reference implementation’s own release gate blocks such wording mechanically while any named deviation remains open. Empirical hypotheses H1–H6 remain future work.

DOGDD is parameterised over Σ. The first reference instantiation is DOGDD-NBM4 for product management; a sketched second instantiation, DOGDD-RFC, for governance over AI orchestration RFCs is provided in Appendix C to demonstrate domain-agnosticism by construction rather than by assertion. NBM4 is one possible Σ; alternative product-development methodologies (Lean Canvas, JTBD, Continuous Discovery) would yield valid alternative Σ instantiations.

How to Read This Paper — A Plain-Language Track for Product People (NEW in v8)

This paper runs in two registers at once. The formal register — the Greek letters, the propositions, the proof sketches — is what makes the claims checkable by researchers and engineers. The plain register — the marked “In plain terms” companions after each major section, and the glossary below — is for product managers, founders, and product leaders who want to understand what this architecture does for them without reading type theory. Neither register waters down the other: every plain-language statement is backed by a formal one, and if the two ever disagree, the formal one wins.

The one-paragraph version of the whole paper: today, when you hand product work to AI agents, the AI decides what to do while it runs — and you find out afterwards. DOGDD flips that. The AI must first lay out its entire proposed plan as a diagram of typed work items, that diagram is checked against your methodology’s rules by software (not by vibes), stress-tested by a panel of rival AIs, and then signed off by you — and only the signed, locked plan can execute. The executing system is physically unable to run anything else. Every run leaves a tamper-evident record of what was planned, who approved it, and what actually happened.

Glossary — formal object → what it means for a product team

In plain terms — why should a PM care at all? Because “we use AI agents” currently means “we run processes nobody can inspect in advance, reproduce afterwards, or hold anyone accountable for.” If an AI quietly skips customer discovery, invents 30 features, or ships scope nobody approved, you learn about it from the wreckage. DOGDD’s bet is that the fix is structural, not motivational: make the ungoverned path physically unavailable, the way double-entry bookkeeping made invisible money movements unavailable — not by asking clerks to be careful, but by changing what counts as a valid record.

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 prioritised, and structurally sound. It still failed.

No framework prevents this. No AI system predicts war, pandemic, or the precise moment a competitor pivots. Any paper claiming to make product development deterministic is selling a theorem the future will not honour.

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 catalogued and named.

These failures are not caused by an unknowable future. They are caused by an ungoverned present.

Scope of DOGDD. This framework governs the executable path from product intent to artifact-producing AI execution. It does not govern exploratory, conversational, or interpretive work — napkin sketches, interview synthesis, informal PM reasoning — that does not invoke an Executor. DOGDD’s governance begins when a product team decides to run AI agents against a product-hypothesis plan. Everything before that point is upstream; everything after is downstream.

1.1 The Structural Problem with Current AI-Assisted Development

AI agent frameworks have made product teams faster. They have not made them more governed. The dominant pattern — prompt an agent, let it decompose tasks, execute — produces execution graphs that share three structural properties:

Unauditable before execution. Graph shape emerges as a side-effect of running. There is no pre-execution artifact a PM can inspect, challenge, or ratify. The agent starts; the PM watches.

Non-replayable for learning. When a product fails, the execution path that produced it cannot be reconstructed. Institutional memory does not accumulate. The next team makes the same structural mistakes.

Ungovernable at material forks. When the AI decides to generate 12 features instead of 4, or skip pain validation, or skip a discovery stage entirely, there is no structural gate that catches it. Prompt discipline — constraining agents via natural-language instructions — is the dominant mitigation. It is insufficient: a prompt cannot enforce its own compliance inside the system it is constraining.

The result is AI-assisted development that is faster but not sounder. Speed applied to an ungoverned process produces wrong things faster.

In plain terms — the three failure modes above have everyday names. Unauditable: you cannot see the plan before it runs. Non-replayable: you cannot reconstruct what happened after it runs. Ungovernable: nothing stops scope from mutating while it runs. And the popular fix — writing sterner prompts — is asking the fox to enforce the henhouse rules, in the henhouse, in fox language.

1.2 What Governance Means Here

Governance in this paper means three things, precisely:

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 prioritise — a human approves the topology before execution. Not after. The AI proposes; the PM ratifies; the compiler enforces.

Auditable institutional memory. Every execution produces an immutable, human-attributed record of what was decided, why, and by whom. Post-mortem analysis becomes possible. Successful patterns become reusable. Others’ mistakes, encoded in domain methodology, become structural guardrails.

1.3 The Central Contribution

This paper introduces Domain-Ordered Directed Graph Governance (DOGDD) — a five-layer governance stack, parameterised over a domain methodology Σ, that transforms AI planning output into a Governed Graph Commit (GGC): a bounded, inspectable, adversarially reviewed, human-ratified, compiler-validated execution artifact.

The contribution is the specific conjunction at the product-hypothesis layer (L3):

• input shape = open-ended AI planner output (not human-authored workflow code or pre-existing diagrams)
• subject domain = typed product-hypothesis artifacts (Pain / Persona / Feature / ValueProposition / GTMChannel) with declared semantic relationships
• constraint origin = cardinality bounds derived from a domain methodology (NBM4 instantiation; Lean Canvas, JTBD, RFC governance are alternative Σs)
• HITL semantics = human approval is a precondition for artifact existence, enforced as a compile-time type error, not a runtime pause
• closure = the executor accepts only compiler-attested commits, verified by content hash, with no graph-mutation API surface
• epistemic layer = L3 (product hypotheses), where market truth is unavailable ex ante and correctness is structural-risk-reduction
• audit closure = every executed traversal is traceable back to (a) the exact ratified topology, (b) the signing human, (c) schema/model/tool version pins at sign time, (d) evidence bundles that confirm/weaken/invalidate/supersede

We invite reviewers to identify an existing system populating any five of these seven axes simultaneously; we know of none. The substance-axis grid in §2.3 plots every cited comparator against these axes explicitly.

In plain terms — plenty of tools do one of these things: workflow engines lock a diagram, approval tools collect sign-offs, audit tools keep logs. The claim here is narrower and stronger: no existing system combines AI-drafted plans + product-methodology rules + your signature as a hard precondition + a runner that can execute nothing else + a full who-approved-what audit trail — all at the layer where product bets are formed, before any code exists. The contribution is the combination, not any single ingredient.

1.4 Domain Instantiation and Parameterisation

DOGDD is parameterised over the domain methodology Σ. The framework’s contribution is the pattern of compile-time governance; specific Σ instantiations are reference implementations, not the contribution itself.

Primary reference instantiation: DOGDD-NBM4. Product management is the proof-of-concept domain; NBM4 (Kozloff, 2021) supplies the artifact schema, stage ordering, and cardinality bounds. NBM4 is authored by the present author and is therefore declared explicitly as one available Σ — not as proof that NBM4 is the correct PM methodology, and not as evidence that DOGDD’s structural properties depend on NBM4’s specifics. Alternative product-development methodologies — 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 Σ instantiations with different stage counts, artifact type universes, and cardinality tables. The formal properties (P-BLS, P-TI, P-CRE, P-COMP) hold for any finite Σ regardless of which methodology supplies it.

Sketched second instantiation: DOGDD-RFC. Appendix C sketches DOGDD 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 governance layers and the same GGC structure apply.

In plain terms — DOGDD is a governance engine; your methodology is the cartridge. The paper demonstrates it with NBM4 (the author’s own product methodology, declared as such), but Lean Startup, JTBD, Continuous Discovery — or your company’s internal playbook — plug into the same engine. If your methodology can be written as “these artifact types, in this order, with these limits,” it can be enforced.

1.5 Apparatus and Non-Claims

DOGDD’s contribution is the composition of governance layers 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.

This table is a defensive non-claim. A reviewer who attacks “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 the conjunction operate as a compile-time precondition for AI execution at the product-hypothesis layer — not novelty in any of the primitives listed.

1.6 Paper Structure

Section 2 reviews prior art and plots every comparator against a seven-axis substance grid. Section 3 presents the DOGDD governance stack, four-level graph model, GGC definition (minimal and implementation models), the L3 → L2 handoff down(C) → SpecSeed, and Schema Governance. Section 4 provides formal propositions and proof sketches. Section 5 instantiates DOGDD-NBM4 in product management. Section 6 describes the gap-closure ablation analysis. Section 7 presents the adversarial validation methodology and — new in v8 — the reference-implementation conformance evidence (§7.7). Section 8 concludes with limitations and future work. Appendices give the full Φ grammar (A), the NBM4 cardinality table and field-level scope bounds (B), a sketched DOGDD-RFC second instantiation with an operational-status note (C), and the reference-implementation substrate cross-reference to ship-mlp Architecture Blueprint v0.7 (D).

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. The foundational arXiv paper (Piskala, 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 fifteen documented frameworks — from Spec-Kit to enterprise systems to academic proposals. Constitutional Spec-Driven Development (Marri, arXiv:2602.02584, 2026) adds governance layers: security constraints with explicit CWE vulnerability mappings, audit trails, and supervision checkpoints — the closest prior work to DOGDD in governance intent, at a different epistemic layer.

Wasowski (2026) pushes the movement further: stop writing specs entirely, write facts. His argument is precise. Natural-language specifications require model interpretation — and that interpretation drifts. A machine-executable assertion — a BDD Given/When/Then scenario, a typed predicate, a compiler-enforced contract — does not drift. It either passes or fails. That is a fact.

Wasowski is correct 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

In product development, facts do not exist before market validation. “Customers will pay $50/month for this feature” is not a fact — it is a hypothesis. It becomes fact only when enough customers pay and unit economics survive long enough to confirm the business model. A team can conduct the most rigorous customer discovery in the world, validate pain with 200 interviews, prioritise features with perfect WSJF scoring, and still ship a product that fails — because the market shifted, a competitor pivoted, a technology became commoditised, or a geopolitical event restructured the demand landscape entirely.

This is not a deficiency of methodology. 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.

DOGDD does not claim otherwise. Its central artifact — the Governed Graph Commit — is not a fact about the product. It is a governed hypothesis: structured, domain-constrained, adversarially reviewed, and human-ratified. The GGC records the reasoning and governance around a hypothesis, not the truth of its outcome.

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.

Product layer (DOGDD): governed hypotheses → GGC
Code layer (SDD):      governed facts       → executable specs → code

SDD governs implementation specification — the formalization of what the system should do, at Layer 2. DOGDD governs product hypothesis formation — the ratification of which hypotheses are worth building toward, at Layer 3. SDD receives a spec and asks: is this spec correctly implemented? DOGDD receives an intent and asks: is this hypothesis structurally sound, domain-constrained, and human-ratified before AI executes it? These are different epistemic operations at different layers. These frameworks are complementary infrastructure: a GGC produced by DOGDD at Layer 3 can seed Layer 2 SDD specifications via the down(C) → SpecSeed handoff defined in §3.11.

In plain terms — the software world is converging on “write precise specs, let AI write the code.” Fine — but where do the specs come from? From product bets: which pains matter, which features to build, who the customer is. Those bets cannot be “verified” like code, because the market has not voted yet. DOGDD governs that layer: not “is the code right,” but “was this bet formed responsibly — constrained by method, challenged by reviewers, signed by an accountable human — before we spent AI horsepower and payroll on it.”

2.2 Workflow, Orchestration, and Verification Frameworks

We name the closest adjacent systems and the axis on which each touches DOGDD. Each system is genuinely useful; none populates the DOGDD 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-methodology 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 reviewer who asks “isn’t this just LangGraph with HITL discipline?” is correct that topology invariance can be achieved through developer discipline in LangGraph — but achieving it as a compile-time precondition requires the architectural forcing function DOGDD 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 — DOGDD uses Temporal-style replay logging as Mode B tooling but does not contribute novelty in replay infrastructure.

BPMN 2.0 (OMG specification) provides standardised process notation and semantics for business process modelling. BPMN is human-authored process diagrams; DOGDD’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 four-level graph model (G_legal → G_proposed → G_candidate → G_approved → G_active) that DOGDD formalises.

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

Agentproof (Xavier et al., 2026; arXiv:2603.20356) is a close concurrent prior-art comparator on adjacent territory and warrants explicit differentiation. Agentproof extracts a unified abstract graph model from four production agent frameworks (LangGraph, CrewAI, AutoGen, Google ADK) and performs static verification with witness trace generation, plus runtime monitoring of event traces. Temporal safety policies — including a human-gate policy — are declared in a seven-form DSL, compiled to deterministic finite automata, and checked against the workflow graph via graph × DFA product construction. Agentproof verifies workflow graphs that have already been authored as framework code; DOGDD governs the formation of a topology from open-ended AI planner output that does not yet exist as code. Agentproof treats a human-gate as a verifiable temporal property (the DFA must observe an approval event before a sensitive transition); DOGDD treats HITL as a structural compile gate (the Compiler refuses to produce a GGC absent a cryptographically valid α bound to the exact hash of G_approved). Agentproof operates at Layer 2 — verifying that a known workflow execution specification satisfies declared safety properties. DOGDD operates at Layer 3 — governing which hypothesis topologies are even admissible as candidates before any specification or verification question is meaningful. Agentproof and DOGDD are complementary, not overlapping. A GGC produced by DOGDD’s Compiler is, by P-COMP, structurally well-formed at the topology layer; an Agentproof-style temporal policy verifier could be composed downstream over (V, E_exec, ρ) to check additional safety properties orthogonal to schema and cardinality conformance.

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

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; DOGDD’s target is pre-execution ratifiability of hypothesis topology. Both use content-addressed artifacts; they address different problems.

Certified Purity for Cognitive Workflow Executors (arXiv:2605.01037, 2026; added v7.1 C5) converts governance enforcement from runtime convention into structural capability boundaries using restricted WebAssembly, signed purity certificates, runtime verification gates, and remote attestation. It is the closest concurrent prior art on the executor-closure + cryptographic attestation substrate. Certified Purity operates at the code-execution layer (functional purity of computational steps inside a sandboxed runtime); DOGDD operates at the L3 product-hypothesis-formation layer. The mechanisms overlap on substrate (WASM sandboxing, signed certificates, attestation gates) but not on subject matter (purity of computations vs ratification of product-hypothesis topology). Certified Purity is admissible as an alternative substrate satisfying DOGDD’s executor-closure invariant (Appendix D.2); it does not satisfy DOGDD’s L3-conjunction. The presence of this prior art narrows DOGDD’s novelty subclaim: the executor-closure + attestation component is no longer a unique contribution; DOGDD’s contribution is the L3 hypothesis-governance conjunction that includes executor closure as one of seven axes.

HTN planning (SHOP / SHOP2) decomposes goals hierarchically under task-network constraints. HTN planners construct plans; DOGDD does not construct plans (the Planner produces G_candidate via LLM call). HTN constraint structure resembles Σ in that both encode methodology, 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; DOGDD targets L3 product-hypothesis-by-construction.

Recent LLM-agent workflow surveys (arXiv:2603.22386, 2026) distinguish static vs dynamic workflow structures. DOGDD uses that vocabulary: it makes the topology strictly static at execution time by forcing every dynamic decision into the pre-execution governance pipeline.

2.3 The Substance-Axis Grid

We claim DOGDD’s contribution is the conjunction of seven substance axes simultaneously. The exclusivity claim is not “no system does anything similar”; it is “no cited system populates five or more of these axes simultaneously“. The grid below plots every comparator from §2.2 against the seven axes. Reviewers are invited to falsify by naming a system populating five or more axes — we know of none.

Axes

• A₁ Input shape — open-ended AI-planner output (not human-authored workflow code, not pre-existing diagrams)
• A₂ Subject domain — typed product-hypothesis artifacts with named semantic relationships (Pain / Persona / Feature / etc.), not generic tasks/states/activities
• A₃ Constraint origin — cardinality bounds derived from a product-development methodology (not implementation, not security, not process compliance)
• A₄ HITL semantics — human approval is a precondition for artifact existence (compile-time type error 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 layer — L3 (product hypotheses under irreducible market uncertainty), explicitly distinct from L1/L2/L4
• A₇ Audit closure — every executed traversal maps back to (a) ratified topology, (b) signing human, (c) schema/model/tool pins, (d) evidence bundles confirming/weakening/invalidating/superseding

The best any cited prior system manages is roughly 1.5 axes; methodologies (Lean, JTBD, NBM4) populate three of seven on subject and layer but supply no compile-time system. The conjunction at all seven axes is unoccupied in the surveyed comparator set. DOGDD’s novelty claim is restricted to this conjunction; we make no novelty claim in any individual axis.

Systematic prior-art search protocol (v7.1 C10). The substance-axis grid above was constructed by the following search protocol, made explicit to replace the informal “we know of none” framing and to enable reviewer extension:

1. Seed comparators drawn from four families: (a) workflow/orchestration frameworks (LangGraph, Temporal, BPMN, OpenAI Agents SDK, AutoGen, Airflow, Prefect, Dagster); (b) static workflow verification (Agentproof); (c) execution-lineage and durable-replay systems (Execution Lineage, Constitutional SDD, Spec Kit, Certified Purity); (d) product-development methodologies (NBM4, Lean Startup, JTBD, Continuous Discovery, Value Proposition Canvas).
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 schema” + “AI workflow”}. Search window: 2023-01-01 through 2026-05-15.
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. We commit to updating the grid in a public erratum upon any such citation.

This protocol is reproducible and bounded; it makes the “we know of none” claim falsifiable by named system rather than rhetorical. Reviewers extending the search are invited to submit additions; the grid is a living artifact in the paper’s companion repository.

2.4 The Hypothesis-Governance Gap

The deepest gap in existing frameworks is not architectural — it is epistemic. Every workflow, spec, and orchestration framework in the prior art assumes the problem is execution of known intent. The harder problem — governing the formation of intent under uncertainty — is unaddressed at L3.

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. No framework accelerates this.
              ↑
Layer 3: Product hypotheses
         Which pains are real. Which features address them.
         Which segments exist. Which value propositions resonate.
         Governed by: DOGDD → 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.

DOGDD 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 DOGDD does. Not because the product voyage is predictable — it is not. Because a governed voyage through uncertainty is categorically better than an ungoverned one, regardless of what the sea does next.

In plain terms — picture four floors of a building. Floor 1: does the code do what the spec says? (Tests answer that.) Floor 2: is the spec itself precise and enforced? (The spec-driven movement answers that.) Floor 4: did the market buy it? (Only reality answers that.) Floor 3 — which product bets deserved to be specced and built at all — has had no enforcement discipline. It runs on judgment, slide decks, and hope. That floor is where DOGDD installs the machinery: your bets stay bets, but they become governed bets — formed under rules, challenged before commitment, signed by someone accountable, and auditable afterwards.

3. Domain-Ordered Directed Graph Governance — The DOGDD Stack

3.1 Four-Level Graph Model

DOGDD operates over four distinct graph levels. Conflating them produces false claims. Separating them produces precise ones. A fifth intermediate level, G_proposed, names the raw Planner output before any Compiler validation; only after static filtering does it become a G_candidate.

G_proposed — raw Planner output from intent I. May be malformed, contain illegal artifact types, or violate cardinality bounds. G_proposed ∉ G_legal is possible; this is the level at which the Compiler operates filtering, not the level a reviewer should assume is legal.

G_legal(Σ) — the set of all graphs permitted by domain schema Σ and cardinality constraints. The bounded space of structurally legal executions. Defined before any planning occurs. Parameterised by Σ.

G_candidate — a specific graph proposed by the Planner and admitted by the Compiler’s static pass: G_candidate = filter_Σ(G_proposed) and G_candidate ∈ G_legal. Contains all candidate nodes including those not yet activated, with typed activation conditions attached to edges.

G_approved — the graph ratified by human approval and compiled into an immutable Governed Graph Commit C. G_approved ⊆ G_candidate after PM edits (with material edits triggering re-triage; see §3.7). This is the graph the Executor is contractually bound to.

G_eligible(r) (introduced in v7.1 per C2) — the subgraph determined purely by predicate evaluation over the activation context K_r. G_eligible(r) ⊆ G_approved. A node is in G_eligible(r) iff (a) it has no activates incoming edge, OR (b) all its activates incoming edges’ predicates evaluate true under K_r, AND (c) all its requires and derives_from predecessors are in G_eligible(r). Eligibility is a function of K alone, independent of execution success or failure.

G_executed(r) (introduced in v7.1 per C2) — the subgraph of G_eligible(r) whose nodes actually reached status COMPLETED in runtime r. G_executed(r) ⊆ G_eligible(r). Whether an eligible node completes depends on runtime reliability (timeouts, worker failures, transient errors), not on K. P-CRE-A/B (§4.4) claims repeatability of G_eligible, not G_executed; reliability is a separable concern outside the scope of replay equivalence.

G_active(r) — deprecated label retained for cross-reference to v6/v7; reads as G_eligible(r) in all proof contexts and as G_executed(r) in all execution-trace contexts. New text in v7.1 onward uses the precise terms.

SKIPPED nodes are committed candidates in G_approved that are not in G_eligible(r) — predicates evaluated false under K_r. They appear in the execution trace with status SKIPPED, distinct from FAILED nodes which were eligible but did not complete.

Node definition. A node v ∈ G_candidate is a candidate work unit — a planned slot for AI-executed work, carrying type, stage assignment, input edges, and activation condition. A node v ∈ G_active(r) is an executed work unit — a candidate whose activation condition evaluated true in runtime r. SKIPPED nodes are candidates in G_approved that do not enter G_active(r); they appear in the execution trace with status SKIPPED but are not absent from the committed topology.

Chain. G_active(r) ⊆ G_approved ⊆ G_candidate ∈ G_legal; G_proposed ⊄ G_legal in general (raw planner output).

What DOGDD claims — precisely

• P-BLS — Bounded Legal Space: |G_legal(Σ)| < ∞ under finite Σ
• P-TI — Commit Topology Invariance: Fixed GGC → graph-closed Executor preserves V and E_exec
• P-CRE-A — Strict Replay Equivalence (Mode A): Pre-committed K → G_active(r₁) = G_active(r₂)
• P-CRE-B — Practical Replay Equivalence (Mode B): Replay-logged K → G_active(r₁) = G_active(r₂) under replay
• P-COMP — Compiler Admissibility: All accepted C satisfy declared structural constraints
• P-EDGE — Edge Semantic Biconditional: ρ(e) ∈ Φ ⟺ λ_E(e) = activates
• P-AUD — Auditability: Every execution trace maps to exactly one C with verifiable α and γ
• P-IMM — Commit Immutability: id(C) is collision-resistant; any modification produces id(C′) ≠ id(C)
• T4a — Inter-stage Acyclicity: Stage-forward edges imply acyclicity of the inter-stage subgraph
• T4b — Bounded M:N: |E(R)| ≤ min(max_out · |V_source|, max_in · |V_target|)

What DOGDD does not claim. Same intent I produces same G_candidate or G_approved across runs. The Planner is AI-driven. Human approval varies by PM and context. Two PMs running the same intent on the same schema will likely produce different G_approved. DOGDD does not — and need not — claim intent-level uniformity. Its guarantee is commit-level: what the PM approves runs exactly as approved, every time, producing an auditable record of that decision.

In plain terms — a plan goes through named states, like a contract going from draft to redline to signature. Draft (whatever the AI dreamt up), rule-checked draft (illegal parts rejected), signed plan (what you ratified), and finally what actually ran. Keeping these separate is what lets the system make honest promises: it never promises the AI drafts the same plan twice — it promises that the plan you signed is the only thing that can run, exactly as signed, and that skipped-versus-failed work is visibly distinguished afterwards.

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 topology-invariant artifact. Open-ended AI planning is not executable. It must first be transformed — through a domain-bounded, cardinality-constrained, scored, adversarially triaged, human-ratified, compiler-validated pipeline — into a Governed Graph Commit. Only the GGC is executable. The transformation is mandatory. There is no bypass.

The distinction is architectural, not definitional:

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

This is the invention. The three forbidden paths are:

Planner → Executor                          FORBIDDEN
Human Approval → Executor (uncompiled)      FORBIDDEN
Runtime Agent → New Topology                FORBIDDEN

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

The GGC is not merely an artifact. It is the sole admissible execution input. The compiler does not merely validate a graph — it materialises the only form in which AI-generated product-hypothesis topology is allowed to execute. No GGC, no execution. Every execution trace is grounded in a specific committed topology. Every deviation is a violation, not a feature.

This architectural forcing function is the contribution. Topology invariance is its enforced property. DOGDD is the method that produces it. DOGDD does not contribute novelty in graphs, compilers, attestation, replay, or HITL primitives individually (see §1.5 apparatus). The contribution is the conjunction that makes the forcing function operate at L3 product-hypothesis formation.

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 becomes a convention that developer discipline maintains. DOGDD removes the choice. Topology invariance is a compile-time precondition. The executor is structurally blind to anything that is not a valid GGC. It cannot execute an emergent runtime thought-chain because that format is not accepted by the executor API. The distinction is between a policy a developer upholds and a physics a system enforces.

The Trivial Executor Trap. A hostile reviewer will say: “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. It validates the entire epistemic chain — domain legality (node types legal for stage; stage-forward or legally intra-stage), scope boundary (multiplicities within c_candidate maxima), activation language (predicates well-typed members of Φ; no LLM calls; no external state), field-level scope (output content within field-level bounds L; see §3.4), human attribution (α cryptographically valid; references exact pre-commit hash), and compiler attestation (γ signed by Compiler’s attested key from a separate trust anchor). Any of those failing blocks production entirely. The executor’s hash verification is the final link — not the whole chain.

In plain terms — the difference between “policy” and “physics” is the whole idea. Policy: “our team agreed the AI shouldn’t add tasks mid-run.” Physics: “the runner has no API through which a task could be added — the request is not merely forbidden, it is unexpressible.” Every serious safety discipline eventually makes this move: banks moved from “don’t touch the vault” to vaults with time locks; aviation moved from “be careful” to interlocks. DOGDD makes the same move for AI-driven product work: the ungoverned path is not discouraged, it is absent.

3.3 The Governance Stack

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

Intent I
    ↓
Layer 1: Domain-Ordered Schema    → defines G_legal(Σ)
Layer 2: ERD Cardinality + L      → bounds G_legal (finite, enumerable; field-level)
    ↓
Planner
    ↓ G_proposed
Compiler.static (filter_Σ)
    ↓ G_candidate ∈ G_legal
Layer 3: Scored Edges             → typed activation predicates in Φ
    ↓
Layer 4: Adversarial Triage       → confidence verdict β on G_candidate
    ↓
Layer 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             → produces G_active(r) ⊆ G_approved

The GGC is the central artifact. It is not a byproduct of governance — it is the proof that governance occurred and the precondition that execution is permitted. Every downstream execution is a consequence of what the GGC contains. Execution without a valid GGC is a structural impossibility, not a policy violation.

In plain terms — five checkpoints, in order: (1) only legal work-item types in a legal order; (2) only sane quantities; (3) every branch decision written as a checkable formula; (4) a red team of rival AIs files its objections; (5) you sign — or nothing ships to execution. Then the gatekeeper stamps the whole package, and the runner accepts only stamped packages. Each checkpoint kills a distinct failure mode; §6 shows that removing any one of them reopens a hole.

3.4 Layer 1 — Domain-Ordered Schema (with Field-Level Scope Bounds)

A domain methodology 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.

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 edges are permitted only with requires or derives_from semantics and must pass a secondary topological sort within the stage (see §3.5 edge semantic types).

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

derives_from  — artifact B is derived from artifact A as input
                (e.g. FeatureSet derives_from PainPriorities)

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. PainPriorities activates FeatureCandidate)

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

The edge set is partitioned (revised in v7.1 per C1): E_exec = activates ∪ requires ∪ derives_from (scheduler-visible) and E_audit = evidence_for (audit-only). The reason: derives_from semantically means “B takes A’s output as input”; that is an input dependency, and the scheduler must respect it. Earlier drafts (v6/v7) placed derives_from in E_audit; this produced an inconsistency where the executor could schedule B before A despite A being a declared input. v7.1 promotes derives_from to E_exec — it now behaves like requires for scheduling (no φ; mandatory predecessor) but retains its distinct semantic label for type-checking purposes (the Compiler validates that B’s input schema accepts A’s output schema). evidence_for remains audit-only — it asserts epistemic support, not input dependency, and does not affect scheduling beyond the stage-forward rule.

Field-level scope bounds L (introduced in v6). 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, fname ∈ F(a)) → ScopeBound
ScopeBound = { max_list_length : ℕ ∪ {∞}, max_string_length : ℕ ∪ {∞}, closed_enum : Set ∪ ⊥ }

L is enforced at two distinct gates (revised in v7.1 per C3):

• 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; downstream requires/derives_from dependants do not become eligible.

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 methodology 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 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. Domain schema is a ratified encoding of domain methodology — 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, PainPriorities. Stage 3 (Value Suggestion) admits UserJobStory, FeatureSet, ValueMap. A FeatureSet node at Stage 2 is a Compiler rejection. A PainPriorities node at Stage 3 is a Compiler rejection. Within Stage 3, a FeatureRanking node may carry a requires edge from two FeatureCandidate nodes — legal intra-stage dependency, validated by secondary sort. A PersonaProfile node whose description field exceeds L(PersonaProfile, description).max_string_length is rejected for field-level overflow.

In plain terms — two kinds of guardrail live here. The ordering guardrail: features cannot be defined before pains are validated, because the schema literally has no legal slot for them there — the “skip discovery” shortcut every rushed team takes becomes a rejected plan, not a regrettable memory. The size guardrail (L bounds) closes the classic loophole: if you cap the number of Feature cards, a clever planner stuffs 200 features into one card’s description. L bounds cap what fits inside each card too — and they are checked twice: when the plan is drafted, and again when the AI actually writes its output.

3.5 Layer 2 — ERD Cardinality

For each relationship R: aᵢ → aⱼ where f(aᵢ) < f(aⱼ) (or intra-stage with requires/derives_from), a cardinality constraint c(R) = (min_out, max_out, min_in, max_in) bounds edge multiplicity on both sides. Two cardinality levels are distinguished:

• c_candidate(R): Bounds on G_candidate edges — validated by the Compiler against G_candidate before commit.
• c_active(R): Bounds on G_active edges — enforced by activation conditions at runtime. The lower bound of c_active cannot be statically validated by the Compiler unless activation values are pre-committed (Mode A); runtime violations are handled per §3.5.1.

Corrected M:N treatment. Stage ordering gives acyclicity of the inter-stage subgraph and one-directional edges. It does not eliminate M:N relationships. A Pain node may connect to multiple Feature nodes (Pain → Feature: 1:N). A Feature node may reference multiple Pain nodes as inputs (Pain → Feature viewed from Feature: N:1 incoming). The combination is N:M — bounded but not eliminated. Per T4b (§4.7), |E(R)| ≤ min(max_out · |V_source|, max_in · |V_target|). M:N is governed, not eliminated.

Optional artifacts are encoded via min_out = 0 (and/or min_in = 0). Mandatory artifacts via min_out ≥ 1 (and/or min_in ≥ 1). The Compiler enforces presence requirements structurally for candidate edges.

PM example. PainPriorities → FeatureSet: c_candidate = (1, 12, 1, 1). One PainPriorities node proposes 1 to 12 candidate Feature nodes; each Feature references exactly one PainPriorities. 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 cardinality.

3.5.1 Runtime Cardinality Collapse Protocol

If a c_active lower bound is violated at runtime — e.g., PainPriorities → FeatureSet requires min_out ≥ 1 active Feature, but all activation predicates evaluate false — the Executor MUST:

1. Halt the affected subgraph
2. Log a RuntimeCardinalityCollapse event in the trace, including the violated relationship, the K values that caused the collapse, and the 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_active lower bounds are not Compiler-enforceable in Mode B/C; they are runtime postconditions with declared collapse semantics.

In plain terms — cardinality is “how many is sane.” Your methodology says a prioritised pain justifies at most a dozen candidate features — so a plan proposing 25 is bounced automatically, with the violated rule named. And if reality collapses the other way (every candidate scores below the bar and zero features qualify), the system refuses to quietly proceed with nothing: it halts that branch, records exactly what data caused the collapse, and demands a new planning round. Silent emptiness is treated as loudly as silent excess.

3.6 Layer 3 — Scored Edges and Φ

The Planner receives intent I and produces G_proposed; after Compiler.static admission, G_candidate is a fully enumerated candidate graph within G_legal. All candidate nodes are instantiated up to c_candidate maxima. Each activates edge carries a typed activation condition φ — a predicate evaluated at runtime to determine whether the candidate node enters G_active(r).

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

field_path  ::= node_id "." "outputs" "." attr_name ("." attr_name)*
typed_atom  ::= field_path : T  op  constant : T            -- types must match
count_agg   ::= "count" "(" field_path op constant ")" op nat
                                                            -- bounded aggregation
                                                            -- over single typed array field
φ           ::= typed_atom | count_agg | φ∧φ | φ∨φ | ¬φ
op          ::= ≥ | ≤ | = | > | <

Φ is total, pure, side-effect-free, strictly typed, and bounded-aggregation-extended. No LLM calls. No external state. No clock. No randomness. Every expression in Φ is decidable and terminating. The bounded count_agg form addresses the v5_2 expressiveness limitation: realistic activation conditions such as “at least 3 personas share this pain” are expressible as count(personas[*].pain_id = current_pain.id) ≥ 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_active(r) because field values differ. P-TI still holds — G_approved topology is unchanged. P-CRE-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 (v7.1 C9 — corrected to match NBM4 schema). PainPriorities → FeatureSet edges carry current_pain_priorities.outputs.maxPriorityScore ≥ 15 — where maxPriorityScore is a scalar derived field on PainPriorities whose value is max(priorityItems[*].priorityScore), computed by the source node and exposed as a typed scalar output. This is a valid typed_atom. Alternatively, the bounded-aggregation form count(current_pain_priorities.outputs.priorityItems[*].priorityScore ≥ 15) ≥ 1 expresses “at least one item exceeds the threshold” directly. Both forms are valid Φ expressions; the scalar-derived form is simpler to compile-check, the aggregation form is more direct. “The AI should assess whether this pain warrants a feature” is not a valid Φ expression and is rejected at compile time.

In plain terms — every branch decision in the plan — “build a feature for this pain only if its priority score clears 15” — must be written as a formula a machine can check, against named data fields with declared types. What is banned is exactly the thing that feels most natural: “let the AI judge whether this pain matters.” That judgment is welcome earlier, when the AI computes the score and you review it — but the go/no-go switch itself must be a formula, so that six months later you can point at the recorded data and say precisely why a branch ran or did not.

3.7 Activation Context K and Three Operational Modes

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

Mode B is the realistic default operating mode and the abstract states this explicitly. P-CRE-A is the strict-determinism mode; P-CRE-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 so that replay reads from the exact bound activation context.

In plain terms — think flight recorder. Mode A: all branch-deciding data is fixed before takeoff (strictest, for audit-grade work). Mode B — the everyday default: data is computed in flight but every value is recorded, so the run can be replayed later and provably takes the same branches. Mode C: nothing recorded; honest about being unreproducible, and therefore not for governed work. The paper never claims the AI writes identical prose twice — it claims the route through the plan is reproducible when the recorder is on.

3.8 Layer 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.
• Sceptic — challenges thresholds, identifies missing nodes, questions cardinality choices, flags boundary cases, identifies where domain methodology 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. High confidence — plan is sound.
• Trial: Proceeds to HITL with flag — moderate confidence, specific concerns attached.
• Watch: Proceeds to HITL with flag — low confidence, PM should scrutinise 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 requirement (introduced v6; clarified v7.1 C8). 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 ≥ 2 distinct model families (e.g., Anthropic + OpenAI + Google) and ≥ 2 distinct prompt families. σ pins the triage policy (the diversity requirement itself — minimum-family counts, allowed role assignments, panel-validity rules); β carries the actual panel configuration of a specific triage run (which models in which roles, with what prompt versions). This was inconsistent in v6/v7 prose (which said “panel configuration is attested in σ”); v7.1 separates them: schema pin (σ) holds the rule; triage record (β) holds the instance. The Compiler validates that the β.panel_config in a given commit satisfies the σ.triage_policy. A measurable triage-quality metric — inter-model agreement on Reject verdicts — is recommended as a runtime indicator of panel calibration.

What adversarial triage claims. Triage is a confidence filter, not a graph-theoretic guarantee. It does not formally close a gap in G_legal. Its contribution is epistemic: it reduces the probability that a structurally valid but semantically unsound G_candidate reaches human approval. This is an engineering property stated as such — not overclaimed as a mathematical one.

In plain terms — before a plan reaches your desk, AIs from at least two different vendors formally argue about it — one defends it, one attacks it, one rules. You receive the plan with the argument attached: the verdict, and the specific objections (“Pain #3 barely misses your threshold — look at it”). Requiring different vendors is the anti-rubber-stamp rule: three copies of the same model tend to share the same blind spots. And a hard rule: a plan the panel rejects outright goes back to the drawing board — it never reaches you wearing a “ready” badge.

3.9 Layer 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 Compiler error — enforced structurally, not by policy convention.

The PM reviews G_candidate in full: all candidate nodes (type, stage, activation condition), SKIPPED candidates and their scores, adversarial triage verdict β and attached concerns, proposed G_approved topology. PM approves, adjusts within c_candidate bounds, or rejects triggering re-planning.

Material edit taxonomy (introduced in v6). The v5_2 contradiction between “material edits trigger re-triage” (§3.7) and the PM example (§3.9 threshold-override-without-retriage) is resolved with 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 β (v7.1 C7). The PM declares safe_ranges in the triage_packet before the four-role panel evaluates G_candidate; the panel’s verdict β includes the safe_ranges field; β is signed into h_pre via the standard α/γ chain. The PM cannot retroactively widen a safe range to legitimise a post-triage edit — the safe_ranges value committed at triage is the only legitimate authority for in-range edits. Threshold adjustments inside the panel-reviewed range during HITL are non-material; adjustments outside the panel-reviewed range are material and re-trigger triage with a new safe_ranges declaration. Earlier drafts (v7) implied PMs could “declare safe ranges in advance” without binding the declaration to β; v7.1 makes the binding explicit so the taxonomy is not gameable.

triage_packet (signed input to four-role panel):
  g_candidate_hash:  sha256_canonical
  safe_ranges:       { predicate_id → [min, max] }   # declared before panel review
  ...

β (signed verdict, includes safe_ranges):
  verdict, concerns, panel_config, ...
  g_candidate_hash:  must match triage_packet.g_candidate_hash
  safe_ranges:       must match triage_packet.safe_ranges (panel reviewed these ranges)
  panel_signatures:  m≥2 over canonical(β)

α signs h_pre which includes β; γ signs (h_pre || α).
The safe_ranges field is therefore bound under both human and Compiler attestation.

Approval record α. α is a cryptographic signature over the pre-commit hash h_pre = hash(V, E_exec, E_audit, λ, ρ, κ, β, σ, μ). h_pre excludes α and γ, resolving the v5_2 hash-circularity defect. After α is appended, the Compiler signs the result to produce γ (see §3.10), and id(C) = hash(h_pre, α, γ).

What HITL claims. For a specific G_approved, this PM at this moment ratified this topology. This is the strongest governance guarantee DOGDD 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.

In plain terms — your sign-off is not a Slack ping you can miss — without your signature the executable work order cannot be manufactured. You review the whole plan (including what will be skipped and why, and what the sceptic AI objected to), you tweak what you own, you sign. The edit rules stop the classic gaming move: you may adjust a threshold inside the band the red-team panel already reviewed, but restructure the plan — or step outside the reviewed band — and it must go back through review. And you cannot widen the band after the fact to make an edit look pre-approved: the band was sealed into the reviewed record.

3.10 The Governed Graph Commit

The GGC is defined at two precision levels:

Minimal model (used in proofs):
C_min = (V, E, λ, ρ, α, σ, μ)

Implementation model (used in §5 NBM4 case study and §3.11 handoff):
C_plus = (V, E_exec, E_audit, λ, ρ, κ, β, α, γ, σ, μ)

Field definitions:
  V        = node set of G_approved
  E        = E_exec ∪ E_audit  (in C_min, partition is implicit)
  E_exec   = execution edges {requires, activates, derives_from} — scheduler-visible (C1)
  E_audit  = traceability edges {evidence_for} — audit-only (C1)
  λ        = node and edge type labelling (artifact_type, stage, edge_semantic)
  ρ        = E_exec → Φ ∪ {⊤}; ρ(e) ∈ Φ iff λ_E(e) = activates; ρ(e) = ⊤ iff λ_E(e) = requires
  κ        = E_exec → ℝ  (planner confidence scores per edge)
  β        = triage record (verdict, concerns, panel_config, G_candidate_hash)
  α        = human approval; α = Sign_user(h_pre) where h_pre = hash(V, E_exec, E_audit, λ, ρ, κ, β, σ, μ)
  γ        = Compiler attestation; γ = Sign_compiler(h_pre || α)
  σ        = content_hash(Σ_text || cardinality_table || L_table || Φ_grammar_version)
  μ        = vector of content hashes pinning (planner_model, triage_models, compiler_binary, executor_binary, tool_versions, prompt_template_hashes)

Commit identity (precise formulation, v7.1 C4). Define:

C_payload  = canonical_json({V, E_exec, E_audit, λ, ρ, κ, β, σ, μ})
h_pre      = H(C_payload)
α          = Sign_user(h_pre)
γ          = Sign_compiler(H(C_payload || α))
id(C)      = H(C_payload || α || γ)

where canonical_json is a deterministic canonicalisation (the ship-mlp reference implementation uses RFC 8785 JSON Canonicalization Scheme; the framework requires any deterministic canonicalisation), H is a collision-resistant cryptographic hash (SHA-256 or stronger), and || denotes canonical concatenation of byte sequences. h_pre excludes α and γ by construction; α signs h_pre; γ signs the canonical form of (C_payload || α). No hash circularity.

Executor verification (v7.1 C4). On load of a transit object (id(C), C_payload, α, γ), the Executor verifies:

H(canonical(C_payload || α || γ)) == id(C)         # tamper detection
H(C_payload || α) == verify(γ, compiler_pubkey)    # compiler attestation
H(C_payload) == verify(α, approver_pubkey)         # human attestation

If any verification fails, the GGC is rejected and no adjacency table is constructed. Earlier drafts informally stated hash(C_content) == id(C); v7.1 makes the canonical-form chain explicit so that C_content, C_payload, h_pre, and the (C_payload || α || γ) concatenation are not conflated.

Compiler attestation γ (introduced in v6). γ is a Compiler signature distinct from human approval α. γ proves the Compiler — operating from a trusted binary with key custody in a separate trust anchor — produced this commit through the full epistemic chain. The Executor verifies γ before α. A compromised human key allows forged α; the Compiler attestation γ ensures the forging path still requires Compiler key compromise (a separable trust event with separate detection and mitigation).

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 distributed via a Σ-versioned trust manifest.
• A compromised human signer allows forged α but does not produce a γ-valid GGC unless the Compiler key is also compromised.
• 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 an optional extension; the architecture supports them via α being a signed set rather than a single signature.
• See §8.2 for the threat-model limitations explicitly listed as future-work hardening; see §7.7.4 for the reference implementation’s current named deviation on key custody.

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

1. Receives id(C) and C_content
2. Verifies hash(C_content) == id(C) — tamper detection
3. Verifies γ against the Compiler trust anchor — Compiler attestation
4. Verifies α against the approver identity declared in σ — human attribution
5. Constructs an immutable adjacency table from verified (V, E_exec)
6. Exposes zero graph-mutation APIs — no create_node, no create_edge, no modify_topology
7. Requires every tool call to reference an existing node ID from V — unknown IDs are rejected and logged as violations
8. Planner and Compiler credentials are unavailable to the Executor — it cannot invoke planning or recompile
9. E_audit is written to the audit log but does not affect 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 schema version σ. 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.

In plain terms — the GGC is the signed work order, and its ID is a fingerprint of everything inside it — the plan, your signature, the red-team verdict, even the exact AI model versions in use at signing time. Change one comma anywhere and the fingerprint changes; the runner notices before doing anything. Two separate stamps matter: yours (you approved this plan) and the gatekeeper’s (this plan actually went through the checks). Forging an order requires stealing both keys, held in different places. And a planner that keeps producing illegal drafts does not get to spin forever — after three strikes, a human must step in.

3.11 The Layer 3 → Layer 2 Handoff: down(C) → SpecSeed

DOGDD’s contribution at L3 is complete only if the L3 hypothesis can be transformed into a L2 specification seed with traceability. We define this transformation explicitly in main text, not as future work.

Definition (Layer-3-to-Layer-2 handoff). Let C be a GGC, τ_r be an execution trace, and selection ⊆ V_active(r) be a selected set of executed hypothesis nodes (e.g., the four Features approved for downstream implementation). The handoff down(C, τ_r, selection) → SpecSeed produces:

SpecSeed = { (req_i, trace_i) :
               req_i is a Layer-2 requirement derived from a node v ∈ selection
               trace_i = { ggc_id: id(C),
                           source_node: v_id,
                           source_field: v.outputs.<name>,
                           approval: α_id_of(α),
                           sigma_pin: σ } }

Every Layer-2 requirement in a SpecSeed carries a trace link to the exact L3 hypothesis node that sourced it, the GGC that ratified it, and the human who signed that ratification. A SpecSeed feeds an SDD pipeline (Piskala 2026; Spec Kit) at Layer 2; the SDD spec then feeds Layer 1 TDD code conformance guards. Each layer transition preserves traceability.

What down() does not do. down() does not infer requirements the L3 hypothesis did not declare. It transforms declared hypothesis outputs into typed L2 spec seeds; it does not invent. A SpecSeed that contains requirements unsupported by trace links is a violation of the handoff contract.

Why this is load-bearing. The four-layer epistemic model (§2.4) is rhetoric without a defined handoff. With down() defined in main text, the L3 → L2 boundary becomes operational: a reviewer can verify trace links between a SpecSeed requirement and its source hypothesis node. Without it, the layer model is unfalsifiable claim. We make the claim falsifiable here. (Implementation status: the reference implementation has not yet implemented down(); this is named deviation OQ-05/G-12 in §7.7.4.)

In plain terms — when the governed product bets are ratified and the winners are selected, they hand off downward into engineering specs — and every spec line carries a receipt: which hypothesis it came from, which signed plan ratified it, who signed. Six months later, when someone asks “why does this feature exist?”, the answer is a click, not an archaeology dig. (Honest status note: this handoff is fully specified here but is the one major piece the reference implementation has not built yet.)

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. DOGDD handles this through an append-only attested commit DAG.

Lifecycle states

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

Signed attestation chain (introduced in v6). Every lifecycle state transition is itself a signed attested record chained to id(C):

transition_record = Sign_user(hash(prev_state, new_state, evidence_bundle_hash, timestamp, transition_actor_id))

Lifecycle is therefore not a mutable claim attached to an immutable artifact — it is an append-only signed event log keyed by id(C), with each transition cryptographically chained to the prior state. The state-transition registry is a content-addressed append-only structure, queryable but not mutable. Supersession C → C′ carries a signed evidence bundle hash and supersedes: id(C) in C′.

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(C)). Evidence classification is human-attributed or AI-with-HITL; the classifier_id is recorded.

Executor enforcement. The Executor checks the lifecycle state of a GGC before running. It refuses to execute INVALIDATED or SUPERSEDED GGCs unless an explicit override is provided — and overrides are themselves attested records added to the lifecycle chain.

In plain terms — a signed plan is never edited; it accumulates a logbook. Market evidence arrives and is filed as a classified entry: this confirms the bet, weakens it, kills it, or replaces it with a successor plan (which points back at what it replaced). Each logbook entry is signed and chained to the previous one, so entries cannot be reordered or quietly rewritten — and the runner refuses to execute a plan whose logbook says “invalidated,” unless someone signs an explicit, recorded override. Your product history stops being tribal memory and becomes an institution.

3.13 Schema Governance — DOGDD Applied to Σ Itself

DOGDD’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-DOGDD pipeline: the proposed Σ revision is reviewed by a triage panel for methodology coherence; PMs and methodology stewards ratify it via HITL; a Σ-Compiler validates structural well-formedness (totality of f, finiteness of A and S, consistency of c and L tables); the result is a signed Σ-commit pinning a content-hash referenced by σ in downstream GGCs.

Recursion bottom. The Σ-meta-DOGDD pipeline is itself governed by a fixed bootstrap Σ_meta — a small, hand-authored, immutable methodology schema that defines what a valid Σ is. Σ_meta is not itself governed by DOGDD; it is the bootstrap trust anchor. This is the standard recursion-termination pattern for self-bootstrapping governance systems (cf. trusting-trust, SLSA framework, sigstore root keys).

Σ revision propagation. When Σ revises, GGCs pinning the old σ 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.

In plain terms — who guards the rulebook? If your encoded methodology is wrong, everything downstream is confidently wrong. So changing the rulebook goes through the same discipline as changing a plan: proposed revision, red-team review, human ratification, sealed new version. Old signed plans stay valid under the rulebook they were signed under — no retroactive reinterpretation. The recursion stops at a small, hand-written constitution that defines what a valid rulebook is. (The reference implementation runs this pipeline mechanically: unsanctioned rulebook revisions are rejected with a typed error — §7.7.2.)

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

This section presents formal propositions and proof sketches. Full mechanised proofs are deferred to a companion technical report. Throughout this section we use the minimal model C_min = (V, E, λ, ρ, α, σ, μ); the implementation model C_plus adds E_exec/E_audit partition, κ, β, and γ without affecting any proof below.

In plain terms — this section is the paper’s legal fine print: exactly what is promised, under exactly which assumptions, with sketch-level proofs. If you are a product reader, the one-line versions are: the space of legal plans is finite, not infinite (P-BLS); a signed plan cannot change shape while running (P-TI); with the flight recorder on, a run takes the same branches on replay (P-CRE); the gatekeeper only admits plans passing all thirteen named checks (P-COMP); every run traces back to exactly one signed plan and one signing human (P-AUD); and any tampering changes the plan’s fingerprint (P-IMM). The Greek below makes those promises falsifiable rather than rhetorical.

4.1 Notation

4.2 P-BLS — Bounded Legal Topology Space

Proposition P-BLS. Under finite artifact types, finite stages, finite per-type instance bounds B(a), finite relationship cardinality maxima, finite field-level scope bounds L, and stage-forward edge constraints, the number of distinct legal typed topologies |G_legal(Σ)| is finite.

Proof sketch. By induction over stages s₁ < s₂ < … < sₙ:

• Base case. At s₁, the number of legal root node configurations is at most ∏_{a: f(a)=s₁} (B(a) + 1) — finite by assumption.
• Inductive step. Given a finite set of legal configurations up to stage sᵢ, each node of type a at sᵢ may produce at most max(c(R)) children of each type at sᵢ₊₁. The total node count at sᵢ₊₁ is bounded by B(a′) for each a′ ∈ Aᵢ₊₁ — finite by assumption. The edge count between any two stages is bounded by B(a) × max(c(R)) — finite. Field-level content bounds L cap the per-field semantic space but do not enlarge topology space; |G_legal| (counted as typed topologies) is unaffected by L. The number of valid topological configurations at sᵢ₊₁ is bounded by the product of node and edge counts — finite.
• Conclusion. By induction across n stages, |G_legal(Σ)| < ∞. ∎

Assumptions required. (i) |A| < ∞; (ii) |S| < ∞; (iii) B(a) < ∞ for all a ∈ A; (iv) max(c(R)) < ∞ for all R; (v) no dynamically typed nodes at runtime; (vi) no unbounded disconnected node generation (reachability from root set required).

Reachability and uniqueness conditions (v6, per P-COMP-vii/viii). P-BLS is stated over topologies satisfying: every v ∈ V reachable from the declared root set via E_exec ∪ E_audit; node identifiers unique within V. These are P-COMP step 7 and step 8 conditions; they are necessary for finiteness because disconnected node addition could otherwise extend an admitted topology indefinitely.

What P-BLS does not claim. P-BLS does not claim that the same intent produces the same candidate graph. The Planner is LLM-driven; G_candidate may vary across runs. P-BLS claims only that every G_candidate ∈ G_legal(Σ), and |G_legal(Σ)| < ∞ under finite Σ.

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

Property P-TI. For a fixed GGC C consumed by a graph-closed Executor, every execution run r preserves V and E_exec exactly. No node is added to V; no edge is added to E_exec.

This is a property, not a novel theorem. It follows by construction from the Executor’s definition: the Executor API exposes no create_node or create_edge operation; it constructs an immutable adjacency table from verified C content on load; all tool calls must reference existing node IDs ∈ V. The property holds trivially if the Executor implementation is correct. The engineering contribution is the enforcement chain that ensures only Compiler-attested, human-ratified GGCs reach the Executor at all — not the runtime invariance itself.

Assumptions required. (i) Executor is graph-closed by construction; (ii) γ and α are verified on load against trusted keys; (iii) tool calls are scoped to existing node IDs in V; (iv) Planner and Compiler credentials are unavailable to Executor at runtime; (v) Compiler trust anchor is uncompromised.

4.4 P-CRE — Commit-Replay Equivalence (Two Sub-Propositions; v7.1 C2 restates over G_eligible)

Note on G_eligible vs G_executed (v7.1 C2). Earlier drafts stated P-CRE over G_active — a term that conflated two distinct objects. v7.1 splits this into G_eligible(r) (the predicate-induced subgraph, a function of K alone) and G_executed(r) (the subgraph of eligible nodes that actually reached COMPLETED status). P-CRE-A/B claim repeatability of G_eligible — the K-determined partition. Whether eligible nodes actually complete depends on transient failures, timeouts, and worker reliability, which are separable runtime concerns outside the scope of replay equivalence. A node that is eligible in two runs but fails in one is a reliability event, not a replay-equivalence violation. Reliability properties are identified as future work (P-REL, §8.3).

Proposition P-CRE-A (Strict Eligibility Replay Equivalence). Let C be a valid GGC and K be pre-committed in C — every field referenced by predicates in ρ has its value committed inside C before execution. If all predicates in ρ are members of Φ (total, pure, side-effect-free), then for any two runs r₁, r₂ of Executor(C, K):

G_eligible(r₁) = G_eligible(r₂)

Proof sketch. Since K is committed and identical across runs, and all φ ∈ Φ are pure functions of their input fields, eval(φ, K) is identical across runs. G_eligible(r) is determined entirely by the edge-eligibility set {e ∈ E_exec : λ_E(e) ∈ {requires, derives_from}} ∪ {e ∈ E_exec : λ_E(e) = activates ∧ eval(ρ(e), K) = true} followed by reachability from the root set; this set is identical across runs under identical K. ∎

Proposition P-CRE-B (Practical Eligibility Replay Equivalence). Let C be a valid GGC and K_log be a content-addressed replay log of activation field values produced during a prior execution of C. For any replay run r_replay reading activation values from K_log:

G_eligible(r_replay) = G_eligible(r_original)

Proof sketch. Mode B replay reads activation values from K_log rather than recomputing them. Since K_log is content-addressed and read-only, K_replay = K_original. By the same argument as P-CRE-A, eval(φ, K) is identical, and 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. P-TI 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) is total over all fields referenced by ρ; (ii) all φ ∈ Φ; (iii) Executor predicate evaluation is deterministic over its input; (iv) no clock, randomness, or external state inside predicates.

What P-CRE does not claim. P-CRE 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-CRE claims only that the eligible subgraph induced by K is repeatable.

4.5 P-COMP — Compiler Admissibility

Proposition P-COMP. A sound DOGDD Compiler accepts G_approved and produces GGC C only if G_approved satisfies all of the following:

1. All node types λ(v) ∈ A
2. All stage assignments f(λ(v)) valid
3. All inter-stage edges stage-forward: f(λ(u)) < f(λ(v)) for (u,v) ∈ E_exec
4. All intra-stage edges in E_exec are requires or derives_from and form a DAG under secondary topological sort within each stage
5. All edge multiplicities within c_candidate(R) bounds on both outgoing and incoming sides
6. All activates edges carry φ ∈ Φ, well-typed against source node output schema; predicate scope restricted to immediate source-node fields (Option A)
7. Every v ∈ V reachable from the declared root set via E_exec ∪ E_audit
8. Node identifiers unique within V
9. All field outputs satisfy field-level scope bounds L
10. HITL approval record α is present, cryptographically valid, signature references h_pre = hash(V, E_exec, E_audit, λ, ρ, κ, β, σ, μ)
11. Triage record β is present, references G_candidate hash, verdict ∈ {Adopt, Trial, Watch}, panel_config satisfies triage diversity requirement (≥2 model families, ≥2 prompt families)
12. Σ is pinned by σ as content-hash of (Σ_text || cardinality_table || L_table || Φ_grammar_version)
13. After all checks pass, Compiler produces γ = Sign_compiler(h_pre || α); id(C) = hash(h_pre, α, γ)

Completeness note. P-COMP proves that accepted GGCs satisfy all structural constraints. It does not prove semantic correctness, strategic soundness, or market validity of the committed 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.6 P-EDGE — Edge Semantic Biconditional

Proposition P-EDGE. For every committed edge e ∈ E_exec:

ρ(e) ∈ Φ  ⟺  λ_E(e) = activates
ρ(e) = ⊤  ⟺  λ_E(e) = requires

Proof. Enforced by P-COMP step 6. The Compiler rejects any activates edge without φ ∈ Φ, and any requires edge with φ. ∎

4.7 T4a, T4b — Acyclicity and M:N Boundedness

T4a (Inter-stage Acyclicity). If all inter-stage edges satisfy f(λ(u)) < f(λ(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 acyclicity is separately guaranteed by P-COMP step 4 (secondary topological sort). Global acyclicity = T4a + P-COMP step 4.

T4b (M:N Boundedness — tightened in v6). For any relationship R: aᵢ → aⱼ with cardinality c(R) = (min_out, max_out, min_in, max_in), the total number of edges across the relationship in any G_legal is bounded by:

|E(R)| ≤ min(max_out · B(aᵢ), max_in · B(aⱼ))

Proof. There are at most B(aᵢ) source nodes; each may have at most max_out outgoing edges of type R. There are at most B(aⱼ) target nodes; each may have at most max_in incoming edges of type R. Total edges are bounded by both — 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 (v7.1 C6 tightening). For every execution trace τ_r produced by Executor(C) with run identifier r, there exists exactly one C such that:

• the structural projection of τ_r is contained in (V, E_exec, ρ) of C
• α attests human ratification of that exact topology
• γ attests Compiler-mediated production
• σ pins the schema; μ pins the model/tool versions; K_log (Mode B) pins the activation context
• Any lifecycle transition affecting C is signed and chained to id(C)

Required trace-event content (v7.1 C6). 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
  executor_id:    executor_pubkey_hash,   # which Executor instance produced the event
  gamma_ref:      H(γ),                   # Compiler attestation reference
  event_seq:      monotonic integer,      # event ordering within run
  event_type:     enum {NODE_ELIGIBLE, NODE_EXECUTED, NODE_SKIPPED, NODE_FAILED, ...},
  node_id:        v ∈ V (when applicable),
  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 — the uniqueness claim collapses. With these fields, each event is unambiguously anchored.

Assumptions required. Logs retained and append-only; identifiers stable; signatures verifiable against trust manifest; evidence references retrievable; K_log content-addressed; every event carries the required identity fields above.

4.9 P-IMM — Commit Immutability

Proposition P-IMM. id(C) = hash(h_pre, α, γ) is collision-resistant under standard cryptographic assumptions. Any modification to any field in C produces id(C′) ≠ id(C). Lifecycle state changes do not modify C — they append signed transition records keyed by id(C).

Proof. Standard cryptographic hash collision resistance (SHA-256 or equivalent). Immutability of C is enforced by content-addressing and the append-only lifecycle registry. ∎

4.10 P-SEP — Layer Separation (Informal)

Proposition P-SEP. Layer 3 governance constraints (DOGDD) do not imply Layer 2 correctness properties unless the down(C) → SpecSeed transform (§3.11) is applied. Conversely, Layer 2 correctness (SDD) does not imply Layer 3 hypothesis soundness. The handoffs down(C) → SpecSeed → SDD spec → TDD code conformance preserve traceability across layers but do not collapse layer-distinctness.

This is stated informally as a layer-discipline property; formal mechanisation is future work.

5. Domain Instantiation: DOGDD-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 DOGDD; (ii) it exhibits the full range of governance challenges — multi-stage artifact dependencies, M:N relationships between pains and features, human judgment requirements at every material fork, and irreducible market uncertainty; (iii) it has a rich, documented methodology (NBM4 — Kozloff 2021) with formal artifact schemas available for direct instantiation.

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

NBM4 self-citation disclosure. NBM4 is authored by the present author (Kozloff, 2021). Its use here is as a domain instantiation vehicle, not as proof of product-management truth. The cardinality values in §5.4 are illustrative defaults for the NBM4 instantiation, calibrated by the author’s practice; domain practitioners adopting DOGDD should derive bounds from their own methodology documentation.

5.2 NBM4 Stage Set

Note — pending v070 stage compression. The 6-stage model below describes NBM4 v065, the schema this paper’s instantiation references. NBM4 v070 compresses the stage set from six to four (Idea / Customer / Product / Growth) per RFC-0125 v0.3.0. None of DOGDD’s formal properties depend on the stage count — P-BLS, P-TI, P-CRE, P-COMP, P-EDGE, T4a, and T4b all hold for any finite totally ordered stage set. A future revision will retarget §5 to the v070 schema; the 6-stage instantiation below remains a valid proof-of-concept until then.

NBM4 v065 defines six ordered stages:

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

5.3 NBM4 Artifact Type Universe

(See v5_2 Appendix B and §5.3 — preserved unchanged in v6. The 24 artifact types across the active stages remain the reference instantiation.)

5.4 Key Relationship Cardinalities

The PainPriorities → Feature relationship is the primary activates edge. Its activation predicate uses either form (v7.1 C9): the scalar-derived form current_pain_priorities.outputs.maxPriorityScore ≥ 15 where maxPriorityScore is a scalar field exposed by PainPriorities computed as max(priorityItems[*].priorityScore), or the bounded-aggregation form count(current_pain_priorities.outputs.priorityItems[*].priorityScore ≥ 15) ≥ 1. The array-indexed form priorityItems[*].priorityScore ≥ 15 is not valid as a typed_atom and would be rejected by the Compiler — it must be expressed via a scalar-derived field or the count_agg form.

5.5 Field-Level Scope Bounds L (sample)

Field-level scope bounds for selected artifact types:

A PersonaProfile node whose description exceeds 2000 characters is rejected at compile time even if the topology is otherwise legal. A FeatureSet node whose features array contains 14 entries is rejected even if c_candidate(PainPriorities → Feature) permits ≤ 12 — field-level L enforces semantic scope within each node in addition to topology-level cardinality.

5.6 PM Example: The Governed Voyage

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

Layer 1 — Schema. Node types constrained to Stage 2 and Stage 3 artifact types. AI cannot generate FeatureSet nodes before PainPriorities — schema rejects it. A PersonaProfile.description longer than 2000 chars is rejected even if topology is otherwise legal.

Layer 2 — Cardinality. c_candidate bounds — up to 3 Personas, up to 12 Pains per Persona, up to 12 Features total. Each Pain connects to at most 3 Features; each Feature references at most 4 Pains.

Layer 3 — Scored Edges. Planner produces G_proposed: 2 Personas, 8 Pains, 12 candidate Feature nodes. Compiler.static admits G_proposed to G_candidate after schema, cardinality, and L checks. Each Feature edge carries current_pain_priorities.outputs.maxPriorityScore ≥ 15 (v7.1 C9 — scalar-derived form). All φ validated as Φ-members. 9 candidates score below threshold — proposed SKIPPED. 3 score above — proposed active.

Layer 4 — Triage. Panel: Claude 4.7 (Advocate), GPT-5.5 (Sceptic), Gemini 3.1 (Judge) — three model families, three prompt families, satisfies diversity requirement. Sceptic flags Pain #3 at priority_score 14.6. Judge: Watch. β attached to G_candidate.

Layer 5 — HITL. PM reviews. PM declares threshold safe-range [13, 17] in advance. PM adjusts threshold to 14.0 for Pain #3 — within safe range, classified as predicate-value edit (non-material), no re-triage. G_approved: 4 active Features, 8 SKIPPED. PM signs α over h_pre.

Compiler.full. Validates all P-COMP conditions including reachability and unique IDs. Computes γ over (h_pre, α). Emits C with id(C) = hash(h_pre, α, γ).

Execution. Executor verifies γ, then α, then constructs immutable adjacency table. Evaluates φ per edge using K_r (Mode B — values logged to K_log). 4 Features activate. 8 SKIPPED. G_approved topology preserved exactly. LLM content in each Feature node may differ across runs (Mode B traversal repeatable under replay from K_log; content not claimed repeatable).

Downstream handoff. down(C, τ_r, selection={4 active Features}) produces SpecSeed with trace links from each Layer-2 requirement to its source Feature node, the GGC id, the PM signature, and σ. SDD pipeline consumes SpecSeed.

Outcome. Not a guaranteed successful product. A structurally sound, domain-constrained, adversarially reviewed, PM-ratified, Compiler-attested execution record. If the product fails because the market shifted, the GGC plus the attested lifecycle chain tells you exactly what was decided, why, by whom, and what evidence subsequently confirmed/weakened/invalidated it. The next voyage starts from a better position.

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

In plain terms — read §5.6 as a day in the life: you ask for “top features from pain discovery”; the AI drafts personas, pains, and twelve candidate features; the gatekeeper checks order, counts, and sizes; a three-vendor AI panel argues and flags the borderline pain; you nudge one threshold inside the pre-agreed band, sign, and the locked plan runs — recording which features activated, which were skipped, and why. Nothing here promises the product succeeds. It promises that if it fails, you will know exactly what was decided, by whom, on what evidence — and your next cycle inherits that knowledge instead of folklore.

6. Layer Composition and Gap Closure

(See v5_2 §6 for the ablation analysis; preserved with these v6 additions.)

DOGDD closes five structural gaps (G1–G5) that an ungoverned AI execution system exhibits:

All five gaps are only simultaneously closed when all five layers are present. Removing any layer reopens a recoverable gap (ablation analysis preserved from v5_2 §6.3). The composition argument is necessity, not novelty in any individual layer.

In plain terms — why five layers and not two? Because each closes a different hole: drop the schema and the AI invents artifact types; drop cardinality and it invents quantities; drop the formula language and branching goes back to vibes; drop the red team and you review unchallenged plans; drop the mandatory signature and execution stops being a human decision. The layers are a set menu, not a buffet.

7. Adversarial Validation Methodology and Implementation Evidence

Sections 7.1–7.6 present the validation design carried from v7.1. Section 7.7 (NEW in v8) reports the first completed implementation-conformance evidence block. Empirical hypotheses H1–H6 remain future work; no empirical outcome results are reported.

7.1 Claims Supportable by Formal Proof

7.2 Claims Requiring Implementation Demonstration

(v8 update: the Status column is new. “Demonstrated (check-API)” means the claim is mechanically asserted in the ship-mlp reference implementation’s conformance suite at the check-API layer described in §7.7, with a typed rejection code and a fail-closed test. The scope qualifier and named deviations in §7.7.4 apply to every row.)

7.3 Claims Requiring Empirical / User-Study Evidence

(See v5_2 §7.3; preserved. Additional hypothesis-marker: every outcome-language claim in the paper is marked as H_n where empirical evidence is required.)

Every empirical claim in this paper carries an explicit H_n marker. Outcome-shaped language (“better/faster”) in motivation framing is not a claim; H1–H6 are the falsifiable claims that bear empirical weight. v8 note: §7.7’s conformance evidence discharges none of H1–H6; it demonstrates that the mechanisms those studies presuppose now exist and reject what they must reject.

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. DOGDD Layer 1 only (ablation)
7. DOGDD Layers 1+2 (ablation)
8. DOGDD Layers 1+2+3 (ablation)
9. DOGDD Layers 1+2+3+4 (ablation)
10. Full DOGDD (all five layers + γ + L + lifecycle chain + down())

7.5 Adversarial Planner Test Cases

(See v5_2 §7.5; preserved with v6 additions. v8 status: every row below is mechanically asserted in the reference implementation’s paper-indexed conformance suite via a dual-index mapping — paper attack id ↔ suite row id — with a named typed rejection code per row; see §7.7.2.)

7.6 What Evidence Would Falsify DOGDD

(See v5_2 §7.6; preserved with v6 additions.)

DOGDD’s core claims are falsified if:

• Any TC-1 through TC-19 passes the Compiler or Executor
• Mode A or Mode B replay produces different G_active under identical C and K (or K_log)
• A legal GGC id(C) can be forged without both α and γ from trusted keys
• The seven-axis substance grid (§2.3) is shown to be populated by a single prior system

v8 note. The first falsifier is now continuously exercised rather than hypothetical: the reference implementation’s conformance suite executes the TC-1–TC-19 rejections (and the TC-20 warning) as fail-closed tests on every run, so a regression that lets any TC pass is a build failure, not a discovered embarrassment.

7.7 Reference-Implementation Conformance Evidence (NEW in v8)

This section reports implementation-conformance evidence, not empirical outcome evidence. It answers one question: does a real system exist whose compiler, executor, and evidence surfaces mechanically enforce what Sections 3–4 specify and reject what Section 7.5 attacks? The answer is yes, within an explicitly declared scope.

In plain terms — everything before this point says what the machinery should do. This section reports that the machinery has now been built and break-tested: all twenty attack scenarios from the table above run as automated tests against real code, each proving the system rejects the attack with a named error. Equally important: the system polices its own marketing. A machine-readable ledger records what is and is not proven, and an automated gate blocks release wording that overclaims. The three honest gaps that remain are listed below in §7.7.4 — by name, not in a footnote.

7.7.1 Evidence provenance

The evidence base is the ship-mlp reference implementation (Appendix D), which since v7.1 has landed a two-stage conformance programme under its own RFC governance: an alpha stage (RFC-0220 §10, landed 2026-07-01, test-first) establishing the content-addressed GovernedGraphCommit schema, the compile.check admission API, the graph-closed execute.check admission API, a pilot compiler-skill package, and an initial paper-ID test suite; and a full-conformance stage (RFC-0235, sprint closed 2026-07-05) extending those surfaces to the complete field binding, the complete typed reject sets, and the all-asserted TC suite. Both stages were executed under ship-mlp’s own governance discipline — intent gates, plan gates, independent multi-model adversarial triage of the RFCs, an architecture-council review with binding conditions, and human-in-the-loop stops resolved by the author — which is itself an instance of the Appendix C DOGDD-RFC pattern operating on the framework’s own evolution.

7.7.2 What is mechanically asserted

The conformance surface comprises, as landed artifacts:

• Full commit binding. The GovernedGraphCommit evidence schema binds the complete C_plus field set — graph (V, E_exec, E_audit), per-node λ with field-level bounds, per-node ρ required-and-typed (pure/total/non-LLM), commit-level κ and β as typed content-hashed subschemas, plus α, γ, σ, μ, route-plan state, authority envelope, and lifecycle/evidence references. Tamper on any bound field — including κ, β, and ρ — changes the commit identity or fails validation (TC-13 hardened).
• Compiler admission (compile.check). Typed, fail-closed rejections for: open-ended plans, malformed graphs, duplicate and disconnected nodes, missing α, non-compiler γ issuers, stale or path-widened authority, unsupported routes, non-pure activation predicates (COMPILE_PHI_NON_PURE for LLM/clock/randomness/external-state sources), unbounded aggregation and non-immediate-predecessor field references without an admissible aggregation edge, field-bound widening (COMPILE_FIELD_BOUND_WIDENING), and contradictory authority.
• Executor admission (execute.check). 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 the ordering guarantee that every admission rejection occurs before runtime adjacency/state construction.
• Replay and lifecycle. Content-addressed K_log build/replay proving identical eligible/active node selection across the declared route set, with replay-claim mode tags rejecting Mode C-as-Mode B claims (TC-20); a hash-linked lifecycle transition chain detecting edit/reorder tamper (TC-19), with typed evidence-bundle classifications (confirms/weakens/invalidates/supersedes), terminal-state execution refusal, and attested-override admission.
• Triage, edits, collapse, and Σ-meta. β diversity enforcement (minimum two model families and two prompt families; single-family panels rejected — TC-16) with safe_ranges bound into β and a σ-pinned triage policy the compiler cross-validates; the three-class material-edit taxonomy with per-class admission predicates and typed out-of-range/unclassified rejections (TC-17/TC-18); governed RuntimeCardinalityCollapse evidence with affected-subgraph halt and commit-referencing supersession request (§3.5.1); and a σ-meta revision pipeline that content-addresses Σ commits and rejects unsanctioned revisions (SIGMA_REVISION_UNSANCTIONED, §3.13).
• The all-asserted TC suite. The paper-ID conformance suite carries exactly one row per TC-1 through TC-20 under a dual-index mapping to the §7.5 attack table (paper attack id and suite row id are separately tracked, so suite drift from the paper’s own falsifier list is itself a detectable failure). All twenty rows are directly asserted; the suite structurally rejects any row regressing to a cited-elsewhere or deferred status. Full trace reconstruction links intent gate, plan gate, route-plan state, compile.check, commit id, execute.check, node-bound effect, evidence references, review gate, and lifecycle state end-to-end, with every trace event carrying the §4.8 identity field set.

7.7.3 The claim boundary is machine-enforced

A distinctive property of this evidence block is that the claim wording itself is governed. The reference implementation maintains a machine-readable conformance ledger recording, per acceptance criterion and per TC mapping, the green/not-green status and the named deviations; and an executable release-claim gate that scans concrete release, grant, and go-to-market artifact surfaces and fails on full-conformance or unqualified “100%” phrasing unless the ledger is green — and blocks unqualified “100%” wording even then. At the time of writing the ledger records all acceptance criteria and all twenty TC mappings green, with overall status deliberately not-green because three named deviations remain open (§7.7.4). This paper’s own wording obeys that boundary: the claims here are scoped claims with named deviations, and the same mechanical gate that governs the implementation’s release artifacts is the reason a stronger sentence does not appear in this section.

7.7.4 Scope qualifier and named deviations

The evidence above is scoped to the check-API layer: the governed validation and admission APIs (compile.check, execute.check), the evidence schemas they enforce, and the conformance suite that exercises them. Three deviations from this paper’s full requirement set are open, named, and recorded in the conformance ledger:

We regard naming these deviations in the same section as the evidence — rather than in an appendix or a footnote — as part of the method: a governance architecture whose own conformance reporting required a mechanical gate to stay honest is making its central argument twice.

In plain terms — three gaps, stated plainly. First: the break-proof machinery exists and passes every test, but the live production pipeline has not yet been rewired to run exclusively through it — that rewiring is the next major project. Second: tamper detection currently works like a sealed ledger (any edit is visible), not like a notarised signature (proof of who sealed it); the stronger version is specified and waits until something actually requires it. Third: the hand-off from ratified product bets to engineering specs is designed but not yet built. Everything else you read in §7.7.2 is running code with passing adversarial tests.

8. Conclusion and Future Work

8.1 Summary

This paper introduced Domain-Ordered Directed Graph Governance (DOGDD) — a five-layer governance architecture parameterised over a domain methodology Σ, whose central claim is enforced production: open-ended AI planning is not executable until transformed into a Governed Graph Commit (GGC) via a domain-bounded, cardinality-constrained, scored, adversarially triaged, human-ratified, compiler-validated pipeline. The architectural distinction from prior work — and the substance of the contribution — is the inversion: most systems achieve topology invariance by removing freedom at execution time; DOGDD achieves it by forcing all freedom to be expressed, bounded, and ratified before execution.

The contribution is the conjunction at the L3 product-hypothesis layer: input shape (AI-planner output), subject domain (typed PM artifacts), constraint origin (domain methodology), HITL semantics (compile-gate, not advisory), closure (executor accepts only Compiler-attested commits), epistemic layer (L3), and audit closure (every traversal maps to ratifying human + schema + models + evidence). No cited system populates five or more of these seven axes (§2.3); reviewers are invited to falsify by name.

DOGDD is parameterised over Σ — NBM4 is the primary reference instantiation; DOGDD-RFC is sketched in Appendix C. The framework’s formal properties (P-BLS, P-TI, P-CRE-A/B, P-COMP, P-EDGE, P-AUD, P-IMM, T4a/T4b) hold for any finite Σ.

New in v8: the validation methodology of Section 7 is no longer entirely prospective. The ship-mlp reference implementation mechanically asserts all twenty §7.5 adversarial test cases with typed rejection codes at the check-API layer, under three named deviations, with the claim boundary itself enforced by a machine-readable ledger and an executable gate (§7.7).

We do not claim deterministic product outcomes. Markets shift. We do not claim deterministic LLM content. We do not claim unique candidate-graph generation from intent. We do not claim full or unqualified conformance of the reference implementation while any named deviation is open — and its own release gate enforces that we cannot. The realistic default operating mode is Mode B (replay-logged K). Proof sketches are provided; mechanised proofs are future work. Empirical validation (H1–H6) is identified as primary future work.

8.2 Limitations

Single concrete domain instantiation. DOGDD is parameterised over Σ; NBM4 is the primary instantiation; DOGDD-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 evidence block demonstrates mechanism conformance, not outcome improvement.

Live-path unification pending (NEW in v8). The reference implementation proves the compiler/executor/evidence contracts at the check-API layer; its live dispatch path is not yet rewired to consume the GGC substrate as its sole execution input. Until the live-path unification RFC closes, “no GGC, no execution” is a demonstrated property of the governed admission surfaces, not yet an end-to-end property of the production path (§7.7.4).

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 Φ from v5_2 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 minting forged GGCs; mitigation requires HSM/TEE custody. A compromised human signing key allows forged α but not γ. Multi-party approval thresholds are supported but not enforced. Schema corruption is mitigated by Σ-meta-DOGDD governance (§3.13) but the bootstrap Σ_meta is a trust anchor. The reference implementation currently realises tamper evidence without asymmetric key custody — a named deviation (§7.7.4), not a silent substitution.

Active cardinality lower bounds are runtime conditions. c_active lower bounds cannot be statically validated by the Compiler in Mode B/C; runtime collapses produce a governed exception via §3.5.1 protocol.

Mode C does not support replay. Runs whose activation values are recomputed via LLM each time forfeit P-CRE-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, field-level L scope-creep study. (v8 update: the adversarial planner test suite TC-1–TC-20, formerly the first item under this priority, is now landed as continuous mechanical assertion in the reference implementation — §7.7; the human-subject and outcome studies remain open.)

Priority 2 — Live-path unification and the reference implementation. Close the §7.7.4 live-path deviation: wire the reference implementation’s live dispatch path to mint commits through compile.check and admit execution only through execute.check, making the check-API evidence the production path’s physics. Then: a reference DOGDD compiler + executor + CLI suitable for indie product builders (BYOK, Apache-2.0, local-first), with NBM4-lite and DOGDD-RFC schema packs and Cursor/Claude Code export adapters.

Priority 3 — Second worked domain instantiation. Promote Appendix C DOGDD-RFC from sketch to worked example with empirical observations from ship-mlp governance (C.6 records the partial operational evidence already accumulating).

Priority 4 — Mechanised proofs. P-BLS, P-CRE-A/B, P-COMP, T4a/T4b formalised in a proof assistant (Coq, Lean 4, or Agda).

Priority 5 — Φ extensions. Bounded transitive-predecessor references (controlled relaxation of Option A); temporal predicates over execution traces; user-defined typed aggregations.

Priority 6 — Σ-meta-DOGDD operationalisation. The reference implementation’s σ-meta revision pipeline (§7.7.2) is the first mechanical realisation; remaining work is a reference Σ_meta bootstrap and migration tooling for external adopters.

Priority 7 — Reliability property P-REL. P-CRE-A/B claim repeatability of G_eligible only. A separable reliability property P-REL should characterise the conditions under which G_executed approaches G_eligible: bounded-retry semantics, idempotency requirements on Worker outputs, timeout policies, and the supersession behaviour of a partially failed execution. P-REL is identified as future work; formalising it without conflating reliability with replay-equivalence is the open design question.

Priority 8 — arXiv submission preparation (updated in v8). Before arXiv CS submission, the following submission-readiness items are required:

• Format conversion. Convert from Markdown draft to LaTeX article with stable theorem numbering, cleaned references, and removal of DRAFT/Pre-publication metadata.
• Title with subtitle. Consider arXiv-safer presentation: main title Domain-Ordered Directed Graph Governance for AI-Assisted Product-Hypothesis Formation; subtitle Shipping Better MLPs Faster (motto preserved as subtitle; main title reads as a research article rather than a marketing slogan). This is presentation, not retraction — the motto’s intent stays intact.
• Mechanical citation verification. Every arXiv ID, author attribution, title, and URL in references must be verified. arXiv-cited works as of v8: Piskala (2602.00180), Marri (2602.02584), Xavier et al. (Agentproof, 2603.20356), Execution Lineage (2605.06365), Xu et al. (Certified Purity, 2605.01037), Bai et al. (Constitutional AI, 2212.08073), Irving et al. (Debate, 1805.00899). Each must be cross-checked against the arXiv abstract page; spot-checks have already validated direction but not every metadatum.
• Implementation evidence inclusion (updated in v8). The v6 arXiv-readiness triage required at least one completed evidence block for a CS-category submission. §7.7 now provides it: a scoped, deviation-named implementation-conformance block. The paper can accordingly be positioned as an architecture paper with implementation-conformance evidence (empirical outcome validation still future work), rather than a purely conceptual architecture paper. Category fit remains cs.SE primary, cs.AI secondary. The named-deviation framing in §7.7.4 must be preserved verbatim in any submission revision — removing it would convert a scoped truthful claim into an overclaim.
• AI-assistance disclosure. Current acknowledgements (Claude, GPT-5.5 Pro, Gemini as adversarial reviewers; sole author for inventive contribution) align with arXiv policy. No change required.
• NBM4 v070 retargeting decision. Either retarget §5 to v070 before submission (eliminating the “soon-to-be-outdated schema” reviewer hook) or move NBM4-specific cardinality details deeper into Appendix B and leave §5 as a methodology-illustration sketch.

In plain terms — what changed between v7.1 and v8 is the difference between an architecture drawing and a certified structure: the twenty break-in tests now run against real code and pass, the system’s own release gate keeps its marketing honest, and the three remaining gaps are named on the same page as the evidence. What has not changed: no claim that products ship faster or better — those studies (H1–H6) are still the headline future work, and the paper says so in its first sentence.

References

(References preserved from v5_2 with v6 additions and attribution corrections.)

Bai, Y., et al. (2022). Constitutional AI: Harmlessness from AI feedback. arXiv:2212.08073.

Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley.

Bench-Capon, T. J. M., & Dunne, P. E. (2007). Argumentation in artificial intelligence. Artificial Intelligence, 171(10-15), 619-641.

Cardelli, L. (1997). Type systems. ACM Computing Surveys, 28(1), 263-264.

Chen, P. P.-S. (1976). The entity-relationship model — toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9-36.

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.

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.

Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009). Introduction to Algorithms (3rd ed.). MIT Press.

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.

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.

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.

Irving, G., Christiano, P., & Amodei, D. (2018). AI safety via debate. arXiv:1805.00899.

Kahn, A. B. (1962). Topological sorting of large networks. Communications of the ACM, 5(11), 558-562.

Kozloff, M. (2021). NBM4: Navigation-Based Methodology for Most Lovable Products, v1.2. NBM4.com. https://nbm4.com

Lodderstedt, T., et al. (2021). The Sigstore project: Software supply-chain security. Linux Foundation.

Marri, R. (2026). Constitutional spec-driven development: Enforcing security by construction in AI-assisted code generation. arXiv:2602.02584.

Nau, D., Cao, Y., Lotem, A., & Muñoz-Avila, H. (1999). SHOP: Simple Hierarchical Ordered Planner. Proceedings of IJCAI-99, 968-973.

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/

Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value Proposition Design: How to Create Products and Services Customers Want. Wiley.

Piskala, K. (2026). Spec-driven development: From code to contract in the age of AI coding assistants. arXiv:2602.00180.

Reynolds, J. C. (1974). Towards a theory of type structure. Programming Symposium, 408-425.

Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.

Torres, T. (2021). Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value. Product Talk LLC.

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.

van der Aalst, W. M. P. (2016). Process Mining: Data Science in Action (2nd ed.). Springer.

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

Xavier, A., et al. (2026). Agentproof: Static verification of agent workflow graphs. arXiv:2603.20356.

Xu, et al. (2026). Certified purity for cognitive workflow executors: From static analysis to cryptographic attestation. arXiv:2605.01037. [Added in v7.1 per C5 — closest concurrent prior art on executor-closure + cryptographic-attestation substrate; differentiated by epistemic layer (L2 code purity vs DOGDD L3 hypothesis governance).]

(LLM-agent workflow optimisation survey, GraphFlow, Execution Lineage, and additional comparator citations: see Appendix D references list, preserved from v5_2 with attribution corrections.)

Agent frameworks and orchestration systems cited

LangChain / LangGraph documentation. https://docs.langchain.com (retrieved May 2026)

Temporal workflow documentation. https://docs.temporal.io (retrieved May 2026)

OpenAI Agents SDK documentation. https://openai.github.io/openai-agents-python (retrieved May 2026)

Microsoft AutoGen documentation. https://microsoft.github.io/autogen (retrieved May 2026)

Guardrails AI documentation. https://guardrailsai.com (retrieved May 2026)

GitHub Spec Kit documentation. https://github.github.com/spec-kit (retrieved May 2026)

Airflow documentation. https://airflow.apache.org/docs/ (retrieved May 2026)

Prefect documentation. https://docs.prefect.io (retrieved May 2026)

Dagster documentation. https://docs.dagster.io (retrieved May 2026)

Appendix A: Formal Definitions, Notation, and Φ Grammar

Definition A.1 (Domain Schema). A domain schema is a tuple Σ = (S, A, f, F, L, R, c, B, Φ, Ψ) 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: A → 2^{(name, type)} is the output field schema per artifact type
• L: (a ∈ A, fname ∈ F(a)) → ScopeBound is the field-level scope-bound function
• R ⊆ A × A × Σ_edge is the set of legal typed relationship schemas, Σ_edge = {derives_from, evidence_for, activates, requires}
• c: R → (ℕ × ℕ) × (ℕ × ℕ) gives outgoing and incoming cardinality bounds (min_out, max_out, min_in, max_in)
• B: A → ℕ gives maximum node instance count per artifact type
• Φ is the typed activation predicate language defined below
• Ψ is the set of static schema constraints beyond graph shape (required fields, legal roots, stage-local ordering rules)

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 ∈ {requires, derives_from} only).

Definition A.2 (Φ Grammar — full)

field_path  ::= node_id "." "outputs" "." attr_name ("." attr_name)*
typed_atom  ::= field_path : T  op  constant : T            -- types must match
count_agg   ::= "count" "(" field_path : T*  op  constant : T ")"  op  nat
                -- bounded aggregation over single typed array field;
                -- T* indicates array of T; aggregation collapses to a scalar count
φ           ::= typed_atom
              | count_agg
              | φ ∧ φ
              | φ ∨ φ
              | ¬φ

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

Typing rules

• Γ ⊢ field_path : T iff field_path resolves to a declared output field of type T in the source node’s schema
• Γ ⊢ constant : T iff the constant literal matches type T
• Γ ⊢ field_path op constant : Bool iff Γ ⊢ field_path : T and Γ ⊢ constant : T (types match) and op is defined on T
• Γ ⊢ count_agg : Bool iff the array element type matches the constant type and the outer comparison’s nat is well-typed
• Γ ⊢ φ₁ ∧ φ₂ : 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, E_exec_c, E_audit_c, λ_V, λ_E, ρ, κ) where (per v7.1 C1) E_exec_c carries edges labelled {activates, requires, derives_from} (scheduler-visible) and E_audit_c carries edges labelled {evidence_for} (audit-only); G_candidate is schema-legal if it satisfies P-COMP steps 1-9 (excluding HITL/triage proofs which apply to G_approved → C).

Definition A.4 (Triage Record)

β = (verdict, concerns, advocate_report, sceptic_report, judge_report, G_candidate_hash, panel_config, timestamp) where verdict ∈ {Adopt, Trial, Watch, Reject} and panel_config encodes model families and prompt families satisfying the diversity requirement.

Definition A.5 (Human Approval Record)

α = Sign_user(h_pre) where h_pre = hash(V, E_exec, E_audit, λ, ρ, κ, β, σ, μ). α references the exact pre-commit hash; h_pre excludes α and γ.

Definition A.6 (Compiler Attestation)

γ = Sign_compiler(h_pre || α). The Compiler signing key resides in a trust anchor separate from human keys.

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

C_min  = (V, E, λ, ρ, α, σ, μ)
C_plus = (V, E_exec, E_audit, λ, ρ, κ, β, α, γ, σ, μ)

id(C) = hash(h_pre, α, γ)

Definition A.8 (Graph-Closed Executor)

An executor X is graph-closed with respect to C if: (i) X accepts only (id(C), C_content) with hash(C_content) = id(C); (ii) X verifies γ against the trust anchor and α against the approver identity declared in σ; (iii) X constructs an immutable adjacency table from (V, E_exec) on load; (iv) X exposes no create_node, create_edge, or modify_topology API; (v) all tool calls reference node IDs ∈ V; (vi) X has no access to Planner or Compiler credentials.

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

See §3.7. Mode A: K pre-committed in C. Mode B (default): K_log content-addressed activation log. Mode C: no K commitment, no replay claim.

Definition A.10 (Eligible and Executed Subgraphs — v7.1 C2)

• G_eligible(r) is the subgraph induced by edges where requires and derives_from edges are unconditionally eligible (v7.1 C1) and activates edges’ predicates evaluate true under K_r. Node eligibility = reachability from the declared root set through this eligible-edge set. G_eligible(r) is a deterministic function of (C, K_r).
• G_executed(r) = { v ∈ V_eligible(r) : status_r(v) = COMPLETED }. G_executed depends on runtime reliability (timeouts, worker failures, transient errors) and is not claimed to be a deterministic function of (C, K_r).
• G_active(r) is a deprecated label retained for cross-reference to v6/v7; new text in v7.1 onward uses G_eligible(r) and G_executed(r) explicitly.
• SKIPPED nodes = V_approved \ V_eligible(r) — predicate evaluated false. FAILED nodes = V_eligible(r) \ V_executed(r) — eligible but did not complete.

Appendix B: NBM4 Artifact Schema — Cardinality and L Tables

(Preserved from v5_2 Appendix B with v6 additions: tightened cardinality form (min_out, max_out, min_in, max_in), and field-level L bounds added per §5.5.)

B.1 Stage Assignments

Preserved from v5_2 Appendix B.1.

B.2 Relationship Cardinality Table (tightened)

B.3 Field-Level Scope Bounds L (sample)

B.4 Activation Predicate Reference

R11 default activation condition uses the v6 typed_atom form: current_pain_priorities.outputs.priorityItems[*].priorityScore ≥ 15 is not valid Φ as a typed_atom (it indexes an array); the correct form is either:

• current_pain_priorities.outputs.maxPriorityScore ≥ 15 — where maxPriorityScore is a scalar field derived in the source node, OR
• count(current_pain_priorities.outputs.priorityItems[*].priorityScore ≥ 15) ≥ 1 — bounded aggregation form

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: DOGDD-RFC — A Second Domain Instantiation (Sketch, with Operational-Status Note)

This appendix demonstrates DOGDD’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. (v8 note: at v7.1 this sentence read “which currently governs RFCs via a manual process with no compile-time enforcement” — that description is now outdated; see C.6.)

C.1 Stage Set

C.2 Artifact Type Universe (sample)

C.3 Sample Relationships and Cardinalities

C.4 Triage Roles in RFC Domain

• Advocate: the RFC author
• Sceptic: a designated counter-proposal reviewer or alternative-architecture proposer
• Judge: a technical lead or governance committee chair

The diversity requirement holds: ≥2 model families, ≥2 prompt families. In the ship-mlp instantiation, the panel is constructed from Claude (Advocate), GPT-5 Pro (Sceptic), and Gemini (Judge).

C.5 GGC in RFC Domain

A DOGDD-RFC GGC ratifies a specific RFC topology — proposed RFC + open questions + ADRs + pilot plan — bound by HITL signature from the governance committee chair. The Executor in this domain is the ship-mlp ratification pipeline: it accepts only GGCs, executes the trial pilot phase, and produces an EvidenceBundle stream.

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 12 Features per PainPriorities). Same five governance layers. Same GGC structure C_plus. Same formal properties. Same down(C) → SpecSeed handoff (RFC → implementation specs in adopting subsystems).

What this demonstrates. DOGDD’s framework-level invariants (P-BLS, P-TI, P-CRE, P-COMP, P-EDGE, T4a/T4b, P-AUD, P-IMM) hold over DOGDD-RFC without any modification to the framework itself. Domain-agnosticism is by construction, not by assertion. The framework is the pattern; Σ-instantiations are reference implementations.

C.6 Operational Status of the DOGDD-RFC Pattern in ship-mlp (NEW in v8)

The DOGDD-RFC instantiation is no longer purely a paper sketch. The ship-mlp substrate operationally runs recognisable instances of the five governance layers over its own RFC corpus and its own evolution — including the conformance programme reported in §7.7, which was itself produced under this discipline:

• Adversarial triage (Layer 4): RFC candidates are triaged by independent multi-model Advocate/Sceptic/Judge panels (distinct model families and prompt families, no self-play), with scored verdicts, binding conditions, and loop-until-pass semantics; the RFC that authorised the §7.7 conformance work passed at a 9.5-threshold panel over multiple rounds.
• HITL as a hard gate (Layer 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 became the live-path named deviation).
• 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.

What C.6 does not claim. This is partial operational evidence of the pattern, not a full DOGDD-RFC conformance claim: the live execution path carries the same substrate-unification deviation named in §7.7.4, RFC artifacts are not yet compiled into content-addressed DOGDD-RFC GGCs end-to-end, and no P-CRE replay claim is made for the RFC domain. Promotion of this appendix from sketch-with-operational-notes to worked instantiation remains Priority 3 future work (§8.3).

A worked DOGDD-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: Reference Implementation Substrate

ship-mlp. DOGDD’s primary reference implementation is ship-mlp, an OSS substrate combining a deterministic Template Planner (alpha) over a canon registry, a Temporal-based execution adapter with Claim-Check storage (raw content in encrypted blob store; orchestration history carries content references and hashes only), gVisor/Firecracker-isolated workers, and a pull-model independent AuditCollector that subscribes to Model Gateway, Tool Proxy, and Runtime Supervisor telemetry streams. Hash canonicalisation throughout uses RFC 8785 JSON Canonicalization Scheme. The full implementation contract is the ship-mlp Architecture Blueprint v0.7 (Kozloff, 2026), authoritative for ADR sequencing, schema specification, and substrate substitution rules.

D.1 Vocabulary Cross-Reference

DOGDD’s framework-level terms map to the blueprint’s implementation-level terms as follows. Each row is exact unless noted.

D.1.1 Landed Check-API Artifacts (NEW in v8)

The §7.7 conformance evidence is carried by the following landed artifact families in the ship-mlp repository (named here by role; exact paths are repository-internal):

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

DOGDD’s invariants (P-BLS, P-TI, P-CRE-A/B, P-COMP, P-EDGE, P-AUD, P-IMM, T4a, T4b) are independent of the substrate choices ship-mlp commits to. Alternative substrates satisfying the architectural contract — a different orchestration engine than Temporal; a different isolation primitive than gVisor/Firecracker; a different signing scheme than ES256 over JCS; a different blob store than S3-class encrypted Object Lock — are admissible. The blueprint’s substrate choices are alpha-stage engineering commitments calibrated for production, not architectural prerequisites of DOGDD.

What ship-mlp commits to that DOGDD does not require

• Temporal as the orchestration adapter
• gVisor / Firecracker microVMs as the worker isolation primitive
• RFC 8785 JSON Canonicalization Scheme (JCS) as the canonicalisation rule
• ES256 over JCS as the signing scheme
• 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 DOGDD requires that any substrate must provide

• Content-addressed canonical serialisation (any deterministic canonicalisation suffices)
• Two cryptographic key custody domains (one for human signers, one for Compiler attestation; separability is the invariant, not the scheme) — the reference implementation’s current realisation of this invariant is a named deviation (§7.7.4)
• A graph-closed execution surface with no topology-mutation API (the invariant; any runtime providing this satisfies P-TI)
• An audit channel sourced from outside the worker process (pull-model AuditCollector is one realisation; signed-receipts-from-mediator is another)
• An append-only signed lifecycle registry keyed by id(C) (signing scheme is substrate-bound; chain-integrity is the invariant)

D.3 Status of the Implementation (rewritten in v8)

At v7.1 this section reported the ship-mlp blueprint at v0.7 with ADR authoring sequenced toward an R1 alpha, and stated that the reference implementation, “when operational,” would become the evidence base. That status is superseded.

As of 2026-07-05 the reference implementation has landed, under its own RFC governance (RFC-0220 §10 alpha, 2026-07-01; RFC-0235 full-conformance sprint, closed 2026-07-05):

• the complete check-API conformance surface enumerated in §7.7.2 and D.1.1, test-first, with typed fail-closed rejection codes;
• the all-asserted paper-indexed TC-1–TC-20 conformance suite with dual-index mapping to §7.5, passing in continuous validation;
• the machine-readable conformance ledger and the executable release-claim gate (§7.7.3), with the ledger deliberately not-green while the three §7.7.4 deviations remain open;
• end-to-end trace reconstruction from intent gate through plan gate, compiler admission, commit identity, executor admission, node-bound effect, evidence references, review gate, and lifecycle state, with the §4.8 per-event identity fields.

The scope qualifier is repeated here deliberately: this is check-API-layer conformance with three named deviations (live-path substrate unification; asymmetric key custody; SpecSeed handoff). The reference implementation is now the evidence base for the mechanism claims of this paper (§7.2, §7.5); it is not yet an evidence base for the empirical hypotheses H1–H6, and it does not support full or unqualified conformance wording — a restriction its own claim gate enforces mechanically.