Governance Chain

The governance chain connects edikt's two systems — architecture governance & compliance and Agentic SDLC governance — into a single traceable path from intent to implementation to verification.

Two systems working together:

Architecture governance & compliance — ADRs, invariants, and guidelines are your current engineering decisions. They compile into governance.md — directives Claude reads every session.

Agentic SDLC governance — PRD → Spec → Artifacts → Plan → Execute → Drift. Each step feeds the next. Each is constrained by compiled decisions and produces new ones.

They connect at three points:

• Governance constrains the spec — existing ADRs and invariants inform the technical design
• Compiled directives are active during plan and execution — Claude follows them automatically
• Drift verifies the implementation against governance — did we build what we decided?

The details of each mechanism have their own pages:

• Quality Gates — block on critical findings during plan and execution
• Compiled Directives — how ADRs become enforcement
• Drift Detection — the verification step
• Agents — specialist review at each phase
• Rule Packs — coding standards that fire automatically

The conversation that drives it

You don't type commands in sequence — you tell Claude what you need, and Claude runs the right step.

"Write a PRD for Stripe webhook delivery with retry logic and idempotency"

Claude generates structured requirements with acceptance criteria grounded in your project context. Review it, mark it accepted.

"Write a spec for PRD-005"

Claude checks that PRD-005 is accepted, then routes to architect, scans your codebase and ADRs, and generates a technical specification. The spec references the PRD and any relevant ADRs.

"Generate spec artifacts for SPEC-005"

Claude produces the implementable outputs: data model, API contracts, migrations, test strategy. Each artifact references the spec it came from.

"Create a plan for SPEC-005"

Claude breaks the spec into phases, routes each to specialist agents for pre-flight review, and returns findings before any code is written.

Then you execute. Claude builds with enforced standards, the active plan phase injected on every prompt.

"Does the implementation match the spec?"

Claude runs drift detection — comparing what got built against the PRD acceptance criteria, spec requirements, artifact contracts, and ADR compliance.

The full sequence:

PRD → spec → artifacts → plan → execute → drift detection

Command references: /edikt:prd, /edikt:spec, /edikt:spec-artifacts, /edikt:plan, /edikt:drift

State machine

Each step in the chain has a status. The chain enforces a strict progression: each artifact must be accepted before the next step can begin.

Step	Status values	Gate
PRD	draft → accepted	spec requires accepted PRD
Spec	draft → accepted	spec-artifacts requires accepted spec
Artifacts	draft → accepted (per artifact)	plan requires accepted artifacts
Plan	draft → in-progress → complete	Execution proceeds phase by phase
Drift report	generated on demand	Closes the loop — accepted vs. built

Attempting to write a spec on a draft PRD produces a hard block:

BLOCKED  PRD-005 status is "draft".
         PRDs must be accepted before generating a spec.
         Review the PRD and change status to "accepted" first.

This isn't a suggestion. The gate exists because a draft PRD represents unresolved requirements — building a technical specification on top of unresolved requirements produces wasted work.

What gets captured at each step

PRD — functional requirements, non-functional requirements, acceptance criteria, open questions. The product intent, in structured form.

Spec — architecture approach, components, trade-offs, alternatives considered, references to ADRs and invariants. The engineering response to the PRD.

Artifacts — the implementable outputs of the spec:

• data-model.md — entities, relationships, indexes
• contracts/api.md — endpoint definitions, request/response shapes, error codes
• migrations.md — schema changes with up and down migrations
• test-strategy.md — unit, integration, and edge case coverage
• contracts/events.md — event schemas, producers, consumers
• config-spec.md — environment variables, feature flags

Plan — phased execution with pre-flight specialist review. Each phase is reviewed by the domain agents before any code is written.

Drift report — comparison of implementation against spec, PRD acceptance criteria, artifact contracts, ADR decisions, and invariants. Saved to the spec folder.

Traceability

Every artifact in the chain carries references to what it came from:

# spec frontmatter
type: spec
id: SPEC-005
source_prd: PRD-005
references:
  adrs: [ADR-001, ADR-003]
  invariants: [INV-001]
status: accepted

# artifact frontmatter
type: artifact
artifact_type: data-model
spec: SPEC-005
status: draft
reviewed_by: dba

When drift detection runs, it follows these references backward through the chain — checking implementation against artifacts, artifacts against spec, spec against PRD acceptance criteria.

Why this matters

Without the chain, the engineering cycle is scattered: requirements in Notion, decisions in Slack, specs in someone's head, verification by hope. The chain creates a single, version-controlled, machine-readable path from "what we decided to build" to "what we actually built."

The drift check closes the loop. It's not optional ceremony — it's the mechanism that makes the governance chain a governance chain rather than a documentation exercise.

When to use it

You don't have to use the full chain for every piece of work. For ad hoc tasks, edikt's rules and hooks govern the session without PRD or spec. The chain is for features where traceability matters — where you need to verify that implementation matches intent.

For new features, the chain is the right default. Tell Claude what you want to build, let it generate acceptance criteria, review and accept it, then proceed.

See /edikt:prd, /edikt:spec, /edikt:spec-artifacts, /edikt:plan, /edikt:drift.