Triggers

Where the watch begins. External stimuli that spawn operational lifecycles.

Method step: Watch. The first move is always external — operations begin when the world stimulates the system.

Why triggers are first-class

Every operational engine has external feeders. An order arrives in the warehouse. A patient is admitted to the ward. A brief lands in the agency inbox. A signup webhook fires from the marketing site. A regulator opens a filing window. A supplier confirms a shipment. A sensor crosses a threshold.

These are not ordinary inputs. They have a special role: they spawn lifecycles. Until a trigger arrives, there is nothing to watch. After a trigger arrives, a new thread is alive in the system, waiting to be advanced.

Most operational software treats triggers as just "events that arrived." That collapses two distinct ideas into one. ContextOS separates them: a trigger is the kind of stimulus that opens a new thread; everything that follows is a stimulus that advances the thread that already exists.

A trigger spawns a thread. A stimulus advances one.

What makes something a trigger

The defining test is simple. Ask: does this input start a new lifecycle that didn't exist a moment ago, or does it move forward a lifecycle that's already alive?

If it starts something new, it's a trigger. If it moves something existing forward, it's an ordinary stimulus arriving on an already-live thread.

Triggers come from the outside. They cross the boundary into the system. They come through the same nine stimulus channels as everything else — webhook, inbound email, sibling system pull, scheduled cron, even a human pressing a button — but they carry the special metadata that says start a new thread of this type.

Trigger types across domains

Vocabulary changes. The shape doesn't.

Commerce & supply chain

Order received — spawns the order-fulfilment thread
Stock-low alert — spawns the replenishment thread
Supplier confirmation — spawns the inbound-receipt thread
Return initiated — spawns the reverse-logistics thread

Healthcare

Patient admitted — spawns the inpatient-stay thread
Lab result posted — spawns the result-review thread
Discharge approved — spawns the discharge-coordination thread
Medication ordered — spawns the dispensing thread

Field operations

Brief intake received — spawns the activation-planning thread
Roster locked — spawns one shift-execution thread per shift
Complaint logged — spawns the resolution thread
Anomaly flagged — spawns the investigation thread

Finance & back-office

Payroll cycle ticks — spawns the weekly-payroll thread
Invoice issued — spawns the collection thread
Tax filing window opens — spawns the filing thread
DSR (data subject request) received — spawns the privacy-response thread

Household & everyday

Homework assigned — spawns the homework-due thread
Appointment booked — spawns the reminder thread
School notice arrives — spawns the action thread

Same engine. Different vocabulary. Different tempo. Identical shape.

Trigger registration

For ContextOS to act on a trigger, it must know which incoming stimulus opens which thread. This is registration, declared once per integration.

A trigger registration says, in plain terms:

This source (e.g. a payment gateway webhook, an inbound email to a particular address, a scheduled cron, a user CTA on a particular screen)
Sending this shape (signed payload, parsed message body, structured event)
Spawns a thread of this type (order-fulfilment, inpatient-stay, shift-execution, etc.)
With this tenant scope (which agency, which clinic, which household)
And carries this identifying key (order_id, patient_id, shift_id) that becomes the new thread's correlation key

Once registered, the engine handles the rest: dedup the trigger so the same source can't double-spawn, scope the new thread's tenancy chain correctly, schedule the first heartbeats per the thread's spec, and emit the trigger event to the canonical log.

Registration is configuration, not code. Editable per tenant. Versioned and audited.

The distinction matters at scale

In a small system you can get away with conflating triggers and ordinary stimuli. In a large one you cannot.

A medium-sized brand-activation agency runs ten to fifteen concurrent campaigns, each spawning dozens of shift-execution threads per day, each receiving hundreds of stimuli through the day. A regional hospital runs hundreds of concurrent inpatient stays, each with thousands of stimuli. A household runs maybe fifteen threads at once, with stimuli arriving in trickles.

If the engine can't tell trigger from stimulus, every input forces a question: is this opening a new thread or not? Asked thousands of times per minute, the answer has to be cheap and unambiguous. Trigger registration makes it so.

This separation also keeps the substrate clean. The thread catalog declares what kinds of lifecycles exist. The trigger registry declares what spawns each. The stimulus channels declare how everything else arrives. Each layer is small. Together they describe a complete operational picture.