SGD Platform

Appearance

The Foundations of SGD ​

Six established disciplines, one synthesis ​

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

In a traditional development team, these disciplines are embodied by people: the enterprise 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. When AI agents replace or augment these roles, that judgement must be encoded explicitly.

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 six disciplines ​

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 the mechanism to ensure strategic business plans drive the enterprise top-down; ArchiMate provides the formal notation for representing capability maps across organisational boundaries.

In SGD: the capability model is 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 before touching any code.

🟢 Living Documentation — BDD / Cyrille Martraire

The idea that specifications and tests are the documentation — not a separate artefact that drifts — was codified by Cyrille Martraire in Living Documentation: Continuous Knowledge Sharing by Design (Addison-Wesley, 2019). 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

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 "Adopt" on their Technology Radar in 2018; the pattern is now used by UK GDS, AWS, and thousands of open-source projects.

In SGD: ADRs are the constraints 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 the methodology of thinking about interfaces as hierarchies — atoms, molecules, organisms, templates, and pages — and established design systems as living, enforced catalogues of components and patterns. "Build systems, not pages."

In SGD: the design system document is the UX Designer persona. It defines the canonical component catalogue, interaction patterns, and design tokens that every UI change must comply with — so five independently-built modules don't look 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. 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 — 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.

From disciplines to virtual team members ​

SGD structures the 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.

Proven independently → Combined for AI agents → Judgement encoded as documents

Six disciplines, each decades-proven in their own right. Synthesised into machine-readable constraints. The documentation is the team.

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.

DisciplineHuman RoleSGD Document
Capability ModellingEnterprise ArchitectCapability Model (L1 → L2 → L3 hierarchy)
Living DocumentationBusiness Analyst + TesterFeature Specs + BDD Scenarios
Architecture Decision RecordsTech Lead / Principal EngineerADR Registry
Design SystemsUX DesignerDesign System Catalogue
DAG Dependency TrackingDevOps / Platform EngineerDAG Manifest
Specification-Driven DevelopmentAll of the aboveChange 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 in regulated sectors

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.

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 — A 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

Sources and references ​

Next: How It Works — see the platform in action in three steps.

Powered by RepoSentry

© 2026 WealthTech Pros & FEAW Services Ltd