The pipeline.
Artifacts are the named work products that flow through Cadence. Like signals, they get called out explicitly, for the same reason. If the org doesn’t name an artifact, it can’t inspect it, validate it, or improve how it flows.
The pipeline is a loop, not a straight line. Increments generate signals, signals turn into briefs, briefs break down into specs, specs spawn plans, plans become implementations, and implementations get released as increments that generate the next signals.
01
Backlog
The prioritized list at every level of the org.
02
Product Brief
User-focused: why, how it's measured, what it changes.
03
Specification
AC, DoD, validation plan. Lives in code.
04
Plan
Technical implementation markdown. Ephemeral by design.
05
Implementation
Working code, validated by fast feedback.
06
Instrumented Increment
Released, observable, generating new signals.
The Signals chapter covers the data flowing in. Read it first if you haven’t. This chapter picks up where the signal becomes a brief, and follows the artifact all the way back to becoming a signal again.
Artifact Nº 01
Backlog
Backlog is the most generic artifact in the pipeline: a prioritized list of things to do. Every level of the org has one. The discipline is ownership.
One owner, delegable downward
A backlog is owned by exactly one person. That person can delegate ownership of subsections to smaller groups, such as area POs, value-stream POs, and eventually pod-level POs, but at every level there’s still exactly one accountable owner. The pod backlog has one owner. So does the area backlog. The org backlog is owned by the Chief PO.
Why so strict? Because backlog is where prioritization actually lives. Prioritization fragments the moment two people both think they’re responsible. Single ownership is what keeps a backlog from becoming a wishlist.
What’s in a backlog
The granularity changes by level. The org backlog mostly holds briefs and epics; the area backlog holds specs; the pod backlog holds spec-level items the pod has committed to or is about to. Ranking is always concrete, so what comes next is unambiguous.
Artifact Nº 02
Product Briefs
Briefs are where signals turn into work. The output of Signal Inspection is a brief. Work doesn’t start without one.
What a brief covers
A brief is user-focused, not a comprehensive specification. It can roll up to a larger epic or initiative or stand alone; that matters less than people think. What matters is that the brief covers three things plainly:
- Why it’s important. What signal triggered this. What changes for the user, the customer, or the business if we ship it. Why this brief, why now.
- How it will be measured. The numbers, signals, or evidence that will tell us this brief delivered what it said it would.
- What it’s going to change. The user-visible delta and the system behavior that will be different. The outcome, not the implementation.
The brief becomes a validation plan
The brief’s “how it will be measured” section is the high-level validation plan that every artifact downstream has to align to.
Specs validate against it. Plans validate against it. Implementation feedback measures against it. The brief sets the bar for what “done” looks like, and everything that follows answers to that bar.
Artifact Nº 03
Specifications
Briefs break down into specs. A spec is where you finally get clear acceptance criteria and a definition of done, but the frame stays user value, not implementation. The spec still describes the user’s experience, just in enough detail to commit to.
What a spec contains
- Acceptance criteria and definition of done. Concrete and testable. The pod can pull this and know what “committed” means.
- A detailed validation plan. Specifically how this spec will be validated as complete — and the validation plan must align with the brief’s high-level validation plan. If they don’t connect, the spec is wrong.
- Whatever else clarifies user value. UI mockups where interaction matters, API contracts where integration matters, data shapes where correctness depends on them. Include what reduces ambiguity and nothing that doesn’t.
Specs live in the code
Specs are not stored in a separate documentation system that drifts away from reality. They live in the codebase, version controlled with the work they describe. They build up over time as a record of what the pod committed to and shipped.
At the end of implementation, specs get curated and indexed, and the index gets saved into the pod’s context library (covered in the Pods chapter). That’s how a pod accumulates institutional memory: every shipped spec becomes retrieval material for the next one.
Artifact Nº 04
Plans
A plan is the technical implementation of how a spec gets done. Where the brief and spec described what and why, the plan describes how. AI agents do most of the drafting; humans direct, validate, and decide.
How a plan gets created
Before writing the plan, agents research everything that informs the implementation: the team’s own context library, dependent teams’ public libraries, established patterns and practices, related shipped work, the spec’s validation plan. The output is a technical implementation markdown file, a working document rather than a polished spec.
The plan lives in the code alongside the work, but it isn’t meant to persist. At release, it gets curated: the knowledge worth keeping is extracted and added to the team’s context library, and the rest is allowed to disappear.
Plans must have a validation plan
Every plan includes its own validation plan: the strategy for how the implementation produced from it will be verified. This is more granular than the spec’s validation plan. It covers how unit tests, integration tests, manual checks, and AI-evaluation steps will combine to confirm the plan’s implementation actually delivers what the spec asked for.
The plan itself gets validated
Plan validation is independent of plan creation, and it happens after the plan is generated.
A separate validation step checks the plan against the org’s standards: architecture patterns, security requirements, the team’s established practices, dependencies. The agent that drafts the plan doesn’t also approve it. This separation prevents AI plans from confidently violating the very standards they should be following.
Artifact Nº 05
Implementation
Implementation is the working code. Plans flow into it immediately. There is no backlog of validated plans waiting in a queue; as soon as a plan is validated, the pod begins implementing.
Who does the work
The default mode is an engineer working alongside their AI agents. The engineer directs and decides; the agents draft and refactor. Together they turn the plan into code.
A second mode is worth using where it fits: a team of agents picks up a plan, implements against it, and requests feedback once they have something working. The human enters when the implementation is ready for review, not at every keystroke. Use it for work where a structured plan plus reliable evaluation are enough.
The point is fast feedback
The reason plan flows immediately into implementation is that you don’t learn whether a plan was right by polishing it. You learn by implementing it and getting real signal back fast. Feedback comes from multiple sources, and a healthy pod uses all of them:
- Comprehensive automated tests. The first signal the implementation gives back, and non-negotiable. Everything else assumes they pass.
- Human testers. Other engineers, QA partners, the PO. Catching what tests don’t.
- Real end users. The fastest way to learn whether the brief’s “why it’s important” was right.
- Independent AI agents. Reviewer agents that look at working product and check against criteria the implementing agents couldn’t see themselves doing wrong.
Feedback updates the plan, the cycle repeats
When feedback comes in, the plan gets updated and reimplemented. Keep it quick; this isn’t a ceremony. A human engineer guides the iteration, but an AI agent can draft the updated plan and the next implementation attempt.
The principle
We don’t care about the plan at the end of the day.
The plan is a tool for getting to a working implementation efficiently. What matters is the implementation, and whether it does what the spec said it should do — measured against the brief’s validation plan.
Artifact Nº 06
Instrumented Product Increment
As implementation work passes validation, it gets rolled into a release: an instrumented product increment. This is the artifact customers actually experience.
Why “instrumented” is in the name
Releases without comprehensive instrumentation are dead ends for the pipeline. They ship value, but the org gets no signal back about whether the value actually landed.
Every increment ships with the observability AI agents need to extract signals from how it performs in production: usage patterns, error rates, latency, business metrics, user feedback channels, cost-to-serve impact. This instrumentation isn’t private engineering telemetry. It’s the input the next round of curation depends on.
Closing the loop
Increment generates signals. Signals turn into briefs. The pipeline doesn’t end. It loops.
That’s why the chapter calls it a pipeline and not a sequence. Without the instrumentation step, the loop breaks. With it, every release becomes the input to the next round of inspection — agents read the signals, curate them, and shape the next briefs that drive the next specs that drive the next plans.
The validation cascade.
One thread runs through every artifact in the pipeline: each one declares how it will be validated, and each downstream artifact’s validation plan must align with the upstream’s.
- 01Brief how the work will be measured at the user-value level.
- 02Spec how the work will be validated as complete — must align with the brief.
- 03Plan how the implementation will be verified — must align with the spec.
- 04Implementation produces feedback that measures against all of the above.
- 05Increment instruments the running system so signals can be measured against the brief's bar.
The cascade is what makes the pipeline auditable. When someone asks “did this work actually deliver what we said it would?”, the answer traces from increment-level metrics back through plan validation, spec validation, and the brief’s original measurement criteria. That traceability is also what lets agents help curate without losing the thread of intent, because every artifact knows which upstream artifact it answers to.
When the cascade breaks (a spec whose validation plan doesn’t connect to the brief, a plan that validates against standards but not the spec, an increment with no instrumentation aimed at the brief’s metrics) the pipeline stops being a pipeline and becomes a pile of loosely related work. The cascade is what holds it together.