Review recorded work against the plan.

See how recorded work compares with the design doc your team agreed on. Each result shows where it came from: a person, an agent or GitHub. The reviewer decides what to confirm and when to ship.

Start free Compare plans

Plans: Plan versus actual on every plan. Acceptance criteria on every plan, up to 10 per design doc on Free, in early access. GitHub evidence on Business and Enterprise.

Object: Dispatch Service
Planned: Yes
Recorded change: Yes
Result: Planned and recorded
Object: Carrier Gateway
Planned: Yes
Recorded change: No
Result: Planned; no recorded change
Object: Tracking Service
Planned: No
Recorded change: Yes
Result: Recorded outside the plan

Object	Planned	Recorded change	Result
Dispatch Service	Yes	Yes	Planned and recorded
Carrier Gateway	Yes	No	Planned; no recorded change
Tracking Service	No	Yes	Recorded outside the plan

This compares the plan with recorded activity. Missing records do not establish whether implementation occurred.

Dispatch Service: Per-channel tender window
Recorded by Priya Raman
Tracking Service: Shipper countdown uses the new window
Recorded by Priya Raman

Plan versus recorded, from the design docRecreated from Archdocs views with sample data.

Find gaps in the recorded work

Compare planned object changes with changes people and agents recorded.

Read the evidence behind a change

See linked pull requests and GitHub checks beside the plan.

Judge each acceptance criterion

Review its evidence with source labels on every plan, in early access.

Compare the plan with recorded changes

Use Record a change, or let an agent record one over MCP. Each change names who recorded it. A missing recorded change is a question to confirm, not proof the work wasn't done.

Object	Planned	Recorded change	Recorded by	Result
Dispatch Service	Yes	Yes	Priya RamanPerson-reported	Planned and recorded
Carrier Gateway	Yes	No	No record	Planned; no recorded change
Tracking Service	No	Yes	Priya RamanPerson-reported	Recorded outside the plan

Next for the reviewer: confirm the Carrier Gateway change with Claude Code's operator, Priya Raman; decide Q1 with Maya Chen; then Mark shipped, or Mark shipped with an exception note.

Sample data from DD-0021. Recorded means someone added a change to the record.

Dispatch Service: Per-channel tender window
Recorded by Priya Raman
Tracking Service: Shipper countdown uses the new window
Recorded by Priya Raman

Linked pull requests show state and checks from GitHub
A person ships with "Mark shipped" or "Mark shipped with exception"
An exception note explains what is still open

Plans: Plan versus actual on every plan. Linked pull requests and CI checks from GitHub on Business and Enterprise.

Recorded changes on a design doc, each naming the service, what changed and the person who recorded it. — Changes and who recorded them

Three pull requests linked to a design doc: two merged, one with CI passed, and one still open. — Linked pull requests with state and checks

See what supports each criterion

Early access

Agents propose criteria. A person authorizes them. A criterion can be satisfied by a person's or agent's attestation, or by GitHub checks: pull request merged, CI checks passed or commit included. Evidence accepted under your policy is not independently verified code correctness; read what each check actually checked.

Satisfied, Failed, Pending and Inconclusive
Waiting for authorization, Waiting for review and Needs recheck
A ship gate can allow, warn or block
Your policies decide whether criteria are required to ship and whether agent or human attestations count

Plans: Acceptance criteria on every plan, up to 10 per design doc on Free, in early access. GitHub evidence on Business and Enterprise.

DD-0021 · Shorter tender window for API carriers

Acceptance criteria

Authorized by a person

Tender expiry tests pass in CI
Satisfied
Checked via GitHub · #482
EDI tenders keep 15 minutes
Waiting for review
Agent-reported by Claude Code
Late acceptance re-offers the load
Pending
Waits on Q1

Ship gate: Warn

Review the agent report and resolve Q1 before marking this change shipped.

Acceptance criteria and the evidence behind themRecreated from Archdocs views with sample data.

Read the source of a result

A merged pull request, a passing check, a closed issue and a correct deployment are different facts.

Agent-reported: An agent submitted an account of what it did or checked.
Person-reported: A person submitted an account of what they did or checked.
Checked via GitHub: GitHub supplied the pull request, check or commit result shown.
Verified: The criterion has supporting evidence accepted under the configured policy; read that evidence and its scope.

Recorded evidence, an agent's report and a verified result are different things. A commit or a closed Linear issue alone does not prove the change is correct, merged or deployed.

Screenshots are from a sample workspace. Recreated views are labeled.

Start free Compare plans Explore Design Docs Read the docs