# Verification and Handoff

## Match evidence to the claim

| Risk or claim | Useful evidence |
| --- | --- |
| business branches and error mapping | unit tests |
| dynamic input, numeric, serialization | type checks, boundary and historical-sample tests |
| database, cache, message, external protocol | integration or contract tests |
| idempotency, races, multi-instance behavior | concurrency, repetition, and recovery tests |
| hot-path cost | benchmark or profiler |
| throughput, latency, backlog, saturation | controlled load or capacity test |
| timeout, degraded dependency, blocked logs, recovery | fault injection or controlled simulation |
| compatibility and migration | old/new samples, mixed versions, rollback or forward-fix test |

Test observable behavior and invariants, not wording, headings, or implementation constants.

Choose relevant steady, peak, burst, degraded, saturated, restart, duplicate, out-of-order, partial-success, skewed-tenant, maximum-payload, mixed-version, and rollback scenarios. Without an exact capacity target, validate limit behavior and protection mechanisms; do not invent a production QPS claim.

Distinguish model reasoning, local functional tests, benchmark, controlled load test, and production observation. Report environment, parameters, duration, data size, and limitations. A short single-machine run does not prove sustained production capacity.

In the handoff, include only task-relevant assumptions, limits and overload behavior, timeout and retry policy, recovery, diagnostics, compatibility, evidence, and unverified boundaries. Avoid unsupported labels such as "production-ready."