Pull Flow¶
Core Idea¶
An activity is triggered by a downstream demand signal rather than scheduled by an upstream producer. The essential commitment is not who does the work or how much, but who initiates each unit and what signal initiates it — push (producer-paced) and pull (consumer-paced) being duals over where uncertainty is absorbed.
How would you explain it like I'm…
The Push-Button Cooler
Think about a lemonade stand. In one way, you make a cup only when a customer walks up and asks for one. In another way, you make a hundred cups in the morning whether anyone shows up or not. Pull flow is the first way: you wait for someone to ask before you start. The asking is the signal that turns you on.
Make It When Asked
Pull Flow is when work only starts because something downstream asks for it, instead of being scheduled ahead of time by whoever does the work. The person who wants the result is in charge of starting it: the maker waits for a request, an empty shelf, or some other demand signal before acting. The opposite is push, where the maker follows their own plan or forecast and the customer has to take whatever shows up. The real difference isn't who works or how much, it's who starts each piece and what signal triggers it. Pull saves you from guessing demand and over-stocking, but it can make the customer wait.
Demand-Pulled Work
Pull Flow is the arrangement in which an activity is triggered by a downstream demand signal rather than scheduled by an upstream producer. Control sits with the consumer of the output: the producer waits for an explicit pull, a request, a falling stock level, or a binding signal, before activating, instead of running on a schedule set without reference to consumption. Push is the dual, where production is paced by the producer's own forecast or rhythm and downstream consumption must absorb whatever arrives. The essential commitment is not about who does the work or how much, but about who initiates each unit and what signal initiates it. Three pieces recur: an activation locus (consumer for pull, producer for push), a demand-signal channel that pull requires and push does not, and a latency-coupling trade-off. The deep choice is where to absorb uncertainty, in inventory for push or in latency for pull, and the two have different failure modes: push fails by forecast mismatch (glut or stock-out), pull fails by the consumer waiting. The arrangement can even be mixed, with a decoupling point separating an upstream push regime from a downstream pull regime.
Pull Flow is the structural arrangement in which an activity is triggered by a downstream demand signal rather than scheduled by an upstream producer. The locus of control sits with the consumer of the activity's output: the producer waits for an explicit pull, a request, a falling stock level, a substrate appearing, or a binding signal, before activating, instead of running on a schedule whose pacing is set without reference to consumption. Push is the dual: production paced by the producer's own plan (forecast, schedule, default rhythm), with downstream consumption obliged to absorb whatever arrives. The essential commitment is not about who does the work, nor how much is done, but about who initiates each unit and what signal initiates it. Three structural pieces recur: an activation locus, which pull places at the consumer and push at the producer; a demand-signal channel, which pull requires to exist and to be fast enough while push does not; and a latency-coupling trade-off, since pull removes the need for forecast buffers but introduces consumer wait, while push removes consumer wait but requires forecast accuracy and buffering against forecast error. The choice between regimes is fundamentally a choice about where to absorb uncertainty: in inventory (push) or in latency (pull). The two have different failure modes, push failing by mismatch between forecast and actual demand (glut or stock-out) and pull failing by latency between demand and response, and the arrangement can be mixed, with a decoupling point separating an upstream push regime from a downstream pull regime.
Broad Use¶
- Manufacturing (canonical): a returning kanban card authorizes the next unit, versus MRP scheduling from forecast and accumulating inventory.
- Biology: the lac operon transcribes enzymes only when lactose is present; the substrate is the pull signal.
- Immunology: antigen-pulled clonal expansion versus constitutive innate surveillance.
- Software: lazy evaluation and on-demand serverless compute versus eager evaluation and prefetching.
- Energy grids: demand-response load-shifting via real-time price versus base-load scheduling.
- Retail: vendor-managed inventory where point-of-sale data pulls replenishment versus forecast-and-push shipment.
- Education: just-in-time instruction triggered by an immediate task versus a front-loaded curriculum.
Clarity¶
Separates throughput questions from activation-control questions, and reveals that the demand signal itself is infrastructure — a pull regime breaks if the consumer-to-producer channel is missing, slow, or noisy.
Manages Complexity¶
Compresses a sprawling family of design choices — buffer sizing, forecast investment, latency budgets, idle-state management — into one question: who initiates each unit, the producer or the consumer?
Abstract Reasoning¶
Trains a reasoner to ask where the activation locus sits, where demand uncertainty is absorbed (inventory under push, latency under pull), and whether the system is mixed with a decoupling point separating upstream push from downstream pull.
Knowledge Transfer¶
- Stream processing: kanban back-pressure ports verbatim — consumers pull events and producers pause when consumers slow.
- Electricity grids: demand-response maps the kanban logic onto consumption-generation with real-time price as the pull mechanism.
- Software evaluation: lazy evaluation mirrors the lac operon — produce only when the substrate (request) arrives.
- Safety-critical control: the non-transfer caveat — where consumer wait is catastrophic, pull is non-viable and push-with-buffering is the only safe regime.
Example¶
On a kanban line a card returning from downstream authorizes one replacement unit, and the upstream station idles with no card — the same posture as serverless compute, where an inbound request spins up a function and the idle producer is the scaled-to-zero cold state.
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
- Pull Flow is a kind of Contextual Mode Switching — Recorded as the candidate-style reading, but flagged DELIBERATE-NON-CONFUSION risk: the file argues pull_flow and its nearest contextual_mode_switching (0.820) are ORTHOGONAL (who-initiates- each-unit vs which-mode-is-active), so a child_of edge there would VIOLATE the phase_c distinction. Therefore the honest decision is to NOT connect to the nearest. There is no other genuine parent: the file severs bottleneck, feedback (back-pressure is a consequence, not a parent), latency, and lean/JIT (programs that implement it). The correct verdict is effectively LEAVE -- pull_flow is a "parentless foundational flow-control" prime per its one_liner. Treat this record as LEAVE; do not draw the contextual_mode_switching edge.
Path to root: Pull Flow → Contextual Mode Switching → Adaptation
Not to Be Confused With¶
- Pull Flow is not Contextual Mode Switching because mode-switching selects which behaviour is active whereas pull flow fixes who initiates each unit — orthogonal variables that can co-occur.
- Pull Flow is not a Bottleneck because a bottleneck is the capacity-limiting stage whereas pull flow is the activation regime; the same bottleneck can run under either push or pull.
- Pull Flow is not Feedback because back-pressure is only one consequence of a pull regime, whereas feedback is the general loop and most feedback has nothing to do with activation control.