Interlock Operations Skill
This skill governs operational behavior for Interlock enforcement.
Core Rules
- Never Publish Enforcement Heuristics
Enforcement logic is internal. Never commit or document:
-
Threshold values for enforcement decisions
-
Specific trigger conditions
-
Bypass mechanisms or exceptions
-
Internal scoring algorithms
Reason: Publishing enforcement heuristics enables gaming.
- Every Enforcement Action Must Emit a Receipt
No silent enforcement. Every action must produce:
{ "action": "refusal|degradation|allowance", "timestamp": "2026-01-10T12:00:00Z", "reason": "quality_floor_breach", "incident_id": "int-123456", "confidence": 0.45, "threshold": 0.80 }
- Receipt Format Changes Require Validation
Before changing receipt schema:
-
Update the schema definition
-
Create positive test fixture
-
Create negative test fixture
-
Run ./scripts/claude/receipt_audit.sh
-
Verify both positive and negative tests pass
- Any Failure = Degrade/Refuse
Never allow silent passes:
Scenario Action
Validator unavailable REFUSE
Schema mismatch REFUSE
Confidence unknown REFUSE
Timeout DEGRADE
Partial data DEGRADE
Receipt Lifecycle
- EMIT → Receipt generated at decision point
- SIGN → Cryptographic signature applied
- STORE → Written to forensic log
- VERIFY → Schema validation on read
- AUDIT → Periodic integrity check
Validation Commands
Full receipt audit with negative tests
./scripts/claude/receipt_audit.sh
Public safety check (no secrets in receipts)
./scripts/claude/public_safety_check.sh
Schema Files
File Purpose
schemas/interlock_event.schema.json
Event schema definition
schemas/golden_fixture.jsonl
Known-good test fixtures
receipts/examples/operatorpack_example_pass.json
Valid receipt
receipts/examples/operatorpack_example_fail.json
Invalid receipt (for negative test)
Prohibited Actions
-
Publishing enforcement thresholds
-
Silent passes on validation failures
-
Modifying receipts after signing
-
Skipping negative tests
-
Committing real receipts to public repo