"A click that fires and hopes is a wish. An operation is a record you can still question after everything goes wrong."
A button click is not an operation
The naive model of changing a machine is a button: click restart, it runs, you hope. But what happens if the browser closes mid-restart? If the network drops? If you handed the job to a teammate and went to lunch? With a button, the answer is the same every time: you don't know. A button records nothing. It's a wish with a loading spinner.
An operation is a durable record with a state machine
The fix is to make every mutation — whether Dad clicks it, Pippa assists, or a delegate runs it — a durable operation: a persisted record that walks a known path. draft → planned → awaiting_approval → running → verifying → succeeded | failed | needs_attention | cancelled. At any instant you can ask which state it's in, and the answer is real, because it was written down before it was shown.
What the record carries
An operation isn't just a status; it holds everything you'd need to understand or resume it: a stable id and kind, the human intent, who requested it and who's executing it, the capabilities it needs, the source host, a frozen target snapshot, its risk class and approval rule, preconditions and preflight evidence, ordered steps, per-target state and events, verification checks, and a recovery story. That's a lot — and it's exactly what a button throws on the floor.
needs_attention is a real destination
Notice that one terminal state is neither success nor failure — it's needs_attention. Some operations end genuinely ambiguous: half-applied, or blocked on a capability the executor turned out not to have. Calling that a clean success or a clean failure is a lie; giving it its own honest state is what lets a human step in with the whole record in front of them.