Spec Is a View

SDD gives regulated AI delivery something it badly needs: a controlled interface. Specs can be reviewed, versioned, scored, traced, and handed to engineers or agents. Standardising on it is the right move. It is also why the next constraint appears immediately: a spec can be controlled without every assertion inside it being defensible.

The spec is governed as a delivery artifact, not as a set of institutionally relied-upon assertions. For AI that drafts a memo for a human to check, the distinction does not bind. For AI that acts on the assertions inside the spec, it does. The constraint past SDD is admissibility: whether the institution can defend the basis on which an AI system acted, after the act, to a supervisor, an auditor, or a court.

The short answer is the claim. The longer answer requires being precise about what a claim is, why a well-formed requirement in mature SDD is not yet one, and how the spec relates to the substrate underneath. The cleanest engineering statement of the relationship is a database one - the spec is a view, claims are the base tables - though the analogy is literal in fewer respects than the strong form might suggest.

Two granularities, but not the obvious one

The granularity argument in its weak form - "the spec is a document, the claim is an assertion" - is too easy to defeat. Mature SDD already decomposes specs into atomic requirements with IDs, owners, status, source links, validity, traceability, and lifecycle. A serious SDD program does not govern only the document; it governs every requirement inside it. The spec-claim distinction is not really about atomicity. Both can be atomic. The distinction lies in three properties that requirements, even when well decomposed and managed in shared libraries, do not by themselves carry. Once those properties are present, the artifact has become a claim - whatever the platform calls it.

Descriptive, not prescriptive

A requirement is prescriptive. It states what the system shall do: enforce this rule, present this disclosure, retain this record. It is an instruction to the system. In formal terms, it is deontic.

A claim is descriptive of an institutional commitment to a proposition. It states what the institution is prepared to rely on when the instruction is executed: this jurisdiction is currently treated as high-risk; this interpretation of regulation X is the one the institution has stood behind; this threshold is the operative one for this product in this jurisdiction. In formal terms, it is epistemic.

The distinction is not that claims are always factual and requirements always normative. Many claims are normative interpretations. A regulatory rule, once the institution adopts a position on it, is a claim about institutional reliance. The requirement is the downstream instruction that implements the rule. Governing the requirement does not govern the underlying claim. For assertional requirements - those whose correctness depends on propositions the institution must defend - the requirement is downstream of claims. Not every engineering requirement has this structure; latency budgets, interface conventions, and UX choices remain ordinary requirements. The claim substrate is load-bearing where an AI act relies on assertions about the world, the customer, the law, or institutional policy.

Canonical, not spec-scoped

Mature SDD can reduce spec-scoping through reusable requirements, shared libraries, derived requirements, and impact analysis. That is real, and it solves the duplication problem. It does not solve the canonical-reliance problem. Even with shared libraries, the unit of governance remains the requirement-in-a-baseline or requirement-in-a-release. The same belief can be baselined into release A and release B; release A continues operating under the older baseline; release B updates. Both remain "approved" in their contexts. The institution now has inconsistent live reliance, and a project-centric library cannot, on its own, answer the institution-centric question: what was the single authoritative position on jurisdiction X at 14:03 UTC last Tuesday, across all active systems.

A claim has identity, lifecycle, and standing outside any one spec or release. Many specs project the same claim. Its standing can change without those specs being edited. Cross-spec contradiction becomes detectable not because someone remembered to compare two specs, but because both projections resolve to claims in the same governed substrate. This is the difference between knowing one spec is internally consistent and knowing the institution is consistent about what its delegated systems are allowed to rely on. Only the second is the question a supervisor will ask after a delegated act.

Dynamic standing, not static status

A requirement has status - a stored field. "Approved." "Deprecated." Status changes when someone changes it, or when an automation rule changes it on someone's behalf. The transition is an act, recorded as such, and the field is overwritten.

A claim has standing - a function. Standing is computed from the claim's dependencies: the current authority of its source, the validity window, any contradicting claims, the most recent interpretation that supersedes earlier ones. The claim's content and provenance are immutable - event-sourced. Standing is a temporal projection over those events, recomputed as dependencies move. When the world changes, the previous version of the claim is not edited; new events arrive, and the standing projection for downstream reliance is recomputed.

The distinction is not whether the value is stored or automated. A mature ALM platform can drive requirement status with webhooks and feeds, and it should. The distinction is what the system can answer.

A mutable status field plus a human-readable audit log is not designed to recompute entitlement from the full dependency graph at an instant. The forensic question delegated AI must answer after the act is: which version of claim C42 was the system entitled to rely on at 14:03:15 UTC last Tuesday, given that two contradictory authority updates arrived within the same hour? An event-sourced substrate, where typed assertion events, authority events, supersession events, and contradiction events are first-class and replayable, answers this as a native capability. Reconstructing the same answer from a mutable record plus a separate audit log is forensic assembly - expensive, slow, lacking the integrity of a native temporal query, and unsuited for a runtime gate. The contrast is not between "ALM" and "claim substrate." It is between current-state requirement management and bitemporal assertion governance. If an ALM platform stores assertion-level events, authority and dependency events, valid-time and transaction-time, and deterministic projection rules, it has implemented the substrate pattern - whether or not it uses the word claim.

That query is the architectural test. Not "can the platform automate a transition" - it can. The test is whether the platform can reconstruct, without forensic assembly, the exact basis the system relied on at the moment of the act, distinguishing what was effective in the world from what the institution had recorded and was entitled to rely on at the time.

Why the spec is a view

Once the three properties are in place, the database statement becomes precise.

Claims are the normalized addressable unit. The spec is a view - a named projection over claims, rendered on demand, not stored truth. A filed, versioned spec is a materialized view: the same projection, cached for convenience, and at the same time a controlled record of what was rendered and approved at that point.

The analogy is literal in one respect, and only one: integrity constraints can be attached and evaluated consistently only at the normalized addressable unit, not at the rendered document. Constraints sit on the substrate; the view inherits the standing the substrate can supply, through governed projection rules. It is not literal in the stronger sense that institutional assertions behave like database facts. Many claims are interpretations, scoped to a jurisdiction, valid for a window, contestable on their face. Normalization gives them a place to be governed. It does not pretend to guarantee truth.

A minimal claim model makes the analogy concrete. The immutable part is a stream of events about a claim:

The standing of the claim is not a column on any record. It is a projection:

The two distinct times are essential. Valid_time is when the assertion was effective in the world. Transaction_time is when the institution knew it and was entitled to rely on it. Most forensic questions about delegated action need both: a regulator may publish a correction with an effective date earlier than the publication date; a court may clarify a rule retrospectively; an authority may issue an interpretation at one time, effective from another.

Projection rules are themselves governed artifacts. The function that turns events into standing is versioned, approved, and reconstructable as of any transaction time. A standing answer is admissible only when the rule version used to compute it is identifiable and the rule itself was in force at the transaction time being queried. The substrate that governs claims must also govern the function that projects them.

A spec that says "the agent must route payments above threshold X to jurisdictions in the high-risk list for enhanced due diligence before release" projects against several claims: a definitional claim about which jurisdictions are currently in the list, a threshold claim about the operative amount, an authority claim about who can change the list. If HM Treasury publishes an updated list, the old membership claims are not edited. New source events arrive. New membership claims are asserted; old ones receive supersession or invalidation events. Standing for any spec projecting those claims is recomputed from the new dependency graph. The historical standing of the old claim remains queryable for acts taken while it was current. The spec is not edited; the basis the agent resolves at runtime has changed.

This is recomputation of standing, not authorization of behavioural change. Whether the system may act on the new standing is the action gate's question, addressed in a separate piece. The architecture does not bypass change control; it refines it. The action gate's policies, themselves under formal change control, determine the blast radius of a standing change: a minor definitional update may be allowed for dynamic consumption, while a change to a load-bearing regulatory interpretation routes dependent systems to a "requires recertification" state and triggers a formal release process.

The same architecture applies outside financial services. In aviation, an FAA airworthiness directive changes the validity of a maintenance-procedure claim a control system was relying on. The maintenance spec is not edited; the claim about which procedure remains current receives a supersession event with its own valid_time and transaction_time. The system's basis at the moment of any subsequent action is reconstructable as of that moment. The supervisory question - whether the action was admissible given what the institution was entitled to rely on - is the same. Different regulator, different forcing function, identical architectural pressure.

Contradiction becomes addressable

Contradiction does not fall out of putting claims in one store. Detecting it requires shared predicates, scopes, validity windows, jurisdictional context, authority precedence, and sometimes human adjudication. Two claims may look contradictory but differ by product, customer class, or effective date.

What the substrate does is make contradiction addressable. Without it, claims live in the documents that contain them; cross-document conflict is a manual review exercise that scales poorly. With it, contradictions can be queried, surfaced as candidates, routed to the right authority, and recorded as resolved or pending. The substrate does not decide the conflict; it provides the place where the conflict can be represented, scoped, owned, and adjudicated. The goal is not perfect institutional consistency. The goal is addressable inconsistency: conflicts are visible, scoped, owned, and prevented from silently supporting delegated action.

The round trip

A spec contains assertional content that can be decomposed into claims, alongside narrative and design material that should remain in the spec. The conversion runs both ways.

Spec to claims, by decomposition. Take the spec's assertional content - the rules, definitions, interpretations, eligibility criteria, thresholds, authority references. Extract each as a candidate claim. Stamp provenance: which spec it came from, which source that spec drew on, who authored it, when, by what method. Score and tier: assign the standing each claim is permitted to be used for, given its source authority and the consequence class of actions that may rely on it. Wire the typed relationships: supersession, derivation, supports, contradicts.

This work is not new. The institution already pays for it - expensively, chaotically, and reactively. The work of interpreting a regulation, scoping it to a product, deciding what counts as authoritative, mapping it to controls, and reconstructing the basis after an audit query already happens. It happens in ad-hoc legal review, in control mapping workshops, in architecture sign-off, in panic-driven post-incident evidence assembly. None of it is captured as durable, reusable, governable output. What changes here is not the work; it is where the work lands. Call the function the Claim Analyst role - business analysis, domain expertise, and where the content carries legal or regulatory weight, qualified legal judgment, integrated into the existing spec-review gate. Reviewers stamp each assertional paragraph with claim identity, authority, scope, and standing tier as part of approving the spec, not as a separate process. Initial implementation is expert-led because legal and policy interpretation are expert work. The maturity path is tooling - semantic parsers, ontology-guided authoring environments, assistive decomposition - that handles the routine majority of claims and reserves expert adjudication for the genuinely novel cases. The architectural saving is that this work moves from reactive fire-drill to predictable upfront control, with a durable output the institution can stand behind.

This is not a routine database operation. Decomposing prose into governed assertions is interpretation, ontology alignment, authority mapping, judgment. It is the central engineering discipline of this architecture. It deliberately separates the institution's governable assertions from the narrative that explains them. The claim substrate governs the what: the propositions the institution stands behind. The spec retains the why: the rationale, design intent, and explanatory context that engineers and reviewers need. Rationale is linked to claims as controlled narrative evidence; it is not the assertional source of truth, but it remains part of the admissibility record.

Claims to spec, by projection. Once claims are governed, the spec is re-rendered from them on demand. The document still exists; the engineering workflow still gets the spec interface it expects. Every assertional line in the spec traces to a claim with a standing and a provenance chain. Projection itself is a controlled artifact: it requires templates, ordering, and rules about which claims to include and exclude.

The substrate is a platform capability

The substrate is not a parallel manually maintained version of the spec; the construction discipline is decomposition, not duplicate authorship. But it is a platform capability - a governed temporal claim graph with a data model, lifecycle, APIs, ownership, and operating model. It needs budget. It needs a team. In the transition, it is additive work. At maturity, it redirects work that the institution already performs - inside specs, in cross-spec review, in audit response, in evidence-pack assembly - so that the governed assertion becomes the durable object and the spec becomes the projection.

Event sourcing is the logical model; non-repudiation requires the controls around it. For regulated use, the event stream must be append-only under privileged controls, with event identity, signer identity, transaction-time stamping, retention policy, and tamper-evident integrity through hash chaining or equivalent ledger controls. Immutable events as an implementation pattern is not the same as evidence non-repudiable to an auditor; the controls have to be there.

The architectural saving is not that the work disappears immediately. It is that the institution stops paying for claim work twice: once trapped inside documents, again reconstructing it for an auditor. The redirection only becomes real when claim authoring becomes the path of least resistance and runtime gates refuse unsupported assertions. The justification is not operational efficiency. It is risk mitigation and capability enablement - the cost of being able to deploy delegated AI into consequential decisions and defend the basis afterwards.

The substrate only survives if it becomes a control point. The adoption invariant is direct: no consequential delegated action may execute, and no spec may be promoted for such action, unless every relied-upon assertion resolves to a claim with current standing or an explicit, governed exception. Without that invariant, the graph becomes another enterprise metadata initiative - correct in principle, abandoned in practice. With it, the graph is in the promotion path, and the claim layer is the path of least resistance for every team that must ship. The invariant is a target state, adopted incrementally - enforced first on the highest-risk, highest-scrutiny systems where the business case for this level of control is undeniable, then extended as the platform proves its ability to de-risk deployment and shorten supervisory response.

The invariant is operational, not rhetorical. Promotion and runtime enforcement need four controls: action classification, claim-resolution evidence, fail-closed semantics, and exception governance. A consequential action carries a declared action class. Before promotion, every assertion referenced by the spec must resolve to claim IDs with permitted standing for that action class - and "every relied-upon assertion" means assertions explicitly referenced by the spec, retrieved into the action context, or emitted as part of the system's decision basis, not every latent association the model touches. For consequential action, the system must be architected so that the actionable basis is constrained to claim-resolved context, approved tools, and emitted decision evidence; latent model knowledge may assist language production, but it may not be the authoritative basis for a consequential act unless surfaced and resolved to standing claims. At runtime, the action gate either obtains a current standing decision or accepts a signed standing token within its freshness window; otherwise it fails closed or routes to human review. Exceptions require owner, authority, scope, expiry, consequence class, reason, and residual-risk acceptance, and are reportable as control breaches if they persist beyond their approved window. The exception path is itself governed: an exception is a special-form claim with standing, not an off-ledger workaround.

This capability can be delivered by a new platform or by an incumbent vendor, but only if the platform re-architects to enforce the separation of immutable assertion events from computed standing projections. A system that continues to mutate requirement records in place, merely adding richer audit logs or metadata, has not adopted the pattern - regardless of how mature its workflow or how rich its traceability.

What this means for SDD

The SDD interface does not change. Engineers and agents still work through specs. Reviews, quality scoring, and traceability all live there for good reasons. The consumption interface stays recognisable.

What changes is the production model behind the spec, and the failure modes engineers see. Authoring of the durable artifact moves to the claim layer. Approval of reliance happens against claims. The spec is rendered, not maintained as the source of truth. Build-time checks can prevent deployment of systems that reference claims without permitted standing. Runtime gates can re-evaluate standing at the moment the system commits to the consequential act. None of this asks engineers to relearn a spec format. It does require the platform to know which is the source and which is the view, and to fail closed when standing cannot be evaluated.

Adopting the substrate is not a migration off SDD. It gives SDD the system of record for institutional reliance the document format was never built to be.

Two axes, kept separate

Axis one is the unit of governance: the spec, or the claim. This piece is about that axis.

Axis two is which governance: data governance (the floor), epistemic governance (claim governance), action governance (the gate at commit). That axis is a different piece in the architecture. Claim standing supplies the admissible basis on which the later action gate can decide. It does not, by itself, authorize the act. What the gate does with claim standing is the subject of the next piece; that the gate must be able to ask for claim standing as of any past instant is the architectural requirement this piece establishes.

Both axes belong in any full architectural answer, but on separate slides. If they land together, the audience cannot tell whether the distinction being drawn is spec-from-claim or data-from-epistemic, and the argument loses precision.

Where it sits in the stack

From the top: humans and agents act. The spec is the interface they work through. The substrate - the governed claim graph - is the system of reference the spec is projected from. Data governance is the floor beneath the substrate, governing the source data and evidence claims depend on; claim governance adds the standing and authority that data governance alone does not provide.

Spec-and-claim is the relationship between the middle two layers. SDD governs the interface; the substrate sits one layer below; the data floor sits below the substrate.

Why this binds

The structural point is direct. A spec governed only as a delivery artifact does not let the institution defend what it acted on, because the act commits on the assertions inside the spec, not on the spec as a document. For drafting, that gap is tolerable: a human reviewer remains accountable for independent judgment over the propositions the system used. For delegated action under supervision, the human is no longer in the transaction path before the act. There is no equivalent way to close that gap without giving each relied-upon assertion canonical identity, current standing, and addressability outside any one document.

The argument is strongest where three conditions coincide: delegated machine action, material consequence, and external accountability. Financial services in scope of supervisory examination is the visible current case. The same architectural pressure appears in defence, aviation, medical devices, autonomous vehicles, safety-critical industrial control, and public administration - any setting where, after a consequential act, an institution must defend not only what the system did but the propositions it was entitled to rely on when it did it. Regulation is the visible forcing function. It is not the boundary of the architecture.

What kills the architecture

The honest test is what would make this wrong.

The claim is not that the capability must be delivered by a separate product or by a system labelled "claim substrate." The claim is that any architecture adequate for delegated action under supervision must provide a minimum capability set: canonical assertion identity, immutable assertion and dependency events, bitemporal standing projection, authority-aware supersession and contradiction handling, and enforcement at promotion and runtime. Ordinary mutable records plus separate audit logs do not provide this natively. They record changes to state; they are not the authoritative temporal dependency graph from which standing is derived. Reconstructing the entitlement query from them is forensic assembly, not a native query. If an ALM platform provides those capabilities - if the audit log is itself the immutable assertion-event substrate, with typed dependency events, bitemporal semantics, and deterministic projection rules - the platform has adopted the substrate pattern under another name. If mutable records and audit logs can provide the same capability without those properties, this argument fails. The observable test is whether the institution can answer the entitlement query natively, at runtime or audit speed, without reconstructing the dependency graph by forensic assembly.

The architecture also survives only as long as its ontology does. With the enforcement invariant in place, the long-term failure mode is no longer abandonment - it is ontology rot: semantic drift in the core predicates, scopes, and types that underpin the graph. An authoritative system operating on a decayed ontology produces verifiably wrong outcomes, which is more dangerous than the messy human system it replaced. Governing the ontology - the predicates and their meanings - becomes as critical as governing the claims, with its own discipline, its own ownership, and its own review cadence.

The supervisory test is what supervisors actually require institutions to produce after a delegated act, as evidence of the basis. If approved specs plus process traceability plus runtime logs prove sufficient, the substrate is not load-bearing for those cases. The substrate becomes load-bearing precisely when an institution must produce assertion-level, time-specific evidence at scale, under changing authority and source conditions - which is where delegated AI under supervision is heading.

Closing

The decision to standardise on spec-driven development is right. The spec is the controlled item. The reviews, the quality scoring, the traceability all live there for good reasons.

What the decision does not settle is what makes the spec defensible. The spec is a view. The view inherits whatever standing the substrate carries. For AI that drafts, the substrate can stay implicit; the human reviewer absorbs the gaps. For AI that acts under supervision, the substrate has to be explicit, governed, queryable, and addressable at the level of the individual claim - because that is the level at which standing changes, contradiction shows, and authority attaches.

A spec in a mature SDD process is a powerful control over development. A spec rendered from a governed claim graph becomes a defensible control over delegated action. The first ensures the system was built as intended. The second ensures the institution can defend the basis on which it acted.

SDD gives the institution the interface it needs. The substrate gives it the source of institutional reliance it has been missing.

The application keeps its interface. The architecture gives it the database it should have been running on.