# Risk register: testing quality program

| ID | Risk | Likelihood | Impact | Mitigation |
|---|---|---:|---:|---|
| TQ-R1 | Coverage gaming without behavioral assertions | medium | high | require boundary/negative/property scenarios and review mutation signal |
| TQ-R2 | Default CI downloads models or accesses services | medium | high | strict markers, empty caches, offline environment, network tests excluded |
| TQ-R3 | Hardware tests make PR CI flaky or unavailable | high | medium | conditional scheduled/manual workflows and documented prerequisites |
| TQ-R4 | Tooling additions create supply-chain exposure | medium | high | pinned sources, explicit update policy, audit/SBOM evidence |
| TQ-R5 | Warning enforcement breaks on third-party noise | medium | medium | classify warnings, use narrow documented filters, ratchet budget |
| TQ-R6 | Mutation/property jobs exceed useful feedback time | medium | medium | target small pure modules and run depth gates separately |
| TQ-R7 | Installed package behavior differs from checkout | medium | high | clean wheel and sdist installation smoke tests |
| TQ-R8 | Numerical tests are device/dtype brittle | medium | high | invariant/tolerance contracts and separate backend-specific evidence |
| TQ-R9 | Conditional evidence is reused for a different commit | medium | high | candidate-SHA validation; exceptions require a reason, canonical issue, and expiry within 30 days |
| TQ-R10 | Test growth silently erodes contributor feedback time | medium | medium | retained per-test/marker timing, policy-owned suite and repeat budgets, expiring slow-test ownership, ten-minute job cap |
