Deep dive
Everything that happens is an event.
The lab speaks in messages. The event runtime is what makes that mean something.
Inside the Operate layer, side effects are not a byproduct — they are the point. Every action the agent takes and every approval gate that opens or closes reaches a single event backbone built on NATS, alongside the infrastructure signals that source adapters are wired to carry. Not because the technology is fashionable, but because an append-only, subject-routed message system is the natural shape of a lab that needs to know what happened, when, and in what order. What reaches the backbone, and by which route, is the subject of the rest of this page — the answer is less obvious than "everything publishes".
One backbone, many voices
NATS is a lightweight publish-subscribe messaging system. In the Operate layer it fills a specific role: a shared nervous system through which every component can speak and listen without knowing who else is in the room. Source adapters publish. The bridge subscribes. The operator ledger does neither — it is upstream of the runtime entirely, and a tailer derives one event from each ledger line. None of these components are coupled to each other directly. They are coupled only to the subject namespace and the schema, the two contracts that give the system its coherence.
This is not a queue in disguise. A queue moves work. An event backbone records what happened and lets any interested party draw its own conclusions. The distinction matters for a system whose primary obligation is accountability.
Five roles, one runtime
Events are not free-form. Each carries a defined schema — a typed contract specifying what fields are present, what they mean, and what constraints they satisfy. A schema is not optional here: without one, consumers cannot trust what they receive, and the audit trail cannot index what it stores. The schema is the handshake between every producer and every consumer, made explicit.
Events travel on named subjects — the addressing layer of the runtime. A subject identifies what happened and where in the system it happened. Producers write to a subject; consumers subscribe to subjects or subject patterns. The subject hierarchy is, in effect, the vocabulary of the lab's internal language: a grammar for things that occur.
The store gives events durability. Published messages do not vanish after delivery; they accumulate in an ordered, replayable log. This is what separates an event-driven system from a fire-and-forget notification scheme: you can go back. You can replay. You can answer questions about the past that no one thought to ask at the time.
The bridge connects the runtime across topological boundaries, between the operator layer and anything that lives outside it. Events that need to cross a boundary travel through the bridge, which handles the mechanics of that crossing without letting each side reach into the other's internals. The boundary stays hard; the information still flows.
Source adapters are the translators. The real world does not speak in typed events. A host changes state. A backup job completes. A network alarm fires. Adapters watch these signals through the governed connectivity layer and translate them into well-formed events the runtime can reason about. The translation is explicit, typed, and goes through schema validation before anything downstream sees it.
Why this shape fits
Event-driven systems earn their complexity by solving three problems at once — and in a governed-autonomy context, all three matter.
Auditability becomes structural rather than bolted on — but not by collapsing two records into one. The append-only operator ledger is the sole audit authority. A dedicated tailer derives exactly one replayable event from each complete ledger line, carrying that line's number and a hash of its contents, and publishes it to the event store. The direction is fixed and one-way: the ledger is the origin, the event stream is a mirror of it. Nothing downstream can become a second origin, and a lost stream is rebuilt by replaying the ledger rather than restored from a backup of itself.
Decoupling is real, not rhetorical. An agent that calls infrastructure directly, or a script that polls and acts in the same breath, creates invisible dependencies. The event backbone breaks that link. Source adapters translate real-world signals; consumers subscribe to what they care about. Adding a new subscriber (a new check, a new alert, a new archival hook) does not require touching the producer. The capability registry can still gate what the agent may do; the event runtime handles what it actually did.
Observability is first-class, not reconstructed after the fact. In a system built around event sourcing, "what happened?" is not answered by grepping application logs. It is a query against a structured, ordered, typed record. The shape of the runtime is also the shape of the answer.
The ledger is the record. The event stream is what the ledger sounds like from the outside.
Part of the governed-autonomy stack
The event runtime does not sit beside the governed-autonomymachinery — it observes it. Every agent action that flows through the capability registry and RBAC policy lands in the operator ledger, and every complete ledger line becomes an event. The ceiling and the record are enforced on the governed path itself; the runtime is what carries the record outward, where the rest of the lab can subscribe to it. Autonomy without a ledger is just automation — and a ledger nothing can read is just a file.