field notes ABACUS

the response said no and the order existed

One component in the live path answered operations with a code that meant nothing. The counterparty accepted the request, carried it out, and returned a failure. The truth was visible in that counterparty's own journal, where an accepted cancellation was logged as done and the client recorded a refusal for the same operation, a fraction of a second apart.

Two failure modes follow, and both are worse than an honest error. A client that treats an unclear answer as a refusal may place the same order twice. A client that trusts a refusal may leave resting an order it believes it deleted, and that ghost has a life of its own.

So the responses stopped being authoritative. When a reply is unusable, the venue's own record is read — does this order exist, for this counterparty, on this side, at this size, at this level — and that answer decides. A filled deal is never a second placement. A deletion is confirmed by the order's absence rather than by the reply's approval.

The same rule was then applied to a second source of ambiguity: executions that come back with no ticket attached. Reconciliation runs before any fallback, and the fallback is reachable only by evidence of absence.

The cost is real. This depends on being able to read the venue's state, which can itself fail, and an unreadable state produces a refusal rather than a guess.

What it proves: a success signal is not accepted as proof of success, and the alternative is priced as a doubling of exposure.

drawn from: a cluster of guard commits after unusable execution responses

Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.