Every Fusion run leaves behind a manifest: a small, structured record of what was attempted, what was checked, and what was decided. You do not need to read all of it. Four fields carry most of the signal.
Here is an illustrative sketch of the shape (field names simplified for reading):
run:
task: "harden webhook retry logic"
execution_tier: customer_ci
decision: verified
gate:
status: passed
pinned_to: "commit 4f2a9c1"
criteria:
- id: DoG-1
weight: hard
verdict: satisfied # unanimous
- id: DoG-2
weight: hard
verdict: satisfied # carried 2-1, dissent attached
- id: DoG-3
weight: soft
verdict: not_satisfied
The ninety-second read
1. The decision. Verified means the gate ran and every hard criterion passed; accepted means this was planning-grade work with no execution gate to run. One word, but it sets your expectations for everything below it.
2. The gate pin. The gate result is hashed and pinned to the exact commit it graded. If the branch moved after grading, the pin will not match, and the manifest is telling you the evidence belongs to an older version of the code. Check the pin before you trust anything else.
3. Hard criteria with drama. Scan the hard criteria for anything carried on a split vote. A unanimous satisfied is boring in the best way. A 2–1 satisfied comes with a dissent, and the dissent is where your review time earns its keep.
4. The soft misses. Soft criteria that failed did not block the run, but they are a to-do list somebody wrote for you for free.
Why the manifest is structured at all
Because "the AI said it looks good" is not an audit trail. A structured manifest can be diffed, queried, archived, and re-checked long after everyone has forgotten the run. The prose summary is for the standup; the manifest is for the incident review six months later.