SDD · Spec-Driven Development

The framework that makes coding agents follow the specification.

Planning before coding became the market standard. What no tool delivers is what comes after the plan: mechanical verification that the process was followed — contracts signed per story, executable sensors and evidence behind every statement.

DELIVERED AS AN .SDD/ KIT INSIDE BOTH PRODUCTS — TECHNICAL REPORT AND CREATE SPEC

stories/executable stories with acceptance criteria and a contract
specs/source-report/the diagnosis evidence, transcribed
sensors.yamlsensors as data: command, criterion, blocking flag
tools/Python code (pure stdlib) that enforces the governance
hooks/authority as mechanism: whoever implements does not approve
canon.lockquality canon pinned by version + hash
MANIFEST.sha256 · [email protected] · 231 files python3 · zero dependencies
27roles with enforced limits
17doctrine dimensions
291SAST rules in the rulepack
40mutants proving the sensors
24/26articles with mapped enforcement
12/12blind calibration of the drift judge
§ 01

Why now

Three forces converged between 2025 and 2026 — and turned governed specification from good practice into a requirement.

01

Generating code became cheap. Generating the right code did not.

When a feature costs minutes of agent time, the bottleneck moves from the keyboard to the intent. Describing vaguely and accepting whatever comes produces plausible code that drifts from the intent and ages badly.

02

Agents need process memory.

An agent opening a repository needs to know what was already decided, what is forbidden and how to prove something is done. Without that, every session reinvents the project.

03

Auditability became a business requirement.

AI-written code in production demands a trail: where each change came from, which evidence supported it, who approved it. SDD is the infrastructure of that trail.

§ 02

Not text — a harness with code inside

Inside the kit travels Python code (pure stdlib — runs on any machine with python3) that turns governance from recommendation into mechanism.

sdd_check

18 integrity rules over the .sdd itself — story missing a required section, contract over the limit, presumed claim without validation tracking. A fresh kit opens 100% green.

hooks

The hook BLOCKS whoever implemented from marking done or filling their own QA evidence. Not "the agent should" — "the agent cannot".

sensors.yaml

The sensor registry is executable data: each with command, criterion and blocking flag. QA does not approve a story without exit 0.

status_gen

Project state is GENERATED from story frontmatter — and the check flags manual edits.

canon.lock

The quality canon arrives pinned by version and hash, with full chain verification. Updating requires human confirmation.

sensor_mutation

40 saboteurs, one per sensor rule — mechanical proof that every sensor actually looks, not passing by vacuity.

spec_drift

The only non-deterministic judge (spec×code drift) is fenced: explicit rubric, blind calibration — no valid calibration, no verdict.

import / export

Bidirectional converters for Spec Kit / OpenSpec / Kiro, with documented loss in every converted file. In and out with no lock-in.

+ a Constitution of 25+1 articles with enforcement mapped at 24/26 — each article points to the mechanism that enforces it; the 2 without one are marked as recorded decisions, not oversights.

§ 03

The comparison, honestly

On the first two rows the market is tied — everyone writes specifications. Below the thick line, we are alone.

CapabilitySpec KitKiroOpenSpecBMADTesslArchGenerator
Specification before code
Multi-agent roles● 27
Authority enforced by mechanism (hooks)
Signed implementation contracts
Executable sensors with a data registry
Graded evidence per statement [A]/[P]/[Q]
Process that verifies itself (mutants)● 40
Canon versioned with hash● 17
Specification born from a diagnosis of real code
Bidirectional interoperability between formats
Open-source / community

● YES · ◐ PARTIAL · — NO

The last row is honest weakness: they have distribution and community; we have depth — and we talk to their tools in both directions.

§ 04

The kit is born from proof, not from a prompt

Every competitor starts from a natural-language description. Our kit is born from a diagnosis of the real repository — validated in production on a public repository.

SECURITY REPORT → REMEDIATION KIT REAL CASE · PUBLIC REPO
16

executable stories — criticals with a hotfix clause and the guardrail that stops the agent from refactoring along the way

38

finding details with the report evidence transcribed, advisory by advisory

sca ✓

dependency sensor EXECUTABLE out of the box — generated from the repository's real lockfiles

[P]→?

findings with presumed evidence become questions: validate before fixing

The client's team — or the client's coding agent — opens the kit, runs the bootstrap and has attack order, evidence and a definition of done. Without a planning meeting.

§ 05

Three real situations

"I inherited a legacy system with dozens of vulnerabilities and a junior team."

Report → remediation kit: prioritized stories with hotfix first, transcribed evidence, dependency gate ready — and the clause that stops the junior (or the agent) from refactoring along the way.

"The audit asked how we govern AI-generated code."

A complete trail by construction: signed contract → citable evidence → green sensor → independent approval enforced by hook. No other tool produces this trail.

"The consultant delivered the diagnosis and left — now what?"

The report points, the kit executes: the distance between the PDF and the executable backlog is one click. A category that does not exist among competitors — none has a diagnosis engine to start from.

While the market competes over who writes the best specification before the code, ArchGenerator delivers the only one that arrives loaded with evidence from the real code, with a process that verifies itself — and that still talks to the competitors' tools in both directions.
§ 06

The canon is public

The quality doctrine the kit carries is not a black box: the sdd-canon registry is public, versioned, with a hash per file and a declared license on every rule.

sdd-canon 0.3.0

17 dimensions anchored in public standards (WCAG, CWE Top 25, OWASP, Well-Architected) + a SAST rulepack of 291 rules from 8 permissive sources.

import / export

Teams already on Spec Kit, OpenSpec or Kiro come in and out with declared loss — no lock-in.

--yes

Updating the canon inside the kit requires human confirmation — an agent never passes alone.

See the kit born from your own code.

A technical report of your repository becomes an executable kit — with the stories, the sensors and the evidence of your system, not of an example.

Book a demo