The artifact that turns "it must be fast and highly available" into something a test can fail. One row per attribute, and every row has a number, a place the number is measured, and a person who agreed to it.
The shape
| # | Attribute | Scenario | Target | Measured at | Owner | Verified by |
|---|---|---|---|---|---|---|
| N1 | Latency | Order submit, normal load | p99 < 400 ms | API gateway, excl. client | Order PO | k6 suite, every release |
| N2 | Latency | Order submit, peak (4× normal) | p99 < 900 ms | API gateway | Order PO | Peak test, quarterly |
| N3 | Availability | Order submit endpoint | 99.95% monthly | Synthetic probe, 3 regions | Order PO | SLO dashboard |
| N4 | Durability | Committed order | RPO 0 | DB failover test | Platform | DR test, half-yearly |
| N5 | Recovery | Full region loss | RTO 30 min | Time to first success | Platform | DR test, half-yearly |
| N6 | Throughput | Sustained submit rate | 1 200 req/s | Load balancer | Platform | Load test |
| N7 | Scalability | Scale-out to 3× | < 8 min, no error budget spend | Autoscaler | Platform | Peak test |
| N8 | Security | Card data at rest | Tokenised, no PAN stored | Data store scan | Security | Quarterly scan |
| N9 | Privacy | Erasure request | Completed < 30 days | Erasure job log | DPO | Monthly sample |
| N10 | Observability | Failed order | Traceable end to end < 5 min | Trace search | SRE | Game day |
| N11 | Cost | Unit economics | < ₹0.42 per order | Cost allocation tags | Finance | Monthly review |
| N12 | Compatibility | API breaking change | Zero without 90-day notice | Contract tests | API PO | CI gate |
When you produce it
During discovery, before any design work that would be invalidated by the answers. The distinction between 99.9% and 99.99% is roughly the difference between one region and three, and finding that out after the design is agreed is expensive.
Re-open it whenever a target is missed twice — either the design is wrong or the number was never real.
Who reads it
Architects, who design to it. Engineers, who build the tests that verify it. Product owners, who have to accept the cost of each number. Vendors, who should be given it verbatim during selection. Finance, for the cost rows.
What good looks like
- Every row has a number and a unit. No "high", "fast" or "robust".
- The measurement point is stated. p99 at the load balancer and p99 in the browser are different numbers and different arguments.
- Peak is a separate row from normal, with the peak multiplier defined.
- Somebody's name is on each row, and they know it.
- Verification is named — a test, a probe, a report — so it is not aspirational.
Common mistakes
- Adjectives. The default failure mode.
- Copying targets between projects. 99.99% inherited from a template costs real money nobody chose to spend.
- No peak definition. Then the load test is testing an average day.
- No owner. An unowned target is renegotiated silently at the first crunch.