WealthTech Pros Strategic Briefing · April 2026

The six disciplines behind
Specification-Governed Development

SGD is not a single invention. It is the deliberate synthesis of six established disciplines—each proven independently over decades—combined for a new audience: AI coding agents. The documentation is the team.

6 Established disciplines synthesised into one governance framework
Decades Of proven practice in enterprise architecture, BDD, and design systems
Zero drift Specifications are constraints, not suggestions—agents must comply
The thesis

Six specialists encoded as documents

In a traditional development team, six disciplines are embodied by people. When AI agents replace or augment these roles, that judgement must be encoded explicitly.

What makes SGD distinctive is that these disciplines are encoded as machine-readable constraint systems that agents must consult before, during, and after every code change. Each document replaces the implicit judgement a human specialist would bring—the architect who spots a structural contradiction, the tester who asks “what about the edge case?”, the UX designer who prevents five modules from looking like five different products.

The result is not a replacement for human judgement—it is the encoding of collective human judgement into a constraint system that makes AI agents safe to operate at enterprise scale.

The key insight: SGD shifts specifications from an input to a constraint—from “here’s what to build” to “here’s what you must not violate.”

The foundations

Six established disciplines, one synthesis

Each discipline has been proven independently over decades. SGD combines them into interconnected, machine-readable documents that govern AI agent behaviour.

Capability Modelling

TOGAF / ArchiMate

The L1→L2→L3 hierarchy of domains, capabilities, and features comes directly from enterprise architecture. TOGAF defines capability-based planning as a mechanism to ensure strategic business plans drive the enterprise from a top-down approach, and ArchiMate provides the formal notation for representing capability maps across organisational boundaries.

In SGD: The capability model serves as the “what exists” layer—the authoritative map of every business function the system delivers. When an AI agent receives a change request, it first locates the affected capability in this model before touching any code.

Living Documentation

BDD / Cyrille Martraire

The concept that specifications and tests are documentation—not a separate artefact that drifts—comes from the BDD community and was codified by Cyrille Martraire in Living Documentation: Continuous Knowledge Sharing by Design (Addison-Wesley, 2019). Martraire demonstrated that well-crafted code, BDD scenarios, and structured annotations can replace traditional documentation entirely.

In SGD: Every feature spec is living documentation: BDD scenarios are the acceptance criteria, and they update as part of the change protocol—never as an afterthought.

Architecture Decision Records

ADRs / Michael Nygard

The ADR format was introduced by Michael Nygard in 2011: short text files capturing a single architectural decision alongside its context and consequences, stored in version control next to the code. ThoughtWorks placed ADRs in the “Adopt” category of their Technology Radar in 2018, and the pattern is now used by the UK Government Digital Service, AWS, and thousands of open-source projects.

In SGD: ADRs are the constraints that AI agents check before making structural decisions, preventing agents from unknowingly contradicting previous architectural commitments.

Design Systems

Atomic Design / Brad Frost

Brad Frost’s Atomic Design (2017) introduced a methodology for thinking about interfaces as hierarchies—atoms, molecules, organisms, templates, and pages—and established design systems as living, enforced catalogues of components and patterns. Frost argued that teams should “build systems, not pages.”

In SGD: The design system document serves as the UX Designer persona: it defines the canonical component catalogue, interaction patterns, and design tokens that every UI change must comply with. This prevents five independently-built modules from looking like five different products.

DAG-Based Dependency Tracking

Make / Bazel / Nx / Terraform

The directed acyclic graph as a dependency management mechanism has deep roots—from Make (Bell Labs, 1976) through Google’s Bazel and Nrwl’s Nx to HashiCorp’s Terraform. The principle: model all artefacts as nodes in a graph, track their dependencies, and when a node changes, automatically identify everything downstream that needs updating.

In SGD: The DAG extends beyond code to encompass capability models, feature specs, API contracts, components, and tests—creating a unified dependency graph that answers “if I change this, what else breaks?” across repositories.

Specification-Driven Development

Kiro / Fowler / Emerging Discipline

Martin Fowler’s team at ThoughtWorks published an analysis of Kiro, spec-kit, and Tessl in 2025, recognising the shift from “vibe coding” to structured specification. Amazon’s Kiro IDE—which attracted 250,000+ developers within three months of launch—uses EARS notation to transform prompts into structured requirements before code generation.

In SGD: Rather than generating specifications from prompts (Kiro’s approach), SGD treats pre-existing, curated specifications as the governing layer that AI agents are obligated to consult and comply with.
The synthesis

From disciplines to virtual team members

SGD structures six disciplines as interconnected documents that an AI agent reads before making changes, consults during implementation, and updates afterward. The DAG is the enforcement mechanism that ensures nothing is missed.

ESTABLISHED DISCIPLINES Capability Modelling TOGAF / ArchiMate Living Documentation BDD / Martraire Decision Records ADRs / Nygard Design Systems Atomic Design / Frost DAG Tracking Make / Nx / Terraform Spec-Driven Dev Kiro / Fowler SGD Synthesis VIRTUAL TEAM MEMBERS The Architect Capability Model + ADRs The UX Designer Design System Catalogue The Business Analyst Feature Specs The Tester BDD Scenarios + Coverage The DevOps Engineer DAG Manifest + Contracts The Developer Change Protocol Proven independently over decades Combined & encoded for AI agents Judgement encoded as documents

SGD synthesises six established disciplines into machine-readable documents that govern AI agent behaviour

The mapping

Disciplines, roles, and documents

Each human role brings judgement, context, and cross-referencing that prevents any single change from undermining the whole. SGD encodes this judgement explicitly.

Discipline Human Role SGD Document
Capability Modelling Enterprise Architect Capability Model (L1→L2→L3 hierarchy)
Living Documentation Business Analyst + Tester Feature Specs + BDD Scenarios
Architecture Decision Records Tech Lead / Principal Engineer ADR Registry
Design Systems UX Designer Design System Catalogue
DAG Dependency Tracking DevOps / Platform Engineer DAG Manifest
Specification-Driven Development All of the above Change Protocol
“Most knowledge is already there somewhere in your artifacts, even in an implicit form.”
— Cyrille Martraire, Living Documentation (Addison-Wesley, 2019)

Why this matters for WealthTech Pros: When AI agents replace or augment development roles in wealth management platforms, the regulatory and fiduciary context demands that architectural judgement is encoded explicitly—not left to probabilistic inference. SGD provides the constraint framework that makes AI-assisted development auditable and safe.

In depth

What each discipline contributes

A closer look at the intellectual heritage behind SGD and how each discipline functions within the framework.

TOGAF Capability-Based Planning

TOGAF’s Business Capability Planning guide describes how capability instances are mapped to the resources, applications, and processes required to deliver value—precisely the traceability that SGD applies to AI agent governance. The ArchiMate modelling language provides formal notation for representing these maps across organisational boundaries.

The Open Group — TOGAF Standard & ArchiMate

BDD as Living Documentation

Martraire, CTO and co-founder of Arolla, demonstrated that well-crafted code, BDD scenarios (Gherkin), and structured annotations can replace traditional documentation entirely, evolving at the same pace as the software itself. The book builds on Domain-Driven Design and BDD principles.

Martraire (2019) — Addison-Wesley

ADRs: Pattern Language of Decisions

Martin Fowler describes ADRs as capturing decisions whose “consequences are very likely to become the context for subsequent ADRs”—creating a pattern language of design choices. The UK GDS, AWS Prescriptive Guidance, and ThoughtWorks Technology Radar all endorse the practice.

Nygard (2011), Fowler — ThoughtWorks

Atomic Design: Build Systems, Not Pages

Frost argued that teams should start with the smallest elements possible and combine them intelligently until reaching a coherent composition. The methodology provides a common naming convention familiar to both designers and developers, enabling modification at any level of the hierarchy.

Frost (2017) — Atomic Design

DAG: From Make to AI Governance

Nx’s recent addition of an MCP server for exposing workspace context to AI agents—including module boundary enforcement and conformance rules—validates the convergence of DAG-based tooling with AI governance. The DAG manifest in SGD grows incrementally as the team works.

Nx, Bazel, Terraform — DAG ecosystem

From Vibe Coding to Structured Spec

Fowler’s analysis describes this as “Spec-Driven-Development”—a recognition that specifications must come before code when AI agents are involved. Amazon’s Kiro IDE attracted 250,000+ developers within three months using EARS notation to transform prompts into requirements.

Fowler (2025) — ThoughtWorks