This document describes the constitutional governance system that enforces architectural discipline across all Spec-Driven Development workflows. The constitution (memory/constitution.md) defines 9 immutable principles that govern how specifications become code, preventing over-engineering and ensuring consistency. This page covers the constitutional articles, template-based enforcement mechanisms, validation gates, and the compliance verification process.
For information about creating the initial constitution file, see /speckit.constitution Command. For details on how constitutional validation integrates into planning, see /speckit.plan Command. For the broader SDD methodology, see Core Concepts and Methodology.
The constitution exists as a single immutable document that serves as the architectural DNA for all generated implementations. It is stored at memory/constitution.md and defines principles that every specification, plan, and implementation must respect.
Sources: spec-driven.md274-407
The constitution follows a formal legal document structure with numbered articles, sections, and subsections:
memory/constitution.md
├── Preamble
├── Article I: Library-First Principle
├── Article II: CLI Interface Mandate
├── Article III: Test-First Imperative
├── Article IV: Documentation Standards
├── Article V: Error Handling Requirements
├── Article VI: Configuration Management
├── Article VII: Simplicity Gate
├── Article VIII: Anti-Abstraction Gate
├── Article IX: Integration-First Testing
└── Section 4.2: Amendment Process
The document acts as compile-time validation for architectural decisions, ensuring that AI-generated implementations maintain quality and consistency.
Sources: spec-driven.md274-283
Diagram: Constitutional Integration with SDD Workflow
The constitution acts as a validation gate during the planning phase, ensuring that technical decisions align with architectural principles before implementation begins.
Sources: spec-driven.md88-94 spec-driven.md274-407
Every feature must begin as a standalone library before integration into application code. This enforces modular design and reusability from the start.
Key Requirements:
Enforcement: The spec template prevents implementation details from appearing in specifications, maintaining proper abstraction levels.
Sources: spec-driven.md283-293
All libraries must expose functionality through text-based command-line interfaces, ensuring observability and testability.
Key Requirements:
This article prevents opaque functionality and ensures all behavior is verifiable through text-based interfaces.
Sources: spec-driven.md295-306
The most transformative principle—no implementation code before comprehensive tests exist and fail.
Test Creation Order:
Non-Negotiable Requirements:
This completely inverts traditional AI code generation by forcing behavior definition before implementation.
Sources: spec-driven.md308-320
These articles establish baseline quality requirements:
Article IV: Documentation Standards
Article V: Error Handling Requirements
Article VI: Configuration Management
Sources: spec-driven.md274-407
Enforces minimal complexity through concrete limits:
Section 7.3: Minimal Project Structure
Gate Questions:
Sources: spec-driven.md322-333
Prevents unnecessary abstraction layers and over-engineering:
Section 8.1: Framework Trust
Gate Questions:
This article combats the AI tendency to create elaborate abstractions by forcing justification for every layer.
Sources: spec-driven.md322-333
Prioritizes realistic testing over isolated unit tests:
Testing Requirements:
This ensures generated code works in practice, not just in isolated theory.
Sources: spec-driven.md335-347
Constitutional principles are operationalized through structured templates that constrain LLM output.
The spec template enforces proper abstraction levels:
These constraints prevent premature implementation details and force explicit uncertainty markers when information is missing.
Sources: spec-driven.md169-191
Diagram: Plan Template Constitutional Enforcement
The plan template includes explicit phase gates that halt implementation if constitutional principles are violated without justification.
Sources: spec-driven.md207-224 spec-driven.md350-373
Templates include self-review checklists that act as quality gates:
| Checklist Section | Constitutional Article | Validation Questions |
|---|---|---|
| Requirement Completeness | Article III | No [NEEDS CLARIFICATION] markers remain? |
| Test Coverage | Article III | Tests written first? Contract tests defined? |
| Simplicity | Article VII | ≤3 projects? No future-proofing? |
| Abstraction | Article VIII | Framework features used directly? |
| Integration | Article IX | Real dependencies used in tests? |
These checklists force LLMs to systematically verify constitutional compliance.
Sources: spec-driven.md193-206
Before implementation begins, three constitutional gates must pass or receive justified exceptions:
Diagram: Phase Gate Validation Flow
Sources: spec-driven.md350-373
When a gate fails, the system requires documented justification rather than blocking progress:
This creates accountability for architectural decisions without preventing necessary complexity.
Sources: spec-driven.md350-373
Diagram: Constitutional Validation Sequence
Sources: spec-driven.md88-94
The constitution is enforced through multiple system components:
| Component | Location | Constitutional Role |
|---|---|---|
| Constitution File | memory/constitution.md | Source of truth for principles |
| Spec Template | templates/spec-template.md | Enforces abstraction levels (Article I) |
| Plan Template | templates/plan-template.md | Enforces phase gates (Articles VII-IX) |
| /speckit.plan | Command logic | Validates plan against constitution |
| /speckit.constitution | Command logic | Creates initial constitution file |
Sources: spec-driven.md274-407
While principles are immutable, their interpretation can evolve:
This allows learning from real-world experience while maintaining stability.
Sources: spec-driven.md385-396
Amendments are dated and include rationale, enabling constitutional evolution while preserving historical context.
Sources: spec-driven.md385-396
The constitutional system provides three levels of consistency:
Sources: spec-driven.md374-382
| Principle | Quality Guarantee |
|---|---|
| Library-First (Article I) | Modularity and reusability |
| CLI Interface (Article II) | Observability and testability |
| Test-First (Article III) | Correctness and regression prevention |
| Simplicity Gate (Article VII) | Maintainability and comprehension |
| Anti-Abstraction (Article VIII) | Direct problem-solving without layers |
| Integration-First (Article IX) | Real-world reliability |
Sources: spec-driven.md374-382
The constitution specifically prevents AI-generated code from exhibiting common problems:
Sources: spec-driven.md397-406
The constitution must exist at memory/constitution.md within the project structure:
project-root/
├── memory/
│ └── constitution.md # 9 Articles of Development
├── specs/
│ └── NNN-feature-name/
│ ├── spec.md
│ └── plan.md # References constitution during validation
└── templates/
├── spec-template.md # Enforces constitutional constraints
└── plan-template.md # Contains phase gates
Sources: spec-driven.md274-407
Constitutional validation integrates with these workflow commands:
/speckit.constitution: Creates initial memory/constitution.md file/speckit.plan: Validates plans against constitutional principles/speckit.tasks: Ensures tasks align with constitutional requirements/speckit.implement: Executes implementation following constitutional guidelinesSources: spec-driven.md76-104
Refresh this wiki