DEV Community

Trent Wade
Trent Wade

Posted on

The override protocol: how Keel lets the operator overrule a refusal — honestly

Keel's refusals are hard gates: when a question can't be answered honestly, the run stops and the lead parks with its reason named. But a machine you can't overrule isn't a tool — it's a boss. So the override exists. What matters is how it's recorded.

An override is a first-class record, not an edit. The original refusal stays in the ledger — parked, named, timestamped. The override lands on top of it, carrying the operator's word with provenance: who said it, when, and exactly which refusal it unlocks. History is never rewritten. A later reader sees the refusal AND the override, in order, each stamped.

The rules around the override are as strict as the refusal it answers. It applies to exactly the refusal it names — never a class, never a blanket permission. Silence is never an override; the machine waits, and waiting means no. And the override answers only to the operator's own word: his sentence, his signature, his attestation — the things only he can supply.

This is why the fail-closed discipline survives human authority instead of dissolving into it. The operator is the only authority the machine recognizes, and the machine recognizes his authority by recording it — every override visible, every one attributable, none of them silent.

Build the pressure valve into the contract, and the contract holds even when you open the valve.

Repo link to include at the end: https://github.com/KeelDev-tech/keel (Apache-2.0).

Top comments (0)