Outcome checks: deploy is not done
A simple Check schedule (+24h, +7d, +14d) so approved work stays tied to measurable follow-through.
If you do not run outcome checks, you do not really know whether the handoff worked.
You only know that the team shipped something.
The schedule that works
deploy + 24h -> breakage check deploy + 7d -> behavior check deploy + 14d -> metric check
That is enough for most operator workflows.
What to check
+24h
- errors
- support spikes
- performance regressions
- obvious funnel breaks
+7d
- did people use the new path?
- did the expected behavior move?
+14d
- did the target metric move?
- did any counter-metric get worse?
Outcome Check template
CHANGE: PRIMARY METRIC: TARGET: COUNTER METRICS: SEGMENTS: CHECKS:
- +24h:
- +7d:
- +14d: OWNER: ROLLBACK THRESHOLD:
Where ContractSpec fits
ContractSpec keeps the Check attached to the same reviewed trail as the brief, Change Card, Impact Report, and approved handoff.
Related articles
Impact Report template: breaks vs must-change vs risky
A practical Impact Report template to make blast radius explicit before approved work leaves review.
Change Card template: the smallest spec engineers trust
PRDs are too big. Tickets are too small. Use a Change Card to define the reviewed handoff engineers can trust.
Evidence-backed briefs: stop shipping claims without citations
A brief you can defend: claim -> evidence -> pattern -> scoped change -> measurable acceptance criteria.