Enforcement Receipts Explained
An enforcement receipt proves that a governance decision was made and an action was executed. It documents the what, why, and when of enforcement.
What are the action semantics?
The enforcement action defines what the boundary did in response to evaluation. Each action has specific semantics:
CONTINUE
Operation allowed to proceed. No drift detected or drift within acceptable bounds.
- - Workload continues execution
- - Receipt documents the approval
- - Monitoring continues
BLOCK_EXECUTION
Operation prevented from starting. Used when drift detected before execution begins.
- - Workload never starts
- - Receipt documents the block
- - Caller receives rejection
TERMINATE
Running operation stopped immediately. Used when drift detected during execution.
- - Workload forcefully stopped
- - Receipt emitted before termination
- - Resources released
What reason codes exist?
Reason codes explain why the enforcement action was taken:
Code Meaning ───────────────────────────────────────────────────────── OK No issues detected HASH_MISMATCH_FILE File hash differs from baseline HASH_MISMATCH_CONFIG Configuration drift TTL_EXPIRED Policy validity window passed SIGNATURE_INVALID Subject or policy signature failed SUBJECT_MISSING Expected file/resource not found POLICY_MISMATCH Policy binding broken MEASUREMENT_TIMEOUT Could not complete measurement THRESHOLD_EXCEEDED Telemetry outside allowed range MISSING_DATA Required telemetry not received LATE_DATA Data arrived outside time window RESOURCE_EXHAUSTED System resource limits hit MANUAL_OVERRIDE Human-initiated enforcement
How does policy binding work?
Every enforcement receipt references the policy that governed the decision:
// Receipt policy reference
"policy": {
"policy_id": "sha256:a1b2c3..."
}
// This proves:
// 1. Which policy was active
// 2. Which enforcement_mapping was used
// 3. That the action matches policy rules
// Verifier checks:
// - policy_id in receipt matches bundle's policy artifact
// - action taken matches enforcement_mapping[reason_code]
// - If mismatch: ENFORCEMENT_POLICY_MISMATCH errorWhat is the decision block?
The decision block captures the full enforcement context:
"decision": {
// What was done
"action": "TERMINATE",
// Why
"reason_code": "HASH_MISMATCH_FILE",
// Human-readable context
"details": "config.json: expected abc123, got def456",
// For complex scenarios
"contributing_factors": [
{ "type": "FILE_DRIFT", "path": "config.json" },
{ "type": "TTL_WARNING", "remaining_ms": 30000 }
],
// Recovery guidance (optional)
"suggested_remediation": "Review config.json changes"
}How do receipts prove enforcement?
The receipt chain proves enforcement actually happened, not just that it was claimed:
- ■Signature: Only the boundary's key could sign; proves boundary made the decision
- ■Timestamp: When the decision occurred (TSA-attested for high assurance)
- ■Chain position: Where in the sequence; proves order of events
- ■Policy reference: Which rules governed; proves correct policy was used
- ■Action + reason: What was done and why; verifiable against policy mapping
What about enforcement failures?
If enforcement action itself fails (e.g., couldn't terminate process), the receipt documents this:
"decision": {
"action": "TERMINATE",
"action_status": "FAILED", // vs "EXECUTED"
"reason_code": "HASH_MISMATCH_FILE",
"details": "Termination failed: process not found",
"fallback_action": "ALERT",
"fallback_status": "EXECUTED"
}Frequently asked questions
Can enforcement receipts be faked?
Not without the boundary's signing key. A forged receipt would fail signature verification. The key should be protected; if compromised, key rotation and revocation are required.
What if TERMINATE fails repeatedly?
The policy should define escalation. Typically: retry → alert → manual intervention. Each attempt produces a receipt documenting the failure, creating an audit trail for incident response.
Do I need a receipt for every measurement?
MEASUREMENT_OK receipts can be batched or sampled for high-frequency measurements. DRIFT_DETECTED and ENFORCED receipts must always be individual and immediate. The policy defines which events require receipts.