SRDD (Part 4 of 4): Scaling Up - SSRDD, Principles, and Implementation
← Back to SRDD entry page
This is Part 4 of a four-part series on Spec-Roundtrip Driven Development.
- 👉 Read Part 1: Why SRDD Exists
- 👉 Read Part 2: The AI Coding Landscape
- 👉 Read Part 3: The SRDD Workflow
Part 3 walked through the SRDD workflow: five phases, contracts as authority, the AI as scope guardian, and regeneration as a deliberate reset of understanding.
Where the earlier parts focus on failure modes and workflow, this final part focuses on durability: how SRDD holds up under scale, time, and organisational pressure.
This final article covers three things: how SRDD scales to multi-domain systems through Scaled SRDD (SSRDD), the principles that underpin the methodology, and the current state of implementation - what you can adopt today and what tooling is still planned.
Scaled SRDD (SSRDD)
For systems that extend beyond a single bounded context, SRDD scales into Scaled SRDD (SSRDD).
SSRDD is not a new methodology layered on top of SRDD. It is a coordination wrapper that allows multiple independent SRDD loops to coexist without collapsing into chaos or bureaucracy.
Each domain, service, or subsystem:
- owns its own planning artefacts
- runs its own SRDD cycles
- evolves at its own pace
- regenerates when its local signals demand it
No central plan attempts to predict how the whole system should evolve.
Instead, SSRDD introduces just enough structure at the system boundary to allow independent evolution without accidental entanglement.
System-Level Coordination
At the system level, SSRDD coordinates only what must be shared:
Shared constitutions
Agreed integration standards that define how domains present themselves to one another - API conventions, event schemas, versioning rules, and compatibility expectations. These govern interaction, not internal design.Explicit contracts
Public-facing APIs, events, and invariants are declared and versioned. Domains are free to change internally as long as these contracts hold or are deliberately evolved.Dependency visibility
What each domain consumes and produces is visible by design. Hidden couplings are surfaced early, before they calcify into architectural traps.Boundary drift detection
SSRDD watches for signs that domain boundaries are eroding - duplicated responsibilities, circular dependencies, creeping knowledge of internals - and flags these as candidates for regeneration or boundary renegotiation.
This combination is uncommon: most large systems either centralise architectural control to prevent drift, or decentralise teams without making drift visible at the system level. SSRDD does neither - it allows local autonomy while making architectural change observable rather than accidental.
Crucially, SSRDD does not synchronise development cadence, force shared tooling, or impose uniform internal practices. It coordinates interfaces and intent, not implementation.
SSRDD scales understanding, not bureaucracy.
Why SRDD Works
SRDD succeeds because it aligns with how complex systems actually evolve - not how we wish they would.
It acknowledges discovery
SRDD assumes that important knowledge arrives late. Instead of treating this as failure, it builds discovery into the process and gives it a disciplined place to land.It prevents specs from becoming fiction
Specs are continuously regenerated from reality, not left to rot as idealised narratives disconnected from the system that ships.It manages AI-induced technical debt at the design level
AI accelerates both construction and decay. SRDD counters this not by slowing AI down, but by periodically reasserting architectural intent before debt becomes destiny.It preserves tacit product wisdom
Decisions that would otherwise live only in heads or pull requests are captured, externalised, and made legible to both humans and machines.It restores human judgment where it belongs
AI executes, analyses, and enforces. Humans choose direction, recognise discomfort, and decide when a system needs to change course.
SRDD is not the fastest way to write code.
It is the fastest way to keep understanding intact - as systems grow, teams change, and years pass.
Boundary Enforcement via Dependency Permissions (SSRDD)
SSRDD does more than coordinate domains. It can enforce architectural boundaries.
The core rule is explicit:
If a domain does not declare that it consumes another domain, it cannot see it.
This model is closely analogous to Project Jigsaw (Java 9+).
Like Jigsaw, SSRDD treats boundaries as design-time and compile-time constraints, not as informal conventions. Domains must explicitly declare what they depend on and what they expose. Everything else is inaccessible by default.
Explicit dependency declarations
Each domain declares its dependencies in contracts/consumes.yaml:
consumes:
- identity-management/api-users
- inventory/api-stock
Controlled evolution of dependencies
In practice, dependency permissions in SSRDD are not universally mutable.
Domain developers typically do not have direct write access to the system-level SSRDD artefacts that define cross-domain dependencies - such as the shared constitution or dependency registry. Their focus remains local: implementing behaviour within declared boundaries.
Changes to domain dependencies are instead mediated at the system level, typically by architects or designated system stewards.
This mirrors the intent of Project Jigsaw: module boundaries are not something individual classes casually rewrite. They are structural decisions, owned at a higher level of abstraction.
Why this separation matters
Without this separation, boundaries decay quietly:
- A developer “just imports” another domain to save time
- A quick integration bypasses the contract layer
- A dependency is added for convenience and never removed
- Architectural coupling becomes invisible until it is irreversible
AI-assisted development amplifies this failure mode. When generation is cheap and fast, the path of least resistance is always cross-boundary access.
SSRDD deliberately resists this by making dependency changes explicit, reviewable, and intentional.
Developers still move quickly within their domain.
They simply cannot accidentally change the shape of the system.
In short: SSRDD treats dependency changes as architectural events, not implementation conveniences.
Architectural control without architectural bottlenecks
This is not about slowing teams down.
By centralising dependency authority:
- Domains remain autonomous within their scope
- Integration decisions are made with system-level visibility
- Boundary changes become conscious design moments
- Regeneration remains feasible because coupling stays controlled
The result is not bureaucracy - it is preserved optionality.
Architects are not approving code.
They are curating the shape in which code is allowed to grow.
SSRDD enforces boundaries the same way strong type systems enforce correctness:
not by trust, but by making the wrong thing impossible.
Principles
The principles that follow were crystallised in part through reflection on Craig Adam's article "Agile is Out, Architecture is Back" - a clear articulation of why architecture matters more, not less, in the age of AI-assisted development. His framing of the codebase as curriculum and the developer's evolving role helped sharpen what SRDD was already reaching toward. Thank you.
The five phases describe what happens in SRDD. This section describes why certain patterns recur across all of them.
These principles are not rules to be enforced. They are orientations - ways of thinking that make AI-assisted development more effective, more sustainable, and more aligned with human intent.
Designing for AI Comprehension
Your codebase is a curriculum. Every pattern teaches the AI what to repeat. Contradictions create confusion. Consistency creates velocity.
The AI learns your project not from training, but from context. It reads your existing code and generates more code that looks like it. This has profound implications.
Rules files instruct. Code demonstrates.
Your CLAUDE.md, cursor rules, and similar files tell the AI what to do. Your codebase shows what "right" looks like. Both matter - but when they conflict, the AI often follows what it sees over what it's told.
If your codebase contains:
- Multiple logging implementations → AI picks one randomly or invents another
- Inconsistent error handling → AI generates inconsistent error handling
- Mixed naming conventions → AI outputs mixed naming
- God classes alongside clean modules → AI might follow either pattern
The AI does not judge which pattern is correct. It pattern-matches on what exists.
This principle is LLM-agnostic: Every AI coding tool - Claude Code, Cursor, Copilot, Windsurf, and tools not yet built - reads your codebase into context. Keep your codebase clean and consistent because the AI will copy what it sees.
Applying this across SRDD
| Phase | Purpose | Application |
|---|---|---|
| Phase 1 | Establish intent | Define canonical patterns in ARCHITECTURE.md before implementation begins |
| Phase 2 | Build it | Correct deviations immediately; uncorrected deviations become new patterns |
| Phase 3 | Check fit | Review for pattern conformance, not just correctness |
| Phase 4 | Validate reality | Formalise production discoveries carefully; they become future examples |
| Phase 5 | Realign or continue | Consolidate contradictory patterns during regeneration |
Guardrails Beyond Tests
Use types, linters, schemas, and structure not just to enforce correctness - but to communicate intent.
Tests verify behaviour after the fact. Guardrails prevent bad patterns from entering in the first place. They operate earlier in the feedback loop, and they constrain what the AI can produce.
Types as documentation:
Strong typing (TypeScript, Zod schemas, Pydantic models) constrains AI output at generation time. A well-typed function signature tells the AI what shapes are valid before it writes a line of implementation.
Linters as guardrails:
ESLint rules, Prettier configurations, and architectural linters (like eslint-plugin-boundaries) reject code that violates conventions automatically. The AI learns quickly that certain patterns don't survive.
Schemas as contracts:
OpenAPI specs, JSON Schema, and similar declarations make contracts machine-readable. The AI can validate its output against them - and tools can reject non-conforming code before review.
Folder structure as architecture:
Where code lives communicates what it is. A clear directory structure - with boundaries that match domain concepts - helps the AI place new code appropriately. Ambiguous structure produces ambiguous placement.
These guardrails are not bureaucracy. They are force multipliers. Every constraint that prevents a bad pattern from entering is a constraint that doesn't need to be caught in review, fixed in testing, or cleaned up during regeneration.
Guardrails encode judgment structurally - not just in documentation.
Encode Judgment, Don't Just Document It
Structure that enforces decisions is stronger than documentation that describes them.
Documentation can be ignored. Structure cannot.
When a decision matters - when violating it would cause drift, inconsistency, or architectural decay - encode it in a way that makes violation difficult or impossible:
- Use folder boundaries to enforce module separation, not just naming conventions
- Use types to make invalid states unrepresentable, not just documented as "don't do this"
- Use linter rules to reject patterns automatically, not just style guides that request compliance
- Use CI checks to fail builds on violations, not just code review comments
The AI reads structure more reliably than prose. A linter rule that rejects a pattern is more effective than a CLAUDE.md instruction that discourages it.
This does not mean documentation is worthless. It means documentation is for explanation, not enforcement. Explain the "why" in docs. Enforce the "what" in structure.
The test: If the AI could violate a decision and still produce code that passes all checks, the decision is not yet encoded. It is merely suggested.
Coherence Over Correctness
Correct code that doesn't fit is worse than imperfect code that coheres.
The AI can produce code that works. That is table stakes. The harder problem is producing code that fits - that respects existing boundaries, follows established patterns, and doesn't introduce architectural debt.
A function can pass all tests and still:
- Use a different logging approach than the rest of the system
- Handle errors in a novel way that won't be replicated
- Introduce a dependency that violates layering
- Name things inconsistently with surrounding code
These are not test failures. They are coherence failures. They make the system harder to understand, harder to maintain, and harder for the AI to pattern-match correctly in future.
The reviewer's job is coherence: The AI handles correctness. The human ensures fit.
This requires architectural awareness - understanding not just whether the code works, but whether it belongs. That awareness is precisely what distinguishes a developer from a code generator.
The Developer Dreams, The AI Disciplines
Humans are for invention, imagination, and direction. Machines are for execution, analysis, and consistency.
SRDD deliberately assigns roles:
The developer:
- Decides what to build and why
- Makes architectural judgments
- Recognises when something feels wrong
- Chooses direction when trade-offs arise
- Dreams futures the AI cannot imagine
The AI:
- Executes implementation within constraints
- Guards scope and flags deviations
- Detects spaghettification signals
- Maintains consistency with established patterns
- Synthesises understanding during regeneration
The AI does not dream. It interpolates. It gravitates toward the statistical centre of its training data. Novel architectures, distinctive designs, and opinionated choices must come from humans.
But humans are fallible. They get bored. They take shortcuts. They expand scope opportunistically. The AI provides discipline: holding boundaries, asking clarifying questions, refusing to silently drift.
Neither is sufficient alone.
Together, they compound.
Specs Are Snapshots, Not Contracts
Specifications capture understanding at a moment in time. Code becomes the source of truth. Periodically, understanding must be extracted back out.
This is the foundational insight of SRDD.
Traditional spec-driven development treats specifications as authoritative: write the spec, generate the code, update the spec when requirements change. In practice, this breaks down. Code evolves faster than documentation. Implicit behaviours emerge. The spec becomes fiction.
SRDD inverts the relationship. Specs are inputs to a cycle, not outputs of a process. They capture intent at the start. But as implementation proceeds, the code becomes the real source of truth - informed by production discoveries, implicit contracts, and decisions made under pressure.
The roundtrip is what makes SRDD sustainable:
- Specs guide initial implementation
- Implementation reveals what specs missed
- Production surfaces implicit contracts
- Regeneration extracts new specs from living code
- The cycle repeats with compounded understanding
Without the roundtrip, specs drift into irrelevance. With it, understanding compounds instead of decaying.
Velocity Follows Clarity
Fast development is not the cause of good systems. It is the consequence of clear ones.
Teams do not ship slowly because they lack skill. They ship slowly because they lack confidence. Confidence erodes when:
- No one is sure what a change might break
- Boundaries have blurred beyond recognition
- Patterns contradict each other
- Tests defend structure rather than contracts
- Tribal knowledge has replaced explicit understanding
SRDD addresses velocity by addressing clarity. Regeneration restores architectural coherence. Contracts make guarantees explicit. Pattern hygiene ensures the AI produces consistent output. Guardrails prevent drift from entering.
The result is not just a cleaner codebase. It is a faster one - because developers (and AI) can act with confidence instead of caution.
Speed is earned, not demanded.
Summary
| Principle | Core Insight |
|---|---|
| Designing for AI Comprehension | The codebase teaches the AI what to repeat |
| Guardrails Beyond Tests | Prevent bad patterns earlier than review |
| Encode Judgment, Don't Just Document It | Structure enforces; documentation explains |
| Coherence Over Correctness | Fit matters more than function |
| The Developer Dreams, The AI Disciplines | Humans choose direction; machines maintain consistency |
| Specs Are Snapshots, Not Contracts | Understanding must roundtrip back from code |
| Velocity Follows Clarity | Confidence enables speed |
These principles are not optional.
SRDD's phases, guardrails, and regeneration cycles exist to enforce them - or surface it clearly when they're being violated.
Implementation
SRDD is currently a methodology, not a product. This section describes what exists today, what's planned, and what reliable enforcement will require.
Current Status
| Component | Status | Notes |
|---|---|---|
| Methodology documentation | ✅ Available | SRDD.md, SCALED-SRDD.md |
| Planning doc templates | ✅ Available | 00-07 document templates |
| Rules file examples | ✅ Available | CLAUDE.md templates for SRDD workflow |
| Scope enforcement tooling | 🔲 Planned | Pre-commit hooks, MCP integration |
| Coherence validation | 🔲 Planned | Pattern comparison against ARCHITECTURE.md |
| Regeneration advisor | 🔲 Planned | Cross-session signal tracking |
| SSRDD coordination layer | 🔲 Planned | Multi-subsystem orchestration |
The methodology can be adopted today using documentation and rules alone. Teams will capture significant value - better than vibe coding, better than undisciplined agentic work. But reliable enforcement of scope guarding, coherence review, and regeneration detection will require tooling that does not yet exist.
SRDD Implementation
What works with rules alone:
- TDD workflow: AI follows this well with clear instructions
- PR description format: templatable, AI complies
- Communication protocols: "ask before expanding scope" works reasonably
- Phase awareness: AI can be reminded which phase it's in
- Pattern following: works if good examples exist in the codebase
What needs tooling for reliable enforcement:
Scope enforcement: Pre-commit hooks or CI checks that validate files changed against declared issue scope. AI self-discipline is insufficient; hard blocks are required.
Coherence validation: CLI or MCP server that compares implementation against ARCHITECTURE.md patterns. Generates structured report for human review. Could integrate with PR process.
Pattern drift detection: Static analysis that scores conformance against canonical patterns. Custom linter rules or dedicated tool. Runs in CI, blocks on threshold violations.
Regeneration advisor: Tracks signals across sessions: contract change frequency, scope expansion requests, pattern drift indicators. Surfaces recommendations: "3 significant contract changes in 2 weeks - consider regeneration." Cannot rely on AI memory alone.
Planned tooling:
The table below outlines planned tooling that reinforces SRDD practices; the methodology already works today using rules files and process discipline, which cover roughly 60% of the model.
| Command | Purpose |
|---|---|
srdd check |
Validate current state against methodology |
srdd review-coherence |
Compare implementation against ARCHITECTURE.md |
srdd regeneration-status |
Surface signals that suggest regeneration |
MCP server integration for real-time checking within Claude Code, Cursor, and similar tools is a longer-term goal. This would make SRDD workflows smoother - the AI checks scope, patterns, and coherence before acting, rather than failing at commit or review. True enforcement still requires hard blocks at git and CI layers; MCP advises, it does not prevent.
Adoption without tooling:
Teams can adopt SRDD today by:
- Using the planning doc templates (00-07)
- Adding SRDD rules to their AI configuration (CLAUDE.md, .cursorrules, etc.)
- Following the phase workflow manually
- Relying on human review for coherence and scope discipline
This delivers 60-70% of the value. The remaining 30-40% - reliable enforcement without human vigilance - awaits tooling.
SSRDD Implementation
SSRDD wraps multiple SRDD instances with a coordination layer. Each subsystem runs its own SRDD cycle; SSRDD governs the boundaries between them.
Additional components required:
CONSTITUTION.md enforcement: Validation that subsystem contracts conform to system-wide standards. Not just documentation; automated checks.
Cross-subsystem dependency tracking: Visibility into which subsystems depend on which contracts. Change impact analysis before regeneration.
Coordinated regeneration: When one subsystem regenerates, affected subsystems are notified. Integration contracts are re-validated. Cascade effects are surfaced, not hidden.
System-wide coherence dashboard: Aggregates health signals across subsystems. Pattern drift in subsystem A, contract churn in subsystem B, integration test failures between C and D - visible in one place.
Current status:
SSRDD is documented as methodology. No tooling exists. Adoption today requires:
- Manual coordination between subsystem teams
- Disciplined maintenance of CONSTITUTION.md
- Human tracking of cross-subsystem dependencies
- Scheduled integration checkpoints
This is workable for small numbers of subsystems (2-4) with disciplined teams. Beyond that, tooling becomes essential.
Planned approach:
SSRDD tooling will build on SRDD tooling:
| Command | Purpose |
|---|---|
ssrdd status |
Health across all subsystems |
ssrdd check-constitution |
Validate subsystem compliance |
ssrdd impact-analysis <change> |
What subsystems are affected? |
ssrdd coordinate-regeneration |
Orchestrate multi-subsystem realignment |
Timeline: SRDD tooling first, SSRDD coordination layer second.
Roadmap
Alignment with Agile and SAFe:
SRDD is designed to complement, not replace, existing delivery frameworks. Future documentation will map SRDD phases to Agile ceremonies and SAFe constructs - showing how regeneration fits into PI planning, how Phase 5 triage aligns with backlog refinement, and how SSRDD coordinates across Agile Release Trains.
Rules file templates:
Complete CLAUDE.md, .cursorrules, and copilot-instructions.md templates that encode SRDD workflow, scope guarding, and pattern-following behaviour. Ready to drop into any project.
MCP server integration:
Real-time SRDD enforcement within Claude Code, Cursor, and similar tools. The AI checks scope, patterns, and coherence before acting. True enforcement still requires git and CI layers; MCP advises and surfaces signals continuously.
Kubernetes and container orchestration:
SSRDD's domain model maps naturally to microservices architectures. Future work will explore how SSRDD boundaries align with Kubernetes namespaces, how CONSTITUTION.md standards translate to service mesh policies, and how coordinated regeneration integrates with deployment pipelines. The goal is SSRDD as a design-time discipline that produces systems well-suited to container orchestration - not as an afterthought, but by construction.
Contributing
SRDD and SSRDD are open methodologies. The documentation, templates, and (eventually) tooling will be available for community use and contribution.
If you're interested in contributing to the tooling effort, or adopting SRDD in your organisation and sharing learnings, [contact information / repository link].
Closing
Vibe coding, agentic coding, context engineering, spec-driven development - each optimises for something real. Speed. Autonomy. Discipline. Traceability. None of them are wrong. But none of them close the loop.
Vibe coding forgets. Agentic coding echoes. Context engineering curates inputs but not outputs. Spec-driven development treats specifications as authoritative even as reality drifts away from them.
SRDD closes the loop.
What SRDD Enforces
The roundtrip is the methodology.
Specifications flow into implementation. Understanding flows back out through regeneration. This is not a rescue operation - it is a planned phase in the system's lifecycle.
Specs are snapshots, not contracts.
Specifications capture understanding at a point in time. Code becomes the source of truth. Periodically, understanding is extracted back out.
The codebase is a curriculum.
The AI learns from your existing code. Every pattern teaches it what to repeat. Contradictions breed confusion; consistency compounds velocity.
Guardrails encode judgment structurally.
Types, linters, schemas, and folder boundaries prevent bad patterns before review. Documentation explains; structure enforces.
Coherence matters more than correctness.
The AI determines whether code works. The reviewer determines whether it fits. Correct code that violates patterns degrades the system.
The developer dreams; the AI disciplines.
Humans choose direction, make architectural judgments, and recognise when something feels wrong. The AI executes, guards scope, and maintains consistency.
Velocity follows clarity.
Fast development is not the cause of good systems. It is the consequence of clear ones. Confidence enables speed.
At Scale
SSRDD extends these principles across domains:
- Boundaries become explicit
- Dependencies become intentional
- Domains evolve independently without silent entanglement
- Understanding scales - not bureaucracy
The Core Commitment
Every senior developer has stared at a system they once understood and thought: "If only I could burn this down and rebuild it properly - keeping everything we learned, but losing the accumulated mess."
SRDD makes that possible.
- Specs deserve a return ticket
- Boundaries deserve enforcement
- Judgment deserves to be structural
- Understanding deserves to survive
AI accelerates everything, including mistakes. SRDD exists to make learning faster than decay.
The Complete Series
- Part 1: Why SRDD Exists - The problem, the journey, the insight
- Part 2: The AI Coding Landscape - Vibe coding, agentic coding, context engineering, SDD
- Part 3: The SRDD Workflow - Phases, contracts, regeneration
- Part 4: Scaling Up - SSRDD, principles, implementation (this article)
© 2026 Brooke Smith. All rights reserved.
This document constitutes a public disclosure and defensive publication of the
Spec-Roundtrip Driven Development (SRDD) and Scaled SRDD (SSRDD) methodologies.
The author expressly places the concepts, processes, and workflows described
herein into the public domain as prior art, for the purpose of preventing
subsequent patent claims or exclusive ownership by third parties.
Commercial use, redistribution, or derivative works of this text require
explicit permission from the author.
Top comments (0)