DEIMOS AI LLC · PUBLIC RECORD DEIMOS (JPL 402) RA 08ʰ56ᵐ38ˢ DEC +18°40′03″ Δ 1.537 AU AS OF 18 OCT 18:00 UTC REV 2026.10.18
Field Note 01 · 2026-10-18 Flight Rule FR-4: Bend, don't break Instrument Ratchet (ONCE)

Field Note 01 · Deimos AI LLC · 2026-10-18

At most once: why we refuse the stronger word.

An agent is about to charge a card. It sends the request. The connection drops. Did the charge go through? The agent doesn't know, and neither does anything else in its stack. So it does what software has always done: it tries again.

That retry is where the money goes. A supervisor re-runs the task. Two workers pick up the same job. A process wakes from a crash with no memory of what it did a minute ago. Each of them is behaving correctly, and together they charge the card three times.

The tempting answer is a product that promises exactly once. We don't make that promise, and we don't let our own copy make it either.

Why not exactly once

An effect that leaves your system, a charge, a deploy, an email, happens somewhere you don't control. Between “I asked the vendor to do it” and “I learned that it was done” there is always a gap, and a crash can land in that gap. When it does, nobody on your side can know whether the effect happened. Any system that claims to guarantee exactly once across that gap is either quietly guessing or quietly retrying.

What can be guaranteed is narrower and more useful: the same action is started at most once. Every later attempt, whether it is a retry, a restart or a racing worker, gets the recorded answer instead of a second try.

What we say when we don't know

The hard case is the crash inside the gap. Here Ratchet does something most systems avoid: it says so. The effect is marked indeterminate, a known unknown, and your policy for that kind of effect decides what happens next: block it, check with the vendor, or allow a retry you chose on purpose. Never a silent retry.

That is Flight Rule FR-4 in practice. Bend, don't break: when we don't know, we say so, and unknown never quietly becomes yes.

Why the smaller promise wins

A promise you can keep is worth more than one you can't. “At most once, and an honest unknown” is something an engineer can build on, an auditor can check, and a finance team can reconcile against the vendor's own records. “Exactly once” is something you find out was false on the day it matters.

So the stronger word stays out of our product, our docs and this site. If you see it anywhere near Ratchet, tell us and we'll log the correction in the Record.