testing · system signals
System signals — health of the technical chain
- SLOs — latency, error rate, availability. Defined in the ADRs, measured in production.
- Pipeline pass rate — how often does the pipeline pass on first push? A declining rate signals code quality or test fragility.
- Deploy frequency — how often does the team deploy? Daily is a faster feedback loop than weekly.
Platform signals — health of the development chain
- Lead time — time from story pulled to production. Measures the total flow, not any single step.
- Change failure rate — percentage of deploys that cause an incident or rollback. Measures chain quality as a whole.
- Time to restore — time from incident to resolution. Measures operational readiness.
System and platform signals are what the tech lead watches continuously. They are not the prediction — they are the health of the machinery that delivers the prediction. A team with a 30% change failure rate will never reliably check a prediction, because the system is too unstable to know whether a metric moved because of the feature or because of a deployment failure.
SLIs and SLOs — the observable definition of working
A Service Level Indicator (SLI) is a measurement. A Service Level Objective (SLO) is the target. Together they define what "working" means in observable terms. SLOs are defined in the ADRs — they are architectural promises, confirmed in staging before every release.
- SLI: percentage of grade submissions that complete in under 2 seconds
- SLO: 99% complete in under 2 seconds, measured over a rolling 7-day window
The SLO is the technical promise. The Prediction is the human promise. Both must be measurable before the release gate, and both will be checked against reality in Volume V.
Resolution gate — Testing to Review
Enough to know the chain holds.
Every scenario has a named test. Every Epic boundary has a contract test. Visual baselines exist. QA has verified before merge. Analytics events trace to the prediction. SLO baselines are measured.