Artifact Chains End-to-End

Introduction

Module 01 named the six transformations; Module 03 taught you to register artifacts cleanly. This module connects them: how one Journey actually flows from a feature_request to implementation-ready plans, what each transformation produces, and what "good" looks like at each fidelity level.

The goal for this module is the intake-to-plan-ready span — Clarify through Arrange. That's where most of the leverage (and most of the failure) lives, because it's where a vague idea becomes something an agent can execute without guessing.

What you'll be able to do by the end

• Trace a Journey through enrich → evolve → decompose → plan
• Use Decision Gates and their criteria to control phase transitions
• Recognise what good output looks like at Discovery, Definition, and Execution fidelity
• Read the traceability graph to find what a change affects

---

1. The Journey as a lineage

A Journey is an artifact lineage with a root artifact (a feature_request) and a current phase. It isn't one document that mutates — it's a chain of linked artifacts, each produced from the last:

Transformation	Phase shift	Input → Output	Link
enrich	within Observe	feature_request → feature_request (v+1)	—
evolve	Observe → Model	feature_request → feature_specification	derives_from
decompose	Model → Partition	feature_specification → user_story ×N	derives_from
plan	Partition → Arrange	user_story → implementation_plan	implements
execute	Arrange → Synthesise	implementation_plan → code_and_tests	implements
converge	Synthesise → Ship	code_and_tests → release_artifacts	implements

Because every step links to its parent, you can trace any line of code back to the user story, the spec, and the sentence in the original request that justified it. That traceability is the point — it's what lets a reviewer trust AI-generated work without re-deriving it.

---

2. Intake to plan-ready, step by step

Clarify → a sharp request. A Journey starts in clarify with a root feature_request. The job here is a request that states the problem, who has it, and what success looks like — not a solution. Vague intake poisons everything downstream.

Observe → enrich. As research lands, enrich appends a new version to the same request — deepening it in place rather than forking. The request grows a risk-and-assumption register and feasibility notes. (This is the one transformation that doesn't change artifact kind.)

Model → evolve. evolve turns the enriched request into a feature_specification that derives_from it: architecture-aware, with acceptance criteria, non-functionals, and explicit open questions.

Partition → decompose. decompose splits the accepted spec into N user_story artifacts, each derives_from the spec, each independently buildable and verifiable with its own acceptance criteria.

Arrange → plan. plan turns one story into an implementation_plan that implements it — step-by-step tasks with file-level changes and verification checkpoints. The bar: an agent could pick up any task and execute it without asking a clarifying question. When that's true, you're plan-ready.

Plan-ready, defined Every story has an implementation plan whose tasks are unambiguous and verifiable. If a task needs a clarifying question to start, it isn't done — it's an Arrange retreat to Partition waiting to happen.

---

3. Decision Gates control the transitions

Producing an artifact does not advance the Journey. The transformations shape the lineage; a Decision Gate flips the phase. A gate is a multi-reviewer checkpoint with two things to satisfy:

• Required reviewers — the people configured to approve this phase.
• Typed criteria — a checklist that's evaluated, not just vibed. Criteria come in three kinds:
  • manual — a human checks a box ("acceptance criteria are testable").
  • artifact_exists — automatically satisfied when an artifact of a given kind exists in the lineage.
  • artifact_accepted — satisfied when that artifact has reached ACCEPTED status.

When the last required reviewer approves and all required criteria are satisfied, the gate completes and the Journey advances atomically — one transition, fully recorded. Criteria are configurable per project (phase profiles + fidelity presets) and can be extended per Journey.

If review surfaces gaps, you retreat (with a reason) to an earlier phase rather than forcing forward. Retreat preserves history; it's the methodology working, not a black mark.

---

4. What "good" looks like at each fidelity

The same chain runs at different depths. The artifact kinds are the same; the expected thoroughness differs.

Artifact	Discovery	Definition	Execution
feature_request	Enough to judge feasibility and commit	Sharp problem + constraints	Finalised, validated
feature_specification	High-level approach, defensible	Build-ready: criteria, non-functionals	Complete, all open questions closed
user_story	Phase/milestone-level chunks	INVEST stories with acceptance criteria	Task-level, fully sized
implementation_plan	Rough effort estimate	Detailed tasks	Exhaustive, agent-ready

A common mistake is reviewing a Discovery-fidelity spec as if it were Execution-fidelity and rejecting it for "missing detail" — or worse, accepting an Execution-fidelity plan that's actually only Discovery-deep. Match the bar to the pass.

---

5. Read the graph before you change anything

The links (derives_from, implements, supersedes, references) form a traceability graph, and it answers real questions:

• Upstream ("what does this depend on?") — is everything this plan is built on actually ACCEPTED?
• Downstream ("what does this affect?") — if I change this spec, how many stories, plans, and code artifacts are in the blast radius?

Before you edit an accepted spec, trace downstream. A one-line change to a spec that already has ten stories and five plans hanging off it isn't a one-line change — and the graph is what tells you so before you find out the hard way.

---

Exercise — one-line request to plan-ready

On a sandbox Journey, take a single one-sentence feature request all the way to plan-ready:

1. Register the feature_request; enrich it once with a risk or assumption.
2. Evolve it into a feature_specification (Definition fidelity) with at least three acceptance criteria and one open question.
3. Decompose it into two or three user_story artifacts.
4. Plan one story into an implementation_plan whose tasks are all verifiable.
5. Open the gate for one transition and walk its criteria — note which are manual vs artifact_*.

Then trace the line from your plan back up to the original sentence. If the chain holds — every artifact linked, every step justified by the one above — you've driven a real artifact chain. Module 05 is how you review work like this rigorously enough to trust it.