Specifications give direction.
The process checks delivery.
The SDD Kit connects specifications to stories, contracts and executable checks. It helps your teams and coding agents follow what was agreed and record evidence of each delivery.
AN .SDD/ KIT FROM SUPPORTED ASSESSMENTS OR CREATE SPEC
SDD Kit 3.1.0 reference. Roles and dimensions checked in the source. Mutation, rule-enforcement and calibration results documented on August 13, 2026.
Why now
Three forces converged between 2025 and 2026 — and turned governed specification from good practice into a requirement.
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.
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.
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.
A process your team can run
The kit includes Python tools built on the standard library, so process checks run inside your repository.
Integrity checks for the .sdd itself: required sections, contract limits and traceability for claims that still need validation.
Where the environment supports hooks, they restrict implementers from approving their own work or filling in their own QA evidence. Roles and their limits are explicit.
The sensor registry is executable data: each with command, criterion and blocking flag. QA does not approve a story without exit 0.
Project state is GENERATED from story frontmatter — and the check flags manual edits.
The quality canon arrives pinned by version and hash, with full chain verification. Updating requires human confirmation.
40 deliberate faults, one per sensor rule, verify that the checks detect the problems they are designed to catch.
The evaluator that checks for drift between specification and code follows an explicit rubric and blind calibration. It cannot issue a verdict without valid calibration.
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 mechanisms mapped for 24/26. Each article identifies its check. The remaining two are explicitly recorded decisions.
How to evaluate an SDD approach
Beyond writing specifications, ask how each tool connects context, implementation and verification. These are the criteria behind ArchGenerator’s SDD Kit.
| What to assess | How ArchGenerator addresses it |
|---|---|
| Specification before code | Specifications, acceptance criteria and an execution plan before implementation. |
| Multi-agent roles | Separate roles for planning, implementation, review and approval. |
| Authority enforced by mechanism (hooks) | Hooks restrict actions according to the responsible role. |
| Signed implementation contracts | Each story has a contract defining scope, deliverables and verification. |
| Executable sensors with a data registry | sensors.yaml records commands, acceptance criteria and blocking conditions. |
| Graded evidence per statement [A]/[P]/[Q] | Each claim distinguishes evidence, assumptions and open questions. |
| Process that verifies itself (mutants) | Mutation tests check whether sensors detect deliberately introduced faults. |
| Canon versioned with hash | canon.lock pins the version and hashes of quality references. |
| Specification born from a diagnosis of real code | Repository findings feed into stories, evidence and verification checks. |
| Bidirectional interoperability between formats | Import and export for Spec Kit, OpenSpec and Kiro, with documented conversion limits. |
| Open-source / community | The sdd-canon registry is public; the ArchGenerator platform is a commercial product. |
The ecosystem keeps evolving. Check the features available in the version your team uses and choose mechanisms that suit your context.
Explore the official documentation for other approaches:
From repository findings to executable work.
A kit can also start from a diagnosis of a real repository. This documented example connects security findings to implementation stories and remediation checks.
executable stories — criticals with a hotfix clause and the guardrail that stops the agent from refactoring along the way
finding details with the assessment evidence transcribed, advisory by advisory
dependency sensor EXECUTABLE out of the box — generated from the repository's real lockfiles
findings with presumed evidence become questions: validate before fixing
Your team or coding agent opens the kit, runs the bootstrap and receives prioritized work, supporting evidence and a definition of done.
Three real situations
"I inherited a legacy system with dozens of vulnerabilities and a junior team."
A technical assessment becomes a remediation kit: prioritized stories, urgent fixes first, supporting evidence and a dependency check ready to run. Scope rules help prevent unrelated refactoring during the fix.
"The audit asked how we govern AI-generated code."
Story contracts, traceable evidence, executable checks and independent review provide a process record that can support an audit.
"The consultant delivered the diagnosis and left — now what?"
The assessment can become an implementation kit with priorities, evidence and acceptance criteria. Your team gets a starting point for carrying out the recommendations.
The SDD Kit connects specifications and repository evidence with a verifiable process, while preserving interoperability with your team’s tools.
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.
17 quality dimensions based on public references (WCAG, CWE Top 25, OWASP, Well-Architected), with a versioned SAST rule set from permissively licensed sources.
Teams already on Spec Kit, OpenSpec or Kiro come in and out with declared loss — no lock-in.
Updating the canon inside the kit requires human confirmation. An agent cannot approve that update on its own.
See the kit born from your own code.
For supported assessments with the feature enabled, recommendations from your repository can become an executable kit, with stories, acceptance criteria, and checks based on evidence from your system.