Evidence and Proof · Lesson 03 of 04
Negative controls
Runtime negative controls challenge a proof obligation; refusal canaries separately verify agent admission remains closed.
Learning objectives
- Explain why negative controls are essential for agent safety
- Write a negative control for a protected path
- Interpret a refusal receipt correctly
Prerequisites
A negative control asks whether a proof obligation fails in the expected way when a required effect is intentionally missing. It is different from an agent refusal canary, which checks that an execution boundary refuses a declared task or workflow.
Bind the control to the same obligation
A validated runtime negative control must reconcile its control identity, dependency, proof obligation, expected failure mode, and failure attestation digest. Shape-only values such as same_obligation: true are not enough without canonical linkage.
ota proof runtime --workflow app --negative-control postgres-unavailable --jsonState the uncovered paths
A control proves the declared challenge path and obligation. It does not prove every equivalent command, script, migration, or external-system effect is blocked. Effect-level assurance requires a shared enforcement chokepoint rather than more prompt phrases.
Canonical terminology
Evidence boundary for this lesson
Establishes
- The worked examples establish the lesson's canonical Ota distinctions for its stated scope.
Does not establish
- Reading the lesson does not validate a repository, execute its tasks, or establish organizational acceptance.
Knowledge check
How is a runtime negative control different from a refusal canary?
A negative control challenges a proof obligation by withholding an expected effect. A refusal canary verifies that agent admission rejects a declared task or workflow.