SDD Evidence Log Template

Use the evidence log when review approval is not enough. It records how each acceptance criterion was proven, where the proof lives, and what signal should stop a rollout.

evidence.md

# Evidence Log

Spec:
Release:
Owner:
Date:

## Acceptance Evidence
| Criterion | Evidence | Link | Result |
| --- | --- | --- | --- |
| AC-1 | Test | | Pass/Fail |
| AC-2 | Screenshot | | Pass/Fail |

## Operational Evidence
- Log query:
- Metric:
- Alert:
- Stop signal:

## Manual Checks
- [ ] ...

## Known Gaps
- Gap:
- Risk:
- Owner:
- Follow-up date:

When to use this template

The release touches money, data integrity, permissions, or customer-visible state.
A reviewer needs to verify proof instead of trusting a summary.
A team wants stable release notes and rollback context.
AI-generated code must provide concrete evidence before merge.

What a filled version looks like

The template becomes useful after it carries a real decision, owner, and evidence. This is the level of specificity to aim for.

| Criterion | Evidence | Link | Result |
| --- | --- | --- | --- |
| AC-2 duplicate replay | Integration test | refund_timeout_replay | Pass |
| AC-3 support block | Screenshot | support-refund-pending.png | Pass |

Stop signal: duplicate_refund_attempts > 0.5% for 15 minutes.

Review before implementation

Each acceptance criterion has a proof type and result.
Operational signals are concrete queries, dashboards, metrics, or alerts.
Known gaps are owned and dated.
Rollback or stop signal is visible to release reviewers.

Weak vs strong wording

Weak

Tests pass and QA checked it.

Strong

AC-2 is covered by refund_timeout_replay, AC-3 is verified by a support UI screenshot, and rollout stops if duplicate_refund_attempts exceeds 0.5% for 15 minutes.

FAQ

Is an evidence log required for every change?

No. Use it when correctness needs proof: high-risk releases, API changes, migrations, payment flows, permissions, or AI-generated diffs.

What counts as evidence?

A test, fixture, screenshot, log query, metric, dashboard, alert, manual check, or release gate that proves a specific criterion.

How does this help SEO and content quality?

For the site reader, it shows a real operational artifact, not abstract advice. For teams, it turns review into a reproducible practice.

Related resources

Editorial note

This template is written for spec-driven development workflows. The example is illustrative and should be adapted to your domain.

Author: Daniel Marsh
Editorial policy: How we review and update content

Tip: keep it under /docs/specs/ or /.specs/, then update it in the same pull request as implementation changes. Last updated: May 11, 2026.