DomainSpec: A Layered Meta-Architecture for Deterministic Software Derivation and Governance Attenuation in Multi-Agent Systems

Large language model (LLM) agents can now generate code, tests, and infrastructure from natural-language specifications. Yet without formal structure, their outputs remain stochastic — non-reproducible, non-auditable, and ungovernable at scale. We present DomainSpec, a layered meta-architecture (L0–L7) that bridges domain knowledge to verified software through deterministic derivation rules and self-regulating governance. The framework introduces four contributions: (C1) a dual-track meta-model spanning business semantics and operational enforcement across seven layers; (C2) a typed domain ontology of 25 meta-types and 29 typed relationships that enables deterministic derivation both per feature (T = f(C, R, Δ)) and across feature composition (T_composed = f(C, R, Δ) + f_cross(E_AB, Δ_cross)), mapping domain concepts to test obligations, observability metrics, and implementation contracts; (C3) a governance attenuation theory explaining why adding governance layers to multi-agent systems decreases per-layer fidelity, bounded by Shannon channel capacity; and (C4) a meta-circular self-governance mechanism where the framework's axioms, constitution, and tuning loop govern — and prune — themselves. We validate DomainSpec on a production system with 7 features across 3 business pillars, deriving 445 test obligations and 146 observability metrics from 89 domain concepts. Results show that typed ontologies eliminate the stochastic gap between specification and implementation, while structural governance interventions (observer-executor separation, deterministic signal detection, via negativa pruning) restore enforcement fidelity without adding layers. DomainSpec is open-source and available as a replication package.

Keywords: domain-driven design, meta-modeling, deterministic test derivation, LLM agents, governance attenuation, multi-agent systems, specification-first development

The emergence of LLM-based coding agents — SWE-agent [14], Devin [2], GitHub Copilot Workspace [3] — has shifted the bottleneck in software engineering from writing code to governing what agents write. These systems can produce syntactically correct implementations from natural-language prompts, but they lack formal guarantees about completeness, consistency, or traceability to business requirements.

Three fundamental problems remain unsolved:

1.1 Core Hypothesis & Research Questions

DomainSpec is grounded in three intertwined hypotheses:

H1 — Domain Structure Determines Test Completeness: If domain concepts (entities, rules, events, calculations, workflows, policies) and their relationships (references, produces-for, triggers, enforces) are formally modeled, then test obligations can be deterministically derived with coverage traceable to business requirements. The hypothesis predicts that typed domain models are both necessary (informal models produce incomplete, non-reproducible tests) and sufficient (typed models produce comprehensive, derivable tests).

H2 — Governance Layers Have Attenuation Bounds: As multi-agent systems add decision-making layers (specify → derive → verify → enforce → tune), per-layer compliance fidelity decreases in a measurable pattern bounded by Shannon channel capacity and the cognitive load on agents. The hypothesis predicts that naive layer stacking yields exponential attenuation, but structural interventions (observer-executor separation, deterministic signal detection) can invert the trend without removing layers.

H3 — Self-Improving Systems Require Meta-Circular Governance: Systems that improve themselves need mechanisms to improve those improvement mechanisms, which creates an infinite regress. The hypothesis predicts that a bounded strange loop — where the framework's constitution axioms govern how the constitution itself evolves — can resolve this without external authority.

These hypotheses drive four research questions:

• RQ1: Can we derive deterministic, complete, and traceable test suites from domain models without manual test authoring? (→ C2)
• RQ2: Does adding governance layers to multi-agent systems decrease fidelity predictably, and can structural interventions restore fidelity without removing layers? (→ C3)
• RQ3: Can agent roles (PO, QA, Dev, Stakeholder) make better decisions if they share a common domain model and governance signals? (→ C1)
• RQ4: Can a system govern its own governance through axioms and tuning loops, achieving self-improvement without infinite regress? (→ C4)

These questions map to experiments E1–E10 (RQ1–RQ3) and E11–E20 (meta-meta framework generalization of RQ2–RQ4).

This paper presents DomainSpec, a layered meta-architecture that addresses all three problems through a unified structural approach. Rather than treating specification, derivation, governance, and self-improvement as orthogonal concerns, DomainSpec organizes them as emergent properties of a seven-layer hierarchy:

• Layers 0–1 define the domain ontology — a closed vocabulary of 25 meta-types and 29 typed relationships that capture business semantics, including cross-feature composition edges.
• Layer 2 hosts the derived software — tests, code, and metrics produced by deterministic rules applied to L1 concepts.
• Layers 3–4 encode governance — a formal constitution (L3) grounded in epistemic axioms (L4), each rule traceable to the harm its absence causes.
• Layer 5 provides navigation — structured discovery of concepts across the knowledge graph.
• Layer 6 enforces compliance — alignment audits, blocking gates, and deterministic signal detection.
• Layer 7 orchestrates execution — 14 specialized agents and 25 skills coordinated through a nine-stage pipeline.

The key insight is that derivation and governance are not bolted onto the system — they are structural consequences of the layered architecture. A typed ontology (L1) deterministically produces tests (L2). A formal constitution (L3) deterministically maps to enforcement gates (L6). The tuning loop (signals → reflection → improvement) closes the system into a self-regulating cycle where Axiom A6 ("govern the governance itself") creates a Hofstadterian strange loop [4] that prevents infinite regress.

We make four contributions:

We validate these contributions on a production poker team management system comprising 7 features across 3 business pillars (product, operations, finance), demonstrating that DomainSpec derives 445 test obligations and 146 observability metrics from 89 domain concepts with full traceability.

The remainder of this paper is organized as follows. Section 2 surveys related work. Section 3 presents the meta-architecture. Section 4 defines the typed domain ontology. Section 5 formalizes the derivation calculus. Section 6 develops governance attenuation theory. Section 7 describes the self-improving pipeline. Section 8 presents the case study. Section 9 discusses limitations and future work.

DomainSpec sits at the intersection of several research traditions: domain-driven design, model-based testing, specification-first development, multi-agent governance, and meta-modeling. We survey each and identify the gap that DomainSpec fills.

2.1 Domain-Driven Design

Evans' Domain-Driven Design (DDD) [7] established that software structure should mirror domain structure through ubiquitous language, bounded contexts, entities, value objects, and aggregates. DDD provides the intuition that domain semantics should drive implementation, but it remains informal — the vocabulary is advisory, relationships are implicit, and there is no derivation function from domain model to verification obligations. DomainSpec formalizes the DDD intuition into a closed typed ontology with deterministic derivation.

2.2 Model-Based Testing

Model-based testing (MBT) [8] generates tests from behavioral models — state machines, labeled transition systems, or UML diagrams. MBT achieves deterministic derivation (from model to test), but the models describe system behavior, not domain semantics. A state machine captures valid transitions but says nothing about the business rules that guard them, the calculations that produce side effects, or the events that propagate downstream. DomainSpec's derivation operates on domain concepts (rules, calculations, postconditions, workflows), not behavioral abstractions, producing tests that are traceable to business meaning.

2.3 Behavior-Driven Development

BDD [9] bridges domain language and tests through Given/When/Then scenarios written in Gherkin. BDD is human-readable but not formally derivable — there is no function from domain model to scenario set. The scenarios must be manually authored, and their completeness depends on the author's diligence. DomainSpec generates BDD-style templates deterministically: every rule in operations.md produces at least 2 tests (pass + fail), every state transition produces 1 happy-path test and 1 negative test, every interface endpoint × response status produces 1 contract test.

2.4 Formal Specification Languages

TLA+ [10], Alloy [11], and Z [12] provide mathematically rigorous specifications with model checking or theorem proving. These achieve the strongest guarantees but are impractical for typical business domains: the learning curve is steep, the specification effort is high, and the gap between formal model and implementation code requires a separate verification step. Recent work combines Alloy with LLMs [13] to lower the barrier, but the fundamental trade-off between rigor and accessibility remains. DomainSpec targets the middle ground — formal enough for deterministic derivation, accessible enough for domain experts writing Markdown.

2.5 LLM Agents for Software Engineering

SWE-bench [1] established the benchmark for LLM agents resolving GitHub issues. SWE-agent [14] introduced tool-use and retrieval-augmented workflows. More recent systems like Devin [2] and Copilot Workspace [3] provide end-to-end development environments. These systems demonstrate that LLM agents can produce working code, but none address specification governance — ensuring that what the agent builds matches what the domain requires. VeriGuard [15] formally verifies LLM-generated agent policies against synthesized safety specifications, but inherits the accessibility limitations of formal methods. DomainSpec governs agent execution through typed specifications that agents can navigate and derive from.

2.6 Multi-Agent Governance

As agent systems scale from single-agent to multi-agent architectures [16], governance becomes a first-class concern. Constitutional AI [17] introduced the idea of using principles to constrain generation, but applies at the single-output level. The Agentic Delivery Lifecycle (ADLC) [18] proposes continuous tuning as the central value driver for agent-assisted development. DomainSpec operationalizes ADLC principles through a concrete layered architecture with formal governance attenuation bounds.

2.7 Meta-Modeling Frameworks

The Meta-Object Facility (MOF) [19] defines a four-layer meta-modeling architecture (M0–M3) for standardizing modeling languages. ISO/IEC/IEEE 42010 [20] provides a conceptual framework for architecture descriptions. Zachman [21] organizes enterprise architecture along interrogative dimensions, and Kruchten's 4+1 view model [31] decomposes an architecture into complementary stakeholder views. These frameworks operate at the modeling language level — they define how to define models — but do not connect to software derivation or agent governance. The Meta-Track framework [22] introduces a seven-layer hierarchy connecting domain vocabulary to code via annotations and orphan detection. DomainSpec adopts Meta-Track's layering insight and extends it with deterministic derivation (L1→L2), formal governance attenuation theory (L3–L4), and meta-circular self-governance (A6, C10, M-001–M-006).

2.8 Research Gap

Table 1 summarizes the landscape. No existing approach combines a typed domain ontology, deterministic derivation to both tests and observability metrics, multi-agent governance with formal attenuation bounds, and meta-circular self-governance — the four properties that DomainSpec unifies under a single layered architecture.

DomainSpec organizes knowledge, software, and governance into a seven-layer dual-track hierarchy. The business track governs what things mean (domain semantics → software → verification). The operational track governs how the framework itself runs (orchestration → enforcement → self-improvement). Both tracks share Layers 0–2 and diverge at Layer 3.

3.1 Layer Definitions

• Layer 0 — Domain Reality. The actual business domain as it exists independent of software. This is the territory, not the map. L0 is the ultimate source of truth against which all other layers are validated.
• Layer 1 — Ontology. A typed vocabulary of 25 meta-types and 29 relationships (Section 4) that captures domain semantics, including cross-feature composition semantics. L1 transforms the informal domain reality into a navigable knowledge graph documented in Markdown files (SPEC.md, domain.md, operations.md, states.md, etc.).
• Layer 2 — Software. Executable artifacts derived from L1: implementation code, test suites, observability instrumentation, and infrastructure configuration. L2 artifacts are derived, not authored — they are the output of applying derivation rules (Section 5) to L1 concepts.
• Layer 3B — Governance (Business Track). The constitution: explicit rules governing how domain concepts may be created, related, and extended. Constitution rules (C1–C11) are collected in CONSTITUTION.md, each traceable to an L4 axiom and mapped to an L6 enforcement gate.
• Layer 3O — Governance (Operational Track). Agent instructions, skill specifications, and pipeline sequencing rules that govern how the framework's agents operate.
• Layer 4B — Epistemic Foundations (Business Track). Axioms (A1–A6) formalized in AXIOMS.md that articulate why each governance rule exists. Each axiom is grounded in empirical evidence of harm — the damage observed when the axiom is violated. This follows Taleb's Via Negativa [23]: formalize a rule only when its absence has caused measurable harm.
• Layer 4O — Epistemic Foundations (Operational Track). The principles underlying agent behavior: economy of action, minimal privilege, observability-by-default.
• Layer 5 — Navigation. Discovery mechanisms for locating concepts across the knowledge graph: feature indexes, tag indexes, registry files, and structured search patterns.
• Layer 6B — Enforcement (Business Track). Alignment audits, layering audits, PASS/FLAG/BLOCK verdicts, and CI gates that verify L2 artifacts conform to L1 specifications. Each enforcement gate references the L3 constitution rule it implements.
• Layer 6O — Enforcement (Operational Track). Signal detection, threshold analysis, and tuning triggers that verify the framework itself operates within expected bounds.
• Layer 7B — Orchestration (Business Track). The nine-stage pipeline (Section 7) that sequences planning, specification, story generation, test derivation, implementation, verification, and signal emission.
• Layer 7O — Orchestration (Operational Track). The tuning loop (signals → reflection → improvement) that closes the self-governance cycle.

3.1.1 Hard Layer-System Definitions

To keep architecture semantics centralized (instead of distributed across claims and experiments), we define the layer system explicitly.

3.2 The Derivation Chain

The architecture's structural power comes from its formal derivation chains. Each chain traces from epistemic foundation to enforcement:

Concretely, Axiom A1 ("Documentation is the source of truth for domain meaning") justifies Constitution Rule C1 ("Every domain concept must be documented before it is implemented"), which is enforced by Gate G1 (the alignment audit that blocks code without corresponding SPEC entries). This chain is auditable: given any enforcement gate, one can trace backward to the axiom that justifies its existence. Given any axiom, one can trace forward to every gate that implements it. Table 2 shows the complete chain.

3.3 The Dual-Track Architecture

The business and operational tracks share L0–L2 (the domain and its software) but maintain independent governance hierarchies. This separation ensures that what to build (business track) and how to build it (operational track) are governed by independent authorities that can evolve at different rates.

Business Track (B)                   Operational Track (O)
─────────────────                    ────────────────────
L7B: Pipeline stages                 L7O: Tuning loop
L6B: Alignment audits                L6O: Signal detection
L5B: Feature navigation              L5O: Agent context discovery
L4B: Domain axioms (A1–A6)           L4O: Operational principles
L3B: Constitution (C1–C11)           L3O: Agent instructions

         ╲                 ╱
          ╲               ╱
           L2: Software
           L1: Ontology
           L0: Domain Reality

The tracks converge at three points: (1) L1, where the ontology defines vocabulary for both tracks; (2) L2, where derived software serves both domain behavior and framework operation; and (3) the feedback loop, where operational signals (L6O) trigger business-track re-derivation (L7B → L1 → L2).

3.4 Meta-Circular Self-Governance

The deepest structural property of the architecture is its meta-circularity. The framework governs itself through the same mechanisms it uses to govern software:

• Axiom A6 ("The governance system governs itself") creates a self-referential foundation — the axiom layer includes an axiom about its own governance.
• Constitution Rule C10 permits the constitution to amend itself when evidence warrants, subject to the same Via Negativa principle (C11) that governs all rule creation.
• Meta-health metrics M-001–M-006 observe the observer: Orphan Rate (M-001) measures whether the ontology-to-code binding is complete, Friction Rate (M-002) measures whether enforcement is active, Overhead Ratio (M-006) measures whether governance cost is proportionate to domain work.

This creates a Hofstadterian strange loop [4]: the system that observes software behavior is itself observed by the same system's meta-health layer. The loop is bounded (it does not recurse infinitely) because M-001–M-006 are defined metrics with fixed computation, not open-ended self-reflection. The observer observes itself through a finite, deterministic lens. This structure resolves the infinite regress problem: rather than requiring an external authority to govern the governance, DomainSpec's governance is self-terminating through bounded self-reference.

4.1 Meta-Types

DomainSpec defines a closed vocabulary of 25 meta-types organized into three categories: 14 backend types, 11 UI types. Every domain concept documented in a feature specification must declare exactly one meta-type.

The backend types organize into four functional groups:

• Structural (what things are): Entity, Value Object, Enum
• Behavioral (what happens): Operation, Query, Calculation, Workflow, Saga
• Governing (what constrains): Rule, Policy
• Connective (what connects): Interface, Event, Mapping, State Machine

The UI types mirror this organization:

• Structural: Page, Layout, Component
• Behavioral: View Model, Hook, Form, Action
• Governing: Guard
• Connective: Binding, Adapter, State Indicator

Technique specializations are deliberately excluded from this vocabulary. Architectural techniques such as Saga, Outbox, CQRS, Materialized Read Model, and Hexagonal Ports/Adapters are not added as meta-types: they have no single structural code-artifact shape, only a decision-protocol shape (when to apply them, given which symptoms). They are governed by a separate decision axis — the technique/specialization model (Section 4.3, DS-M13) — rather than by the closed meta-type system above. This keeps the meta-type vocabulary about what artifacts exist and routes which technique to choose into its own method. (Two such techniques, Materialized Read Model and the Outbox event-reliability pattern, recur as candidate vocabulary extensions; see Section 9.1.)

4.2 Typed Relationships

Each relationship has a typed signature constraining its source and target:

4.3 Formal Properties

The ontology satisfies four structural properties:

These properties ensure that the concept graph is well-formed: no relationship can connect incompatible concept types, cross-feature edges are explicit, and the dependency direction between frontend and backend is structurally enforced.

Properties 1–4 govern the meta-type system of §4.1. The orthogonal technique/specialization axis introduced above carries its own validity property, kept separate so it does not contaminate the structural ontology:

4.4 The Concept Graph

The concept graph provides full-stack navigability. From any concept, one can follow typed edges to discover what it affects and what affects it. For example, tracing a user action end-to-end:

This trace is fully typed: each step constrains what concept types can appear next, making the graph navigable by both humans and LLM agents.

The central claim of DomainSpec is that verification obligations — test cases and observability metrics — can be deterministically derived from the typed domain ontology. This section formalizes the derivation.

5.1 The Derivation Function

The derivation is deterministic: given the same concept graph G and the same rule set Δ, the function produces the identical set of test obligations T on every invocation. This eliminates the stochastic gap — LLM agents execute derivation rules, not stochastic generation.

The composed function preserves determinism while making cross-feature integration obligations explicit and derivable.

5.2 Test Derivation Rules

DomainSpec defines 14 backend test derivation rules and 6 UI test derivation rules for per-feature graphs. For composed systems, 3 additional cross-feature derivation rules are applied through f_cross. Each rule specifies its source (which documentation section), its trigger (which concept types), and its output (which test types with what cardinality).

5.3 Derivation Cardinality

The test obligation count for a feature is deterministic and computable:

For a feature with n_s state transitions, n_r rules, n_c calculations, n_p postconditions, n_e events, n_q queries, n_ep endpoint-status combinations, and n_m mappings:

where the inequality accounts for rules that produce more than the minimum test count.

5.4 Observability Derivation (Symmetric Outer Loop)

A key architectural insight is that the same specification documents that derive tests also derive production observability metrics. DomainSpec defines 16 observability derivation rules (O-rules) that operate on the concept graph in parallel with the test rules, producing OpenTelemetry metric obligations.

The total observability obligation count is similarly deterministic:

Together, tests and metrics form a symmetric verification pair: tests validate at build time (inner loop), metrics validate at runtime (outer loop), both derived from the same specification, both traceable to the same domain concepts. This symmetry ensures that no domain behavior is tested but unmonitored, or monitored but untested.

5.5 Three-Layer Metric Architecture

The derived metrics organize into three layers, each answering a different question:

• Domain Fidelity (O1–O3, O5–O7, O9, O15–O16): Does production behavior match the specification? Any violation is a P0 — the system is doing something the domain model says it should not.
• Operational Health (O4, O8, O10–O12): Is the system reliable and performant? Violations are P1 — the system is correct but degraded.
• Business Effectiveness (O13–O14): Is the feature achieving its goal? Violations are P2 — the system works but the business outcome is wrong.

This layering ensures that alerts are actionable: a P0 always means the domain model is violated, not just that latency is high.

6.1 The Problem

DomainSpec's dual-track architecture operates as a seven-layer recursive reinforcement system. Each layer governs the layer below it, and the tuning loop creates a cross-cutting feedback mechanism. A fundamental tension emerges: as governance layers accumulate, each individual layer's enforcement fidelity decreases.

We call this governance attenuation — the systematic loss of per-rule compliance as the total number of rules grows. This is not a bug in any particular implementation; it is a structural property of bounded-capacity enforcement channels.

6.2 Three Root Causes

Cause 1: Context Exhaustion (The Epilogue Problem). In LLM-based agent systems, governance observations (signal emission, compliance checks) are typically the last step in a multi-step pipeline. By the time an agent reaches step 10 of a 10-step process, its effective attention over early-session events has degraded. This maps to the serial position effect [24] and to dual-process accounts of bounded attention [29]: items in the middle of a long context are recalled worst. Governance violations from step 3 are forgotten by step 10.

Cause 2: Observer-Executor Conflation. The same agent that performs the work is asked to observe itself performing the work. This violates the Conant-Ashby Good Regulator Theorem [25]: every good regulator of a system must be a model of that system. The executor is the system — it cannot simultaneously be its own model with high fidelity. Asking a controller to be its own oscilloscope produces partial observations at best.

Cause 3: Instruction Dilution (Channel Saturation). Agents receive instructions from multiple sources simultaneously: agent definitions, skill specifications, framework instructions, and governance epilogues. Each source competes for attention in a fixed-capacity channel.

6.3 The Channel Capacity Model

We model governance fidelity using Shannon's channel capacity theorem [5]:

where C = effective governance capacity (rules reliably followed per session); B = bandwidth (context window attention available for instructions); S = signal strength (clarity and specificity of each rule); N = noise (competing instructions, ambiguity, context length).

Adding governance layers increases N (more competing instructions) faster than it increases S (clarity of any single instruction). The result is a decreasing signal-to-noise ratio and thus decreasing effective capacity per rule.

6.4 Theoretical Bounds

Three theoretical results suggest that k* ≈ 6–7 for bounded-capacity systems:

• Miller's Law [26]. The number of objects a bounded-capacity information processor can maintain simultaneously is 7 ± 2. LLMs exhibit analogous capacity limits in instruction-following tasks.
• Ashby's Requisite Variety [6]. A controller must have at least as much variety as the system it controls. For a system with 25 concept types and 29 edge types: log₂(54) ≈ 5.75 governance dimensions are theoretically sufficient. At 7, returns are diminishing.
• Gödel's Incompleteness (informal application). No sufficiently complex formal system can prove all true statements about itself. The meta-system cannot fully observe itself — there will always be governance gaps that the system is structurally incapable of detecting from within.

6.5 Empirical Evidence

DomainSpec's signal system (Section 7.2) is the instrument intended to measure governance attenuation directly: it records, per pipeline session, how many of the expected governance observations were actually emitted. We state the prediction the architecture makes, and separate it from what has so far been measured.

Prediction. Because governance observations are the last step of a long pipeline (Cause 1) and are self-reported by the executor (Cause 2), the model predicts that the realized signal-emission rate will fall well below 100% of expected, with the highest-value signal type (governance-gap) the most underreported — detecting what you failed to detect requires exactly the self-modeling capacity that Conant-Ashby proves insufficient. The targeted intervention threshold for observer-executor separation (Section 6.6) is to lift governance-gap detection from a low self-report baseline (on the order of 30–40% of expected) to at least 60%.

Evidence status. At the time of writing, the live signal corpus is not yet populated to support these rates as measured findings: the dedicated signal-emission experiment (E7) has not been run, and the persisted signal log is empty. The 30–40% baseline and 60% target above are therefore stated as the experiment's projected figures, not as collected data, and are the explicit object of E7. We include them here to fix the measurable target, and flag that the attenuation curve itself (Definition 6) remains an open empirical result pending E4/E5/E7.

6.6 Structural Interventions

The winning strategy is not more rules enforced by instruction but fewer, sharper rules enforced structurally — targeting the system's highest-leverage intervention points [28]. DomainSpec proposes three structural interventions:

Intervention 1: Observer-Executor Separation (Dual-Agent Protocol). Instead of asking one agent to both execute and observe, dispatch a lightweight shadow agent after each pipeline session. The executor produces artifacts; the observer reads the session's output and produces only signals. This mirrors Constitutional AI's [17] approach where one model generates and another evaluates. This eliminates causes 1 (context exhaustion — the observer has full attention budget) and 2 (conflation — the observer has a single responsibility).

Intervention 2: Deterministic Signal Detection. The largest signal types — alignment-gap, spec-gap, governance-gap — can be partially computed rather than relying on LLM self-report. Deterministic detectors shift detection from L7 (unreliable LLM observation) to L6 (deterministic enforcement):

Intervention 3: Via Negativa Governance Pruning. Track which governance rules have actually caught violations via the shouldHaveBeenCaughtBy field. Any rule with zero references after N pipeline runs is consuming channel capacity without proving value and is a candidate for removal. This implements Taleb's Via Negativa [23]: subtract rules that haven't demonstrated necessity.

6.7 Viable System Model Mapping

DomainSpec's architecture maps onto Stafford Beer's Viable System Model (VSM) [27] — five necessary and sufficient systems for organizational viability:

Beer proved exactly five systems are needed — no more, no fewer. DomainSpec's seven layers map onto Beer's five when redundant layers are collapsed. The insight: the fix is not more layers, but making System 3 continuous (shift enforcement left) and formalizing System 5 (axioms).

7.1 The Nine-Stage Pipeline

DomainSpec's delivery pipeline sequences nine stages, each producing traceable artifacts:

1. Plan — Clarify objectives, constraints, acceptance criteria
2. Spec — Create or evolve feature specification (SPEC.md, domain.md, operations.md, states.md, interfaces.md, events.md)
3. Stories — Generate user stories (STORIES.md) with classic + BDD format
4. Tests — Derive test specifications by applying Δ to the concept graph
5. Implement — Generate code satisfying derived test specifications
6. Verify — Run alignment audit, layering audit, PASS/FLAG/BLOCK verdict
7. UI (optional) — Derive UI-SPEC.md, implement frontend, visual audit
8. Observability — Derive metric obligations, instrument code
9. Signals — Emit structured observations about the pipeline run itself

This section instantiates Definition L-C (Section 3.1.1) by making the L7 business-track stage set S and its handoff relation H explicit. Each stage is executed by one or more specialized agents (14 total) coordinated by skills (25 total). Agents operate on the artifacts produced by previous stages, never on raw user intent — ensuring that domain semantics flow through the typed ontology at every step.

7.2 The Signal System

Stage 9 emits structured signals to an append-only JSONL file. Each signal has a typed envelope:

{
  "type": "alignment-gap | spec-gap | governance-gap | rework | overhead | decision | proposal | pattern | spec-compliance | agent-cost",
  "severity": "LOW | MEDIUM | HIGH | CRITICAL",
  "category": "economy | governance | pattern | quality",
  "data": {
    /* type-specific payload */
  }
}

DomainSpec defines 11 signal types across 4 categories:

• Economy (3 types): step-verdict, rework, overhead — track pipeline efficiency
• Quality (2 types): alignment-gap, spec-gap — track specification fidelity
• Governance (3 types): governance-gap, proposal, spec-compliance — track framework blind spots
• Pattern (2 types): decision, pattern — capture reusable insights
• Operations (1 type): agent-cost — track resource consumption

7.3 Threshold-Based Tuning

Accumulated signals are analyzed against 10 threshold conditions. When a threshold is met, the system triggers a tuning action:

7.4 The Closed Loop

The tuning loop closes the architecture into a self-regulating cycle:

This is DomainSpec's implementation of Beer's System 4 (Intelligence): the framework adapts to its environment not through external instruction but through accumulated evidence of its own performance. The meta-health metrics (M-001–M-006) provide the System 5 (Policy) check — ensuring that the tuning loop itself operates within acceptable bounds.

8.1 System Under Study

We evaluate DomainSpec on a production poker team management system: a multi-feature application managing player recruitment, performance tracking, financial settlements, and coaching operations. The system comprises 7 features across 3 business pillars.

The figures reported in this section (concept, test, metric, and story counts; alignment verdicts) are a direct tabulation of the derived artifacts for this one system, not the output of a separately analyzed, replicated experiment. They establish feasibility and end-to-end traceability on a real codebase; the controlled-experiment evidence for the framework's claims (vocabulary sufficiency, composition coverage) is reported separately in Sections 9.1–9.2, and the claims' overall evidence grades in Section 9.4.

8.2 Quantitative Results

Key metrics:

• Test-to-concept ratio: 5.0 (each domain concept produces on average 5 test obligations)
• Metric-to-concept ratio: 1.64 (each domain concept produces on average 1.64 observability metrics)
• Story coverage: 41 user stories across 7 features (5.9 per feature)
• UI-SPEC coverage: 100% (all 7 features have UI design contracts)

8.3 Test Obligation Breakdown

The distribution shows that rule validation tests (δ₄) are the largest category (21.1%), consistent with the domain being rule-heavy (poker team management involves many eligibility checks, financial constraints, and access controls).

8.4 Alignment Verdicts

Alignment audits across the 7 features produced the following verdicts:

The FLAG verdicts typically indicate concepts documented in the specification but not yet implemented (spec-ahead-of-code), which is expected in an iterative development process. The BLOCK verdict indicated a case where implementation diverged from the documented state machine transitions — caught by the alignment audit before reaching production.

8.5 End-to-End Traceability Example

To illustrate full-stack traceability, we trace the GenerateSettlement operation from the financial-settlement feature:

Axiom A3 (Deterministic Derivation)
  → Constitution C3 (test derivation from specs)
    → operations.md documents:
      - Operation: GenerateSettlement
      - Rules: R1-R5 (eligibility, idempotency, period bounds)
      - Calculations: C1-C4 (profit, debt, makeup, payout)
      - Postconditions: settlement event created, balances updated
    → TEST-PIPELINE derives:
      - 10 rule validation tests (R1-R5 × pass/fail)
      - 4 calculation correctness tests (C1-C4)
      - 3 postcondition assertions
      - 2 idempotency tests
      - 4 contract tests (POST /settlements × 4 statuses)
    → OBSERVABILITY derives:
      - O4: 4 operation metrics (invocation, success, fail, duration)
      - O5: 5 rule violation counters (R1-R5)
      - O6: 4 calculation drift gauges (C1-C4)
      - O9: 2 idempotency violation gauges
      - O15: reconciliation mismatch gauge
      - O16: settlement cycle metrics (6 instruments)

Total for one operation: 23 test obligations + 22 observability metrics, all deterministically derived from the specification, all traceable back to Axiom A3.

9.1 Vocabulary Completeness and Model Theory

The strongest claim of this paper — that the extended 25 meta-types and 29 relationships are sufficient to capture business domain semantics including cross-feature composition — is analytically vulnerable. In Model Theory terms, this is the search for formal Completeness and Soundness. If we define the fundamental rules of the domain reality as a set of axioms (Γ) and the DomainSpec typed vocabulary as our representational model (𝓜), verifying absolute sufficiency means proving mathematically that for any structural truth φ resulting from the domain axioms (Γ ⊢ φ), there is a valid and perfectly mappable representation in our taxonomy (𝓜 ⊨ φ).

Our current evidence is empirical and goes beyond the single case study. A dedicated vocabulary-sufficiency experiment (E6) applied the meta-type vocabulary to 36 features across 18 business domains — spanning DDD-canonical, system-design, and enterprise-SaaS sources — comprising 747 domain concepts and 670 relationships. The vocabulary classified 99.87% of concepts (95% Wilson CI [99.25%, 99.98%]) and 98.96% of relationships cleanly, leaving a single strained concept (a materialized Read Model / projection) and one missing edge class (a workflow-to-event subscription). Independently, six multi-bounded-context domain inventories (cargo shipping, food delivery, banking/finance, ride-hailing, e-commerce, and collaborative project management; 86 concepts and 94 cross-context edges) were each classified entirely within the meta-types, with the Saga coordination pattern recurring in all six. These results support — without proving — the sufficiency claim, and bound its residue to a small, named set of candidate extensions (the Read Model and Outbox techniques of Section 4.1, plus the subscribes edge). We do not claim universal sufficiency for infinite spaces. If the taxonomy attempted to map the infinite open-world universe (permitting infinite recursive loops or basic arithmetic within the meta-types), we would hit the barrier of Gödel's Incompleteness Theorems — there would always exist a domain proposition that the taxonomy could neither map nor deny.

However, the architecture operates on a closed-world assumption and is designed for extension: adding a meta-type requires specifying its derivation rules and relationship signatures, abstracting infinite variations into a finite set of bounded classes, in the tradition of formal ontology for information systems [30]. The question is not whether the vocabulary is universally complete, but whether the mechanism for extending it preserves the formal properties (type safety, deterministic derivation, governance traceability) without allowing infinite state explosion.

9.2 Cross-Feature Composition

E9 established that per-feature coverage alone is insufficient at system composition boundaries. Under the original ontology, 74.5% of cross-context edges were strained or broken in the rerun dataset (94 edges across 6 domains). Incorporating three cross-feature edges (produces-for, triggers-cross, enforces-cross) and one additional meta-type (Saga) resolved this gap to 100% modeled coverage with no extra edge types required in the studied domains.

The composition algebra is now treated as an incorporated extension to the base derivation model:

where E_AB and λ_AB are typed cross-feature edges. The corresponding derivation extension is:

with Δ_cross = {δ_produces-for, δ_triggers-cross, δ_enforces-cross}. This extension qualifies C2: deterministic derivation remains complete within feature boundaries under f, and complete at system level under f + f_cross.

9.3 Formal Semantics and SMT Solvers

The meta-types currently have informal semantics (natural-language descriptions). A formal denotational semantics — mapping each meta-type to a mathematical object (Entity → labeled transition system, Rule → predicate, Calculation → pure function) — would strengthen the derivation calculus and enable automated verification of derivation rule correctness.

Because DomainSpec adopts a closed taxonomy that restricts the domain to a finite number of representational states, it clears the path for computational Model Checking. By translating the domain axioms (Γ) and the DomainSpec taxonomy (𝓜) into a restricted logical language (such as First-Order Logic), SMT Solvers (Satisfiability Modulo Theories) could theoretically be employed to search for "failure states" — scenarios where the domain axioms generate an event that does not belong to any DomainSpec classification. Proving the nullity of this error intersection would mathematically validate the taxonomy's completeness against the provided axioms, guaranteeing that agents taking decisions via DomainSpec will not hallucinate behaviors outside the delimited logical space.

9.4 Controlled Experiments

Our case study demonstrates feasibility on a production system, but controlled experiments are needed to evaluate: (a) derivation accuracy compared to manually-authored test suites, (b) governance attenuation across different agent architectures, (c) vocabulary sufficiency across diverse business domains, and (d) developer productivity with and without DomainSpec. Of these, (c) is partly addressed by E6 (Section 9.1) and the composition coverage of E9 (Section 9.2); (a), (b), and (d) remain open, as the determinism (E1), mutation (E3), attenuation (E4/E5), and productivity (E10) experiments have not yet been run.

A further experiment (E11) probes the technique/specialization axis: whether a symptom-driven decision protocol (Property DS-M13) produces reproducible, auditable technique-selection decisions across edge and scenario contexts, over a provisional catalog of techniques (Saga, Outbox, CQRS, Materialized Read Model, Hexagonal Ports/Adapters, and others). E11 demonstrated full reproducibility of decisions under fixed inputs (run-vs-rerun agreement of 1.0) with a complete adjudication trace. We report it as bundle-scope evidence only: its decision gate was cleared under a single-reviewer policy override rather than the protocol's full multi-rater adjudication, and the operator therefore deliberately left the claim matrix unchanged. E11 thus strengthens the methodology's reproducibility story without yet promoting any claim.

For transparency, we state the current evidence grade of the four contributions explicitly. Only C2 (deterministic derivation) has partial empirical support, from E6 and E9. C1 (meta-architecture / traceability), C3 (governance attenuation), and C4 (meta-circular self-governance) remain insufficiently evidenced pending the experiments named above; their treatment in this paper is architectural and analytical rather than empirically validated.

9.5 Threats to Validity

Internal validity. The case study system was developed by the framework author, potentially biasing the vocabulary toward concepts already present. Independent replication on systems built by other teams would strengthen the findings. This threat is sharpened, not relieved, by the corroborating experiments: E6's domain survey and E11's technique evidence were produced within the same author and repository frame, so where they converge on the same concepts they provide consistency rather than fully independent confirmation (an internal independence-grade review accordingly downgraded that corroboration from strong to moderate).

External validity. Seven features in one domain (team management) may not generalize. The business pillars (product, operations, finance) provide some diversity, but different industries may require different meta-type distributions. E9 external-domain composition evidence draws heavily from DDD literature and reference architectures; broader industrial replication remains necessary for non-DDD-heavy ecosystems.

Construct validity. Test obligation counts measure derivation output, not test effectiveness. A derived test that never catches a bug is less valuable than the count suggests. Mutation testing could validate that derived tests have meaningful fault-detection capability. Relatedly, E6 and E9 validate the derivation function's input space — that the vocabulary and relationship set can faithfully represent the domains studied — but not the derivation function f itself: whether the rules of Section 5 produce correct, fault-detecting tests remains untested pending the determinism (E1) and mutation (E3) experiments. For E9 rerun specifically, deterministic edge-type-to-status mapping improved reproducibility but introduces definitional circularity risk in gap-rate interpretation; this is mitigated by convergence with run-1 and the original run-2 analysis.

9.6 Conclusion

DomainSpec demonstrates that the gap between domain knowledge and verified software can be bridged through structure rather than stochastic generation. A typed domain ontology (25 meta-types, 29 relationships) enables a deterministic derivation calculus that produces 445 test obligations and 146 observability metrics from 89 domain concepts, with composed-system derivation extended through explicit cross-feature edges. Governance attenuation — the systematic loss of enforcement fidelity as rules accumulate — is bounded by channel capacity and addressed through structural interventions rather than additional layers. Meta-circular self-governance resolves the infinite regress through bounded self-reference.

The framework is open-source, production-validated, and available as a replication package. We believe that the transition from stochastic to deterministic agent governance is both necessary and achievable — and that the path runs through typed domain ontologies.

This addendum applies the claim-adjudication result of a repository-wide evidence refresh. Quoted blocks reproduce the approved public-safe findings word for word. Tables preserve the approved cell wording while omitting private repository paths, private selectors, and implementation details that cannot enter public Arcanum.

10.1 Approved public-safe thesis — verbatim

10.2 Claim taxonomy and origin matrix

The parent edit must preserve four origins. A fact from one origin cannot be silently relabeled as evidence from another.

10.3 Current versus inherited counts

10.4 Action-local execution and fixture observations

10.5 Immutable historical report observations

10.6 External theory and comparison

10.7 Killed and unestablished claims — verbatim

• Positive output determinism: no repeated-input/output byte-equality witness.
• Traceability as a research result: identifiers and anchors are fields, not an effectiveness study.
• Open-source DomainSpec or Arcanum: Arcanum’s exact license is PolyForm Noncommercial; DomainSpec remains private.
• Production validation, release, promotion, readiness, or shipped-system status: no external owner authorization or operational acceptance evidence.
• Independent replication and general agent conformance: no independent runtime/reproducer.
• Semantic or implementation completeness and complete mutation effectiveness: evidence is component-, fixture-, rubric-, or corpus-bounded.
• Universal novelty, firstness, uniqueness, or precedent-clean: the search is dated and named-source-bounded; adjacent owners exist.
• Theorem-backed governance attenuation, layer optimum, observer/executor incompatibility, under-reporting, or self-governance: cited theory does not entail those claims.
• Public or shipped DomainSpec/Saturn: pillar and publication boundaries forbid the collapse.
• Gödel applicability and Beer-as-exact-proof language: no admitted exact binding supports the mapping.

10.8 Publication, privacy, and replication boundary

• Refer to private evidence only as source-abstracted internal observations with the proof class and non-replication caveat adjacent.
• Say “source-available under PolyForm Noncommercial 1.0.0,” not “open-source.” Do not imply rights beyond the license.
• Public Arcanum, private DomainSpec v2, and unshipped Saturn must remain separate sentences and claim classes. Only Arcanum is public.
• The deployed Pages artifact proves HTTP reachability and byte identity only. It is not release, production, accessibility, visual-correctness, or research-validity evidence.
• Internal prior work and private mechanisms are not independent validation or a new public contribution.
• Historical report claims must keep denominator, operator/rater, corpus, override, and non-generalization caveats adjacent.
• Action-local claims must preserve “dirty checkout” and “exact observed working-tree bytes.” Fixture claims must preserve “untracked” or “modified” where applicable.

1. C. E. Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" arXiv:2310.06770, 2023.
2. Cognition, "Devin: The First AI Software Engineer," 2024.
3. GitHub, "GitHub Copilot Workspace: Technical Preview," 2024.
4. D. Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid. Basic Books, 1979.
5. C. E. Shannon, "A Mathematical Theory of Communication," Bell System Technical Journal, vol. 27, no. 3, pp. 379–423, 1948.
6. W. R. Ashby, An Introduction to Cybernetics. Chapman & Hall, 1956.
7. E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
8. M. Utting and B. Legeard, Practical Model-Based Testing: A Tools Approach. Morgan Kaufmann, 2007.
9. D. North, "Introducing BDD," Better Software, 2006.
10. L. Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley, 2002.
11. D. Jackson, Software Abstractions: Logic, Language, and Analysis. MIT Press, 2012.
12. J. M. Spivey, The Z Notation: A Reference Manual. Prentice Hall, 1992.
13. A. Cunha and N. Macedo, "Validating Formal Specifications with LLM-generated Test Cases," arXiv:2510.23350, 2025.
14. J. Yang et al., "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering," arXiv:2405.15793, 2024.
15. L. Miculicich et al., "VeriGuard: Enhancing LLM Agent Safety via Verified Code Generation," arXiv:2510.05156, 2025.
16. M. Wooldridge, An Introduction to MultiAgent Systems, 2nd ed. Wiley, 2009.
17. Y. Bai et al., "Constitutional AI: Harmlessness from AI Feedback," arXiv:2212.08073, 2022.
18. C. West, "The Agentic Manifesto: Engineering in the Era of Autonomy," 2025.
19. Object Management Group, "Meta Object Facility (MOF) Core Specification," Version 2.5.1, 2019.
20. ISO/IEC/IEEE, "42010:2011 Systems and Software Engineering — Architecture Description," 2011.
21. J. A. Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, vol. 26, no. 3, pp. 276–292, 1987.
22. V. Boscaro, "Domain-Code-Mapping," GitHub, 2026.
23. N. N. Taleb, Antifragile: Things That Gain from Disorder. Random House, 2012.
24. B. B. Murdock, "The Serial Position Effect of Free Recall," Journal of Experimental Psychology, vol. 64, no. 5, pp. 482–488, 1962.
25. R. Conant and W. R. Ashby, "Every Good Regulator of a System Must Be a Model of That System," International Journal of Systems Science, vol. 1, no. 2, pp. 89–97, 1970.
26. G. A. Miller, "The Magical Number Seven, Plus or Minus Two," Psychological Review, vol. 63, no. 2, pp. 81–97, 1956.
27. S. Beer, Brain of the Firm. Allen Lane, 1972.
28. D. Meadows, "Leverage Points: Places to Intervene in a System," Sustainability Institute, 1999.
29. D. Kahneman, Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.
30. N. Guarino, "Formal Ontology in Information Systems," in Proc. FOIS'98, IOS Press, 1998.
31. P. B. Kruchten, "The 4+1 View Model of Architecture," IEEE Software, vol. 12, no. 6, pp. 42–50, 1995.

This appendix reports what has been built and validated since the body was written. It demonstrates results and cites the implementation; it does not disclose the derivation algorithm. The framework and the derivation calculus (C1–C4) are open. The optimized deterministic engine that realizes the C2 calculus is a separate product. The LLM-based generator is the free, open reference path.

A.1 Demonstrated results

A deterministic reference engine that realizes the C2 calculus T = f(C, R, Δ) has been built and validated. We report its measured behavior; the implementation and derivation rules are not published here.

• Determinism by construction. The same specification documents produce byte-identical test obligations across runs and machines. This is the property C2 predicts, achieved without a stochastic generator.
• Validated. The engine's own test suite passes (95 tests, 0 type errors); output is byte-stable; honesty and write-path containment controls pass.
• It refuses rather than fabricates. Where a specification is not formal enough to derive a checkable test, the engine emits a counted, visible gap instead of inventing one. That refusal is itself a measurement — a spec-formalization metric. On the pilot feature it reads 96%.
• Fault detection (E3 mutation testing). On the pilot, after formalizing one rule the specification had left implicit, the derived suite's mutation score rose 38.75% → 54.37%, and the hardest module doubled (17.2% → 36.56%); the regenerated suite passed 13/13 against the real, unmutated code. The residual gap was unwritten specification, not divergent code. C2 is supported, narrowly and honestly: a deterministic generator produces real fault-detecting tests with zero human variance. This is the single-feature pilot, not a corpus result.
• Self-application. Run on its own specification, the engine derives its own test obligations — a fixpoint.

Scope: the engine covers the backend-domain obligation classes. UI/E2E and scaffolding remain on the LLM path.

A.2 Two generators: free and deterministic

The framework offers two paths from specification to tests, behind one contract:

• The LLM generator is the free, open reference path. It produces the full test specification, including UI/E2E, and ships with the open framework.
• The deterministic engine is the optimized path for the backend-domain slice — reproducible, fault-detecting, and zero-variance. Its results are demonstrated in A.1; its derivation algorithm is not disclosed in this paper.

A.3 Governance in practice

The multi-agent governance machinery the paper describes was exercised at real volume under a held human gate: a recorded, append-only dispatch ledger of 58 dispatches (research and review roles, each human-approved before running). These supported repository and method development around DomainSpec; they are not the paper's controlled experiments (E1–E20), but they evidence the dispatch-and-approval model running in practice.

A.4 Roadmap

Planned, not done: widen the deterministic engine's coverage to more obligation classes; strengthen value-level oracles for the hardest computations; take mutation testing from one pilot to a corpus; run the deterministic path as the live backend-domain stage while the LLM path is retained for the rest. The paper's larger experiments — E1 (determinism), E4/E5 (governance attenuation), E10 (productivity) — remain open; C1/C3/C4 stay architectural pending them.