The unit of orchestration. One entity's lifecycle, from spawn to logical conclusion.
Method step: Watch. The substrate the engine watches across thousands of concurrent lives.
A thread is one entity's lifecycle. It begins with a trigger — an order arrives, a patient is admitted, a brief lands, a homework is assigned. It ends at a logical conclusion — the order ships, the patient is discharged, the report is published, the homework is submitted.
Between those two moments, the thread is alive. The engine watches it. Stimuli arrive and advance it. Heartbeats fire on schedule to detect what should have happened and didn't. When the thread reaches a step that requires human judgment, the engine summons the right person on the right surface at the latest safe moment.
A thread is not a workflow. A workflow says do steps A, B, C in order. A thread says this lifecycle is alive; here's what we expect; here's what's arrived; here's what's still due. The difference matters because most lifecycles don't follow recipes — they negotiate with reality.
A business runs thousands of concurrent threads. The engine watches them all at once.
Every event in ContextOS lives on at least one thread. The relationship is not loose; it is structural. Events with the same correlation key belong to the same thread. Together they form an ordered chain — beads on a string.
An event isolated from its thread is suspect. The engine flags orphan events because almost always they signal a misrouted stimulus or a registration gap. Threads make events meaningful: an order-shipped event in isolation is a fact; an order-shipped event placed correctly on the order-fulfilment thread closes a step and exposes the next expected stimulus — the customer's delivery confirmation.
This is what makes "show me exactly what happened in store X at 14:32 last Saturday" tractable. You don't grep logs; you replay the threads alive at that moment.
Inside a thread, each step has three pieces:
When a step is entered, the engine schedules its heartbeats immediately for their future firing times. When the expected stimulus arrives, the step closes and the next step's expectations become live. When the stimulus doesn't arrive in time, the heartbeat fires and the engine routes a signal — surface to the action queue, escalate via the locator, or auto-emit a downstream event if policy allows.
The shape is the same whether the thread is a four-hour shift execution or a thirty-day data-subject request. Different tempo, identical mechanics.
Real lifecycles don't always go forward. A promoter declines a shift, and the thread branches to a replacement-search path. A patient transfers wards mid-stay, and the thread splits across the new ward's care team. An invoice is rejected, and the thread enters a dispute path.
Threads support branches as first-class transitions. A branch is just an alternative next step that fires when a different event arrives. The thread doesn't "fail" — it follows a different valid path to a different valid terminal.
Compensating events are how the system models corrections to immutable history. You can't un-emit an event — the log is append-only. But you can issue a compensating event (order-cancelled, payment-refunded, certification-revoked) that the thread treats as a rewind to an earlier step. The forensic trail stays intact; the lifecycle continues from a known point.
Every thread reaches a terminal. The engine guarantees this by design — no thread is allowed to die quietly. A terminal is one of:
If a thread has neither received its expected events nor any branching ones for an extended period, the sweep heartbeat picks it up and surfaces it as stuck. Operators see "this thread has gone quiet for seven days — what happened?" before it falls off the radar entirely.
When a thread closes, the engine emits a meta-event that records its disposition, marks pending heartbeats as superseded (audit-preserved, not deleted), and triggers any hand-off to dependent threads — a shift's day-close hands off to the day's reconciliation thread, an invoice's collection hands off to the next quarter's brand-relationship thread.
Some events live on multiple threads. A shift's day-close is the terminal of the shift-execution thread and a stimulus that contributes to the day's reconciliation thread and a stimulus that feeds the week's payroll thread. A KYC expiry closes the KYC thread and renders all of that promoter's future shifts ineligible — affecting many shift-execution threads at once.
The engine handles this by treating each event as having a primary thread (where it lives canonically) and zero or more secondary threads (where it appears as a reference). The relationship is bidirectional and discoverable from either side. No thread is an island; every thread can see its inbound and outbound dependencies.
This matters because most operational mistakes happen at thread boundaries. A discharge that should have triggered a billing review but didn't. A shift close that should have updated a brand report but didn't. Cross-thread events make those handoffs explicit and the engine's responsibility to deliver.
A working parent runs maybe fifteen concurrent threads at any moment. A charge nurse runs thirty patients on overlapping schedules. A mid-sized brand-activation agency runs ten to fifteen campaigns spawning dozens of shift-execution threads per day. A regional hospital runs hundreds of concurrent inpatient stays. A national logistics operator runs tens of thousands of in-flight shipments.
The engine's job is to watch them all. Per-thread state is small. Per-thread heartbeats are cheap (most fire and suppress without consequence). The only expensive operation is the moment a heartbeat fires and the engine has to evaluate, route, and possibly summon — and that's the operation that earns the cost, because it's the moment a human's judgment is genuinely required.
Storage is not the problem. Attention is. Threads are how we keep attention on what matters and off what doesn't.
Meet stimuli — the source-blind inputs that move every thread forward.
Calm technology with teeth.