Engineering Constitution Template

Use this template to define the rules that every spec, design, task plan, and AI coding request must respect. It is the small policy layer that keeps SDD consistent across a team.

constitution.md

# Engineering Constitution

Owner:
Applies to:
Last reviewed:

## Principles
- Specs before risky implementation.
- Acceptance criteria must be observable.
- Evidence is required before merge for high-risk changes.
- AI-generated code must stay inside approved scope.

## Required Gates
- Spec review:
- Design review:
- Test evidence:
- Release stop signal:

## AI Coding Rules
- Allowed context:
- Allowed files:
- Non-goal handling:
- Evidence summary:

## Exceptions
- Allowed exception:
- Required approver:
- Follow-up review date:

When to use this template

A team wants SDD to be a working agreement, not only a set of templates.
AI coding tools are used by multiple people and need consistent guardrails.
Review quality varies because nobody knows which evidence is required.
Leads need a lightweight policy that can live in a repo.

What a filled version looks like

The template becomes useful after it carries a real decision, owner, and evidence. This is the level of specificity to aim for.

## Required Gates
- Payment, auth, migration, and public API changes require spec review.
- AI-generated code must include an evidence summary and test command.
- Release stops when the metric listed in evidence.md crosses the threshold.

Review before implementation

Principles are concrete enough to affect review behavior.
Required gates distinguish low-risk and high-risk work.
AI rules name allowed context, files, and evidence.
Exceptions require an approver and follow-up date.

Weak vs strong wording

Weak

Write good specs and use AI responsibly.

Strong

Payment, auth, migration, and public API changes require a reviewed spec, a linked evidence log, and a release stop signal. AI-generated diffs must list allowed files, changed files, and acceptance criteria covered.

FAQ

Is this too formal for a small team?

It can be short. A useful constitution may be under one page if it names the few rules the team will actually enforce.

Where should it live?

Keep it in the repo or team handbook, then link it from templates, PR descriptions, and AI coding instructions.

How often should it change?

Review it after incidents, repeated review misses, or tooling changes. Do not rewrite it just for wording polish.

Related resources

Editorial note

This template is written for spec-driven development workflows. The example is illustrative and should be adapted to your domain.

Author: Daniel Marsh
Editorial policy: How we review and update content

Tip: keep it under /docs/specs/ or /.specs/, then update it in the same pull request as implementation changes. Last updated: May 11, 2026.