Keying the operation on an operator's mandate: lawful repeats pass, the check moves to the issuer
Mandate keying completed both lawful refunds in 20 of 20 pairs and stopped a duplicate authorized once (0 of 20), but let a duplicate authorized twice through in 18 of 20, as designed.
Prediction heldWhere does it stop?Re-checked
- Designed for
- Built to test whether keying the guard's operation identity on an operator-issued mandate, instead of the payment, lets lawful repeats through, still stops a duplicate, and where it stops working.
What was tested
Preregistered: before two claude-opus-5 agents started, the harness issued mandates through the gateway’s operator interface, each naming customer, payment, amount and a count of one. The refund tool required a mandate. Three guarded cells of 20 pairs on a simulator: one mandate named by both tickets of a duplicate, one mandate per ticket for one item, and two lawful refunds with their own mandates.
What we observed
With one mandate, 0 of 20 pairs refunded twice; 18 second refunds got a replay of the first result. With two lawful mandates, both refunds were made in 20 of 20, with no correctly mandated refund refused. With two mandates for one request, 18 of 20 refunded twice, as designed. Every cell matched its preregistered expectation.
What this means for Heimdall
The guard held each mandate: lawful repeats passed and a duplicate under one mandate stopped. One authorized twice passed, as designed: the guard enforces the issuer’s count, not its judgement, so the check moves to the issuer. This bears on grants and the fence key.
Limits
The harness, not a real operator, issued mandates. The comparison with payment keying crosses days. A mandate-derived provider key would by construction match; it was not tested. One model.
What remains open
Test that key as an arm.