Version: 2.1.0 Last Updated: 2026-01-26 Applicability: All projects adopting Spec-Driven Development Scope: universal
This standard defines the principles and workflows for Spec-Driven Development (SDD), ensuring that changes are planned, documented, and approved via specifications before implementation.
Key Benefits:
- Reduced miscommunication between stakeholders and developers
- Clear audit trail for all changes
- Easier onboarding for new team members
SDD (Spec-Driven Development, 2025) is an AI-era methodology distinct from the traditional TDD/BDD/ATDD family. It emerged from the increasing adoption of AI-assisted development tools and the need for specification-first approaches in modern software engineering.
| Methodology Family | Era | Core Literature | Relationship |
|---|---|---|---|
| TDD/BDD/ATDD | 1999-2011 | GOOS (Freeman & Pryce), Dan North, Gojko Adzic | Traditional test-driven development family |
| SDD (2025) | 2025+ | Thoughtworks, GitHub spec-kit, Martin Fowler | AI-era emerging concept, independent from traditional family |
SDD is not part of the "ATDD → BDD → TDD" sequence. Instead, it generates test artifacts through Forward Derivation but remains a separate methodology.
| Methodology | Origin | Focus | SDD Integration |
|---|---|---|---|
| TDD | 1999, Kent Beck | Code-level tests | Can be used during SDD Implementation phase |
| BDD | 2006, Dan North | Behavior scenarios | Forward Derivation generates .feature files |
| ATDD | 2003-2006, GOOS | Collaborative acceptance | Optional input method for AC definition |
┌─────────────────────────────────────────────────────────────────────────────┐
│ Two Independent Methodological Systems │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────┐ │
│ │ SDD (AI-Era Methodology) │ │
│ │ │ │
│ │ Requirements → SPEC.md → Forward │ │
│ │ Derivation → Tests │ │
│ │ │ │
│ │ • Spec is authoritative source │ │
│ │ • AI-assisted code generation │ │
│ │ • Forward Derivation generates │ │
│ │ test structures │ │
│ └─────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Double-Loop TDD (Traditional) │ │
│ │ │ │
│ │ BDD (Outer Loop) → TDD (Inner Loop)│ │
│ │ │ │
│ │ • Tests drive design │ │
│ │ • Manual development │ │
│ │ • ATDD is optional collaboration │ │
│ │ input, not a sequential step │ │
│ └─────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Based on Martin Fowler's analysis of SDD tools (2025), teams can operate at different maturity levels:
| Level | Name | Description | Human Role |
|---|---|---|---|
| 1 | Spec-first | Write spec, discard after completion | Edit spec and code |
| 2 | Spec-anchored | Maintain spec throughout evolution | Edit spec, AI assists code |
| 3 | Spec-as-source | Spec is only source, code auto-generated | Only edit spec, never touch code |
Level 1: Spec-first
- Specifications written before implementation
- Specs may be discarded after feature completion
- Code remains the authoritative source
- Most common in 2025
Level 2: Spec-anchored
- Specifications maintained throughout the lifecycle
- Specs used for evolution and maintenance
- AI assists with code changes based on spec updates
- Growing adoption in enterprise environments
Level 3: Spec-as-source
- Specifications are the only source of truth
- Code is marked as "GENERATED - DO NOT EDIT"
- Any change requires spec modification first
- Still experimental in 2025
- Thoughtworks: Spec-Driven Development
- Martin Fowler: SDD Tools (Kiro, spec-kit, Tessl)
- GitHub spec-kit
Avoid these common pitfalls when adopting SDD:
| Pitfall | Problem | Mitigation |
|---|---|---|
| Over-formalization | Slows feedback like waterfall development | Keep iterative, use short cycles |
| Spec Drift | Spec and code become out of sync | Continuous validation, drift detection in CI/CD |
| AI Hallucination | AI generates code that doesn't match spec | Robust verification, contract testing |
| Size Mismatch | Using heavy workflow for small bugs | Choose appropriate process based on complexity |
| Premature Optimization | Jumping to Spec-as-source (Level 3) | Start with Spec-first, evolve gradually |
| Scenario | Recommendation |
|---|---|
| Critical hotfixes | Fix first, document later |
| Typos and formatting | Direct commit, no spec needed |
| Exploratory prototypes | Skip formal specs, iterate quickly |
| Small bug fixes (< 30 min) | Lightweight tracking only |
Before starting the SDD workflow, evaluate the nature and scope of the change. This prevents over-engineering and ensures changes are routed appropriately.
New Requirement/Change
│
▼
┌─────────────────────────────────────────────────────────┐
│ Q1: What is the scope of this change? │
│ 這個變更的適用範圍是什麼？ │
├─────────────────────────────────────────────────────────┤
│ A) Project-specific internal use only │
│ → Add to CLAUDE.md or project config │
│ → No Core Standard needed │
│ │
│ B) Reusable rule for other projects │
│ → Create Core Standard │
│ → Evaluate if Skill/Command is needed │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Q2: Does this feature require AI interaction? │
│ 這個功能需要 AI 互動嗎？ │
├─────────────────────────────────────────────────────────┤
│ A) Needs interactive workflow │
│ → Create Skill │
│ → Evaluate if Slash Command is needed │
│ │
│ B) Static rule / background knowledge │
│ → Core Standard only │
│ → Reference in CLAUDE.md │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Q3: Does the user need to trigger this directly? │
│ 使用者需要直接觸發嗎？ │
├─────────────────────────────────────────────────────────┤
│ A) Needs /command trigger │
│ → Create Slash Command │
│ │
│ B) AI applies automatically │
│ → Skill only, no Command needed │
└─────────────────────────────────────────────────────────┘
| Evaluation Result | Artifacts to Create |
|---|---|
| Project-specific only | CLAUDE.md update only |
| Universal static rule | Core Standard + CLAUDE.md reference |
| Universal interactive | Core Standard + Skill |
| User-triggered workflow | Core Standard + Skill + Command |
Use these tags in spec documents to indicate scope:
| Tag | Meaning | Example |
|---|---|---|
[Scope: Project] |
Project-specific, not for distribution | CI/CD config, team conventions |
[Scope: Universal] |
Reusable by other projects | Coding standards, testing patterns |
[Scope: Utility] |
Tool/generator, no Core Standard needed | docs-generator, code-formatter |
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Discuss │───▶│ Proposal │───▶│ Review │───▶│Implementation│
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
│
▼
┌──────────────┐ ┌──────────────┐
│ Archive │◀───│ Verification │
└──────────────┘ └──────────────┘
| Stage | Description | Artifacts |
|---|---|---|
| Discuss | Capture gray areas, lock scope, build read_first list | Scope definition, canonical refs |
| Proposal | Define what to change and why | proposal.md |
| Review | Stakeholder approval | Review comments, approval record |
| Implementation | Execute the approved spec | Code, tests, docs |
| Verification | Confirm implementation matches spec (max 3 iterations) | Test results, traceability matrix |
| Archive | Close and archive the spec | Archived spec with links to commits/PRs |
When working with specifications and their implementations, always evaluate what needs to be synchronized. Changes can originate from any artifact and should propagate to related artifacts.
| Change Origin | Evaluate Sync To |
|---|---|
| Core Standard | → Skills, Commands, AI YAML, Translations |
| Skill | → Core Standard (if applicable), Commands, Translations |
| Command | → Skill, Core Standard (if applicable), Translations |
Include this checklist in spec documents:
## Sync Checklist
### Starting from Core Standard
- [ ] Create/update corresponding Skill? (if interactive)
- [ ] Create/update Slash Command? (if user-triggered)
- [ ] Update translations? (zh-TW, zh-CN, etc.)
- [ ] Update AI YAML version? (if applicable)
### Starting from Skill
- [ ] Should this Skill have a Core Standard?
- [ ] If utility Skill (e.g., docs-generator), mark as "[Scope: Utility]"
- [ ] Create Slash Command?
- [ ] Update translations?
### Starting from Command
- [ ] Which Skill does this Command belong to?
- [ ] Update Skill documentation?
- [ ] Update translations?Use these markers in documentation to indicate sync status:
| Marker | Meaning |
|---|---|
[Synced: ✓] |
All related artifacts are synchronized |
[Synced: Pending] |
Sync needed but not yet completed |
[Synced: N/A] |
No related artifacts to sync (e.g., standalone utility) |
Rule: When an SDD tool (such as OpenSpec, Spec Kit, etc.) is integrated and provides specific commands (e.g., slash commands like /openspec or /spec), AI assistants MUST prioritize using these commands over manual file editing.
Rationale:
- Consistency: Tools ensure the spec structure follows strict schemas.
- Traceability: Commands often handle logging, IDs, and linking automatically.
- Safety: Tools may have built-in validation preventing invalid states.
Example:
- ✅ Use
/openspec proposal "Add Login"instead of manually creatingchanges/add-login/proposal.md.
Rule: SDD is a methodology, not bound to a single tool. While OpenSpec is a common implementation, these standards apply to any SDD tool (e.g., Spec Kit).
Guidelines:
- Universal Flow: Discuss -> Proposal -> Review -> Implementation -> Verification -> Archive.
- Tool Adaptation: Adapt to the specific commands and patterns of the active SDD tool in the workspace.
Rule: No functional code changes shall be made without a corresponding approved specification or change proposal.
Exceptions:
- Critical hotfixes (restore service immediately, document later).
- Trivial changes (typos, comments, formatting).
# [SPEC-ID] Feature Title
## Summary
Brief description of the proposed change.
## Motivation
Why is this change needed? What problem does it solve?
## Detailed Design
Technical approach, affected components, data flow.
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Dependencies
List any dependencies on other specs or external systems.
## Risks
Potential risks and mitigation strategies.When implementing an approved spec, reference the spec ID in commit messages:
feat(auth): implement login feature
Implements SPEC-001 login functionality with OAuth2 support.
Refs: SPEC-001
Before checking in code for a spec:
- ✅ Spec is approved
- ✅ Implementation matches spec
- ✅ Tests cover acceptance criteria
- ✅ Spec ID referenced in PR
Reviewers should verify:
- Change matches approved spec
- No scope creep beyond spec
- Spec acceptance criteria met
| Tool | Description | Command Examples |
|---|---|---|
| OpenSpec | Specification management | /openspec proposal, /openspec approve |
| Spec Kit | Lightweight spec tracking | /spec create, /spec close |
| Manual | No tool, file-based | Create specs/SPEC-XXX.md manually |
- ✅ Keep specs focused and atomic (one change per spec)
- ✅ Include clear acceptance criteria
- ✅ Link specs to implementation PRs
- ✅ Archive specs after completion
- ❌ Start coding before spec approval
- ❌ Modify scope during implementation without updating spec
- ❌ Leave specs in limbo (always close or archive)
- ❌ Skip verification step
For existing codebases without specifications, use Reverse Engineering Standards to generate SDD-compatible proposal drafts.
┌─────────────────────────────────────────────────────────────────────────┐
│ Reverse Engineering → SDD Pipeline │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Existing Code │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ /reverse-spec │ │
│ │ • Code scanning → Technical inventory [Confirmed] │ │
│ │ • Test analysis → Acceptance criteria [Confirmed/Inferred]│ │
│ │ • Gap identification → [Unknown] items │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ DRAFT SPEC (Reverse-Engineered) │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ SDD Review Process │ │
│ │ • Human fills [Unknown] sections (motivation, risks) │ │
│ │ • Stakeholder validation of [Inferred] items │ │
│ │ • Formal approval │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ APPROVED SPEC → Normal SDD workflow continues │
│ │
└─────────────────────────────────────────────────────────────────────────┘
When a specification is generated via reverse engineering:
- Mark Status: Include
Status: Draft (Reverse-Engineered)in metadata - Fill Unknowns: All
[Unknown]sections MUST be filled by humans before approval - Validate Inferences: All
[Inferred]items must be reviewed and confirmed - Standard Review: Follow normal SDD review process before implementation
- Source Citations: Maintain file:line references for traceability
| Scenario | Approach |
|---|---|
| Legacy system modernization | Start with reverse engineering |
| Documenting undocumented code | Generate specs from code |
| New team onboarding | Extract specifications for knowledge transfer |
| Pre-refactoring documentation | Create specs before major changes |
| Command | Purpose |
|---|---|
/reverse-spec |
Generate SDD specification from existing code |
/reverse-bdd |
Convert acceptance criteria to Gherkin scenarios |
/reverse-tdd |
Analyze test coverage against BDD scenarios |
After a specification is approved, use Forward Derivation Standards to automatically generate BDD scenarios, TDD test skeletons, and ATDD acceptance tests from the Acceptance Criteria.
┌─────────────────────────────────────────────────────────────────────────┐
│ Approved Spec → Forward Derivation Pipeline │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ APPROVED SPEC-XXX.md │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ /derive-all specs/SPEC-XXX.md │ │
│ │ • Parse Acceptance Criteria │ │
│ │ • Transform AC → Gherkin scenarios [Generated] │ │
│ │ • Generate TDD test skeletons [Generated] │ │
│ │ • Create ATDD acceptance tables [Generated] │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ OUTPUT FILES │
│ ├── features/SPEC-XXX.feature (BDD) │
│ ├── tests/SPEC-XXX.test.ts (TDD) │
│ └── acceptance/SPEC-XXX-acceptance.md (ATDD) │
│ │ │
│ ▼ │
│ HUMAN REVIEW → BDD/TDD workflow continues │
│ │
└─────────────────────────────────────────────────────────────────────────┘
| Scenario | Approach |
|---|---|
| Spec approved, starting implementation | Use /derive-all to generate test structures |
| Need BDD scenarios quickly | Use /derive-bdd for Gherkin generation |
| Starting TDD workflow | Use /derive-tdd for test skeletons |
| Manual acceptance testing | Use /derive-atdd for test tables |
| Command | Input | Output | Purpose |
|---|---|---|---|
/derive-bdd |
SPEC-XXX.md | .feature | AC → Gherkin scenarios |
/derive-tdd |
SPEC-XXX.md | .test.ts | AC → Test skeletons |
/derive-atdd |
SPEC-XXX.md | acceptance.md | AC → Test tables |
/derive-all |
SPEC-XXX.md | All above | Full derivation pipeline |
/derive-contracts |
SPEC-XXX.md | contract.json, schema.json | AC → Contract verification |
SDD requires robust verification mechanisms to ensure generated code aligns with specifications. The Validation Layer provides continuous verification throughout the development lifecycle.
| Theory | Source | Application in SDD |
|---|---|---|
| Design by Contract | Bertrand Meyer, 1986 | AC as pre/post conditions |
| Formal Verification | Computer Science | Spec vs Implementation |
| Specification by Example | Gojko Adzic, 2011 | Executable specifications |
| Contract Testing | Pact, 2013+ | Service contract verification |
| Mechanism | Purpose | Tools |
|---|---|---|
| Contract Testing | Verify implementation honors interface guarantees | Pact, Spring Cloud Contract, Specmatic |
| Schema Validation | Reject payloads violating structural requirements | JSON Schema, OpenAPI validators |
| Drift Detection | Detect divergence between spec and behavior | CI/CD integration, Specmatic |
| Backward Compatibility | Classify changes as additive/breaking | OpenAPI diff tools |
┌─────────────────────────────────────────────────────────────────────────────┐
│ SDD Validation Layer │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ SPEC-XXX.md (Approved) │
│ │ │
│ ├──→ Forward Derivation │
│ │ │ │
│ │ ├──→ Contract Tests (generated) │
│ │ ├──→ Schema Validators (generated) │
│ │ ├──→ BDD Scenarios (generated) │
│ │ └──→ TDD Skeletons (generated) │
│ │ │
│ └──→ Implementation (AI-assisted) │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Continuous Verification │ │
│ │ ┌─────────────────────────────────────────────────┐│ │
│ │ │ Contract Tests ✓/✗ ││ │
│ │ │ Schema Validation ✓/✗ ││ │
│ │ │ Drift Detection ✓/✗ ││ │
│ │ │ BDD Scenarios ✓/✗ ││ │
│ │ │ TDD Unit Tests ✓/✗ ││ │
│ │ └─────────────────────────────────────────────────┘│ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Verification Report → Archive or Iterate │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
| Artifact | Purpose | Verification Role |
|---|---|---|
.feature (BDD) |
Behavior scenarios | Acceptance verification |
.test.ts (TDD) |
Unit test skeletons | Implementation verification |
acceptance.md (ATDD) |
Acceptance test tables | Business verification |
contract.json |
Contract definitions | Interface verification |
schema.json |
Schema definitions | Structure verification |
- Verification (Building it right): Contract tests pass, schema valid, code matches spec
- Validation (Building right thing): AC met, stakeholder approval, business value delivered
- InfoQ: Spec-Driven Development - Validation Layer
- Microsoft: Consumer-Driven Contract Testing
- Wikipedia: Formal Verification
- Specmatic: AI-powered API Contract Testing
SDD verification is grounded in established testing theory:
Design by Contract (1986) Specification by Example (2011)
│ │
▼ ▼
┌───────────────────────────────────────────────────────────────┐
│ SDD Verification Model │
│ │
│ Spec (AC) ←──→ Contract Tests ←──→ Implementation │
│ ↑ ↑ ↓ │
│ Pre/Post Verification Runtime │
│ Conditions Mechanisms Behavior │
└───────────────────────────────────────────────────────────────┘
| SDD Phase | Testing Integration | Theory |
|---|---|---|
| Spec Writing | AC = Pre/Post conditions | Design by Contract |
| Forward Derivation | Generate Contract Tests | Executable Specification |
| Implementation | TDD (optional) | Test-Driven Development |
| Verification | Contract Testing + Drift Detection | Runtime Verification |
| Archive | Test results as evidence | Traceability |
┌─────────────────────────────────────────────────────────────────────────────┐
│ Practical SDD Workflow │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【Input Sources】(Any of these) │
│ ├── Requirements interviews (most common) │
│ ├── Stakeholder emails/documents │
│ ├── Product Requirements Document (PRD) │
│ └── ATDD Workshop (optional collaboration) │
│ ↓ │
│ 【SDD Proposal Writing】 │
│ SPEC-XXX.md includes: │
│ - Summary, Motivation │
│ - Detailed Design │
│ - Acceptance Criteria (Given-When-Then) │
│ - Dependencies, Risks │
│ ↓ │
│ 【Review & Approval】 │
│ ↓ │
│ 【Forward Derivation】 │
│ /derive-all → .feature, .test.ts, acceptance.md, contract.json │
│ ↓ │
│ 【Implementation】(TDD optional) │
│ ↓ │
│ 【Verification】→ 【Archive】 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
- ATDD Workshop is Optional: Not every feature needs a formal workshop
- Spec is the Starting Point: Regardless of input source, convert to SPEC-XXX.md
- Given-When-Then Embedded: AC format borrows from BDD, but doesn't require formal ATDD process
- Forward Derivation Fills Gaps: Auto-generates test structures, compensating for lack of workshops
This standard works together with two complementary standards to form a complete specification ecosystem:
┌─────────────────────────────────────────────────────────────────────────┐
│ SDD Ecosystem Integration │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Legacy Code New Feature │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Reverse │ │ SDD │ │
│ │ Engineering │ │ (This Standard) │ │
│ │ Standards │ │ │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ │ Code → Spec │ Spec First │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ SPEC-XXX.md │ │
│ │ (Approved Specification) │ │
│ └──────────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Forward Derivation Standards │ │
│ │ │ │
│ │ Spec → BDD (.feature) │ │
│ │ Spec → TDD (.test.ts) │ │
│ │ Spec → ATDD (acceptance.md) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
When to Use Each:
| Scenario | Starting Point | Standard to Use |
|---|---|---|
| New feature development | Nothing exists | SDD → Forward Derivation |
| Documenting existing code | Code exists, no spec | Reverse Engineering → SDD |
| Adding tests to existing code | Spec exists | Forward Derivation |
| Major refactoring | Code exists, unclear behavior | Reverse Engineering → SDD → Forward Derivation |
- Forward Derivation Standards - Specification-to-test transformation (Spec → BDD/TDD/ATDD)
- Reverse Engineering Standards - Code-to-specification transformation (Code → Spec)
- Test-Driven Development - TDD workflow and SDD integration
- Behavior-Driven Development - BDD workflow with Given-When-Then scenarios
- Acceptance Test-Driven Development - ATDD workflow for business acceptance
- Testing Standards - Testing framework and best practices (or use
/testing-guideskill) - Test Completeness Dimensions - 8-dimension test coverage
- Commit Message Guide - Commit message conventions
- Code Check-in Standards - Code check-in requirements
- Code Review Checklist - Code review guidelines
- Documentation Structure - Documentation structure standards
| Version | Date | Changes |
|---|---|---|
| 2.1.0 | 2026-01-26 | Added: Change Evaluation (Pre-SDD Assessment) section with decision tree, Bidirectional Sync Assessment section with sync matrix and checklist |
| 2.0.0 | 2026-01-25 | Major refactor: Added SDD as Independent Methodology section (separating SDD from TDD/BDD/ATDD family), Maturity Levels (Martin Fowler 2025), Common Pitfalls, Validation Layer with theoretical foundation, SDD + Testing Integration Model, /derive-contracts command |
| 1.4.0 | 2026-01-19 | Added: Integration with Forward Derivation section, derive commands |
| 1.3.0 | 2026-01-19 | Added: Integration with Reverse Engineering section, related commands |
| 1.2.0 | 2026-01-05 | Added: IEEE 830-1998 and SWEBOK v4.0 Chapter 1 (Software Requirements) to References |
| 1.1.0 | 2025-12-24 | Added: Workflow diagram, Spec template, Integration guide, Best practices, Related standards, License |
| 1.0.0 | 2025-12-23 | Initial SDD standard definition |
- Thoughtworks: Spec-Driven Development
- Martin Fowler: SDD Tools (Kiro, spec-kit, Tessl)
- GitHub spec-kit
- InfoQ: Spec-Driven Development
- OpenSpec Documentation
- Design Documents Best Practices
- ADR (Architecture Decision Records)
- IEEE 830-1998 - Software Requirements Specifications - Requirements documentation standard
- SWEBOK v4.0 - Chapter 1: Software Requirements - IEEE Computer Society
- Design by Contract - Bertrand Meyer, 1986 - Pre/post conditions theory
- Wikipedia: Formal Verification - Formal verification theory
- Microsoft: Consumer-Driven Contract Testing - Contract Testing framework
- Specmatic: AI-powered API Contract Testing - Modern contract testing tool
- Gojko Adzic: Specification by Example - Executable specifications (2011)
This standard is released under CC BY 4.0.