Callback¶
Core Idea¶
A callback is a named action handed off in advance, to be invoked later by someone other than the registrant, when a specified condition arises. The registrant relinquishes control over when and by whom the action fires and proceeds immediately with other work; the holder, with better visibility of the trigger, invokes it on the registrant's behalf.
How would you explain it like I'm…
Ring When It's Time
Imagine you give your friend a note that says 'when the ice cream truck comes, ring my doorbell.' You don't have to stand at the window waiting — you go play, and your friend rings the bell at the right moment for you. You picked the action ahead of time, but your friend decides exactly when to do it. That's a callback: leaving an instruction with someone else so they can do it later, when the right thing happens.
Do-It-Later Instruction
A callback is an action you hand off ahead of time, so someone else can run it later when a certain thing happens. Instead of waiting around for the event yourself, you register your instruction with whoever can see the event, then go do other things. When the condition you named finally happens, that other party runs your action for you — maybe much later, and in a situation you couldn't fully predict. It flips the normal order: instead of 'I'll do this now,' it becomes 'if and when this happens, run this on my behalf.' The catch is that since someone else fires it at a moment you didn't choose, you have to think ahead about what your action should expect when it runs.
Deferred Conditional Action
A callback is a named action handed off in advance, to be invoked later by someone other than the registrant, when a specified condition arises. The registrant gives up control over when and by whom the action runs; the invoker gets the action without needing to know the registrant's downstream reasoning. It inverts ordinary control flow — 'I run this now' — into a deferred, conditional invocation — 'if and when this condition holds, run this on my behalf.' Three commitments are essential: registration (a handler is given to a holder along with a binding condition), suspension (the registrant doesn't block waiting — control returns immediately and it proceeds with other work), and deferred invocation (when the condition is met, the holder invokes the handler, possibly in a different thread of control and long after registration). This carries a consequential asymmetry: because a foreign party fires the handler at a moment the registrant didn't choose, the registrant must reason in advance about what the handler may assume when it fires, how long the registration stays valid, and what happens if the condition recurs or another handler is still running.
A callback is a named action handed off in advance, to be invoked later by someone other than the registrant, when a specified condition arises. The registrant relinquishes control over when and by whom the action is invoked; the invoker is given the action without needing to know the registrant's downstream reasoning. The pattern inverts the ordinary control flow — 'I run this now' — into a deferred, conditional invocation — 'if and when this condition holds, run this on my behalf.' It is the structural device by which an agent commits to a future response without having to wait for the triggering event, and without retaining authority over the moment of action. Three structural commitments are essential: registration (a handler is given to a holder along with a binding condition specifying when it should fire); suspension (the registrant does not block waiting for the condition — control returns immediately and it proceeds with other work); and deferred invocation (when the condition is met, the holder invokes the handler, possibly in a different thread of control, possibly long after registration, in a context the registrant could not fully anticipate). Together these distinguish the callback from a simple instruction: the action is handed across a boundary of control, held by someone with better visibility of the triggering condition, and fired by that holder on the registrant's behalf. The structure carries a consequential asymmetry: because the handler is invoked by a foreign party at a moment the registrant does not choose, the registrant must reason in advance about what the handler is entitled to assume when it fires, how long the registration remains valid, and what happens if the condition occurs more than once or while another handler is still running — structural questions any callback, in any substrate, must answer.
Broad Use¶
- Asynchronous computation: event handlers, completion notifications, and the observer pattern — a handler registered and fired later by a system with visibility of the event.
- Contract law: contingent clauses and standing instructions, lodged in advance with a party who executes them when the condition arises.
- Medicine: advance directives — a patient registers a handler with the clinical system, to be invoked when specified conditions occur.
- Operations and incident response: standing orders, runbooks, dead-man switches, and escalation policies.
- Diplomacy and security: conditional commitments and rules of engagement held by an alliance or command structure against a triggering event.
- Personal coordination: "ping me when it arrives," handing a continuation to someone with better situational visibility than oneself.
Clarity¶
It makes visible who holds the continuation, refactoring "what does each actor do next?" into "who holds whose handlers, under what trigger?" — and forces four lifecycle questions: trigger semantics, invocation context, registration lifetime, and re-entrancy.
Manages Complexity¶
It decouples two parties in time — the registrant works on, the holder watches, invocation closes the loop only when warranted — so a single thread can attend to many pending conditions instead of blocking on each.
Abstract Reasoning¶
The structure forces reasoning about idempotency (a handler that may fire twice must tolerate it), expiry (registrations stale out and must be refreshed), trust transfer (registration gives the holder authority to act in your name), and the inversion-of-control diagnostic ("who holds handlers I don't see?").
Knowledge Transfer¶
- Computation, law, medicine: the four-question rubric — trigger semantics, context, lifetime, re-entrancy — is the portable checklist for any deferred conditional action.
- Idempotency and expiry: a handler safe to run once must be safe to run twice, and stale registrations must be refreshed, whether the registrant is code, a contract, or a patient.
- Inversion-of-control probe: "who holds handlers I do not see?" applies to debugging, auditing standing orders, and reading contingent clauses alike.
Example¶
A patient's advance directive — "if I am in an irreversible coma, do not resuscitate" — is a handler lodged with the clinical team (the holder), who enacts it when the condition holds, in a context the patient cannot be present for; registration transfers authority to act in the patient's name.
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
- Callback is a kind of, typical Delegation of Authority — The file: a callback is 'a narrow, mechanical special case of authority transfer: one action, one condition, no judgment' — registration transfers authority to the holder to act in the registrant's name. A specialization of delegation_of_authority (which grants broad ongoing discretion). Tentative — the file walls them sharply.
Path to root: Callback → Delegation of Authority → Authority
Not to Be Confused With¶
- Callback is not Feedback because a callback is a deferred conditional action fired once (or per trigger) across a control boundary, whereas feedback routes a measured output back to modify input, closing a continuous regulatory loop.
- Callback is not Delegation of Authority because a callback hands off a single specified action on a single condition with no discretion, whereas delegation grants ongoing, discretionary authority within a remit.
- Callback is not Publish–Subscribe because a callback is the registrant's own action lodged to fire on the registrant's behalf, whereas publish-subscribe broadcasts events to many subscribers who independently decide what to do.