Handbook
SDD I/O schema — ceremonies & process slots
**Purpose:** Define a **repeatable, machine- and human-friendly** shape for specifying **inputs, outputs, preconditions, and artifacts** for any **ceremony intent (C1–C6)** or **named process slot** (
SDD I/O schema — ceremonies & process slots
Purpose: Define a repeatable, machine- and human-friendly shape for specifying inputs, outputs, preconditions, and artifacts for any ceremony intent (C1–C6) or named process slot (planning, gate, refinement, …). Use this so agents, engineers, and product share one contract.
Pairs with: Spec-driven development overview · Ceremony foundation · Templates in SDD templates (Spec-driven development)
When to use which template
| You are specifying… | Template file |
|---|---|
| A foundation intent (C1–C6) or a calendar event mapped to intents | CEREMONY INTENT (template) |
| A process step or gate (sequential slice of work, often phased or release) | PROCESS SLOT (template) |
Document structure (required sections)
Every SDD ceremony/process spec SHOULD include these sections in order (copy from the template):
| Section | Meaning |
|---|---|
| SDD metadata | YAML frontmatter: sdd_id, kind, version, maps_to, status |
| Summary | One short paragraph: what this slot does in the delivery system |
| Boundaries | In scope / out of scope for this spec (prevents ceremony creep) |
| Preconditions | What must already be true or available before the slot starts |
| Inputs | Consumed during the slot (read, discussed, transformed)—each with type, owner, format, example |
| Outputs | Produced by the end of the slot—each with consumer, storage location, example |
| Postconditions | Observable done criteria (checkboxes) |
| Participants | RACI-style or lead + required participants |
| Artifact register | Fine-grained list: id, name, type, producer → consumer |
| Traceability | Work-unit IDs, doc paths, tracker links |
| Filled example | Concrete instance (same headings, fictional but realistic project) |
YAML frontmatter (normative keys)
---
sdd_id: SDD-C1-ALIGN # unique, stable string
kind: ceremony_intent # ceremony_intent | process_slot
version: "1.0"
status: draft # draft | active | deprecated
maps_to:
ceremony_intents: [C1] # C1..C6; empty [] for pure process slots
methodology_events: [] # optional: ["Sprint Planning — Part 1", …]
sdlc_phases: [A, B] # optional: A–F touch
title: "Align on intent — horizon H"
owner_archetype: "Demand & value" # from roles-archetypes if useful
---
Input / output row shape (tables)
Use one row per artifact (not one row per meeting). Minimum columns:
Preconditions
| ID | Artifact | Format | Owner | Ready when (criterion) |
|---|---|---|---|---|
Inputs
| ID | Name | Type | Source | Format | Example (snippet) |
|---|---|---|---|---|---|
Outputs
| ID | Name | Type | Primary consumer | Storage / system | Example (snippet) |
|---|---|---|---|---|---|
Artifact register (optional extra granularity)
| Art-ID | Name | Kind | Producer | Consumer | Versioning |
|---|---|---|---|---|---|
Quality rules
- Examples are mandatory — at least one filled example per spec; vague rows without examples are incomplete.
- IDs are stable —
sdd_idand rowIDcolumns do not change meaning mid-flight; use a new version or newsdd_idif semantics shift. - One consumer minimum — every output names who uses it next (person, role, or system).
- Chat is not storage — outputs must name repo path, tracker object, or tool; “verbal agreement” is not an output row unless followed by a written record in the named system.
- Maps to C1–C6 — ceremony specs should tag intent(s) so the foundation and methodology forks stay aligned.
Handbook subchapters (HTML)
Related templates (repo paths)
| Path | Use |
|---|---|
| CEREMONY INTENT (template) | Blank ceremony / intent SDD spec |
| PROCESS SLOT (template) | Blank process step / gate SDD spec |
Canonical source
Edit https://github.com/autowww/blueprints/blob/main/sdlc/methodologies/spec-driven/SDD-IO-SCHEMA.md first; regenerate with docs/build-handbook.py.