Skip to main content

Automations

Automations let the estate react to its own events. An automation rule watches a value (a metric, a catalog object, a governance signal) and fires when a condition first becomes true, so the estate can respond to a change instead of a human polling for it. Firings are recorded into a hash-chained log, consistent with the rest of the platform's tamper-evident discipline. And where a rule is bound into a clean room, its action is treated as an egress: it must clear the room's egress policy and the value gate before it is allowed to act.

How a rule fires​

The engine makes one evaluation pass over every active rule. For each rule it resolves the rule's source by its kind, reads the current value of the watched object, loads the prior per-object state (an (in_range, streak) pair) and computes the new state and whether this pass is a firing edge. A firing edge is the transition into the condition, not merely being in it: a rule fires when its condition becomes true (optionally after a streak), so a persistently-true condition does not re-fire on every pass.

Figure F4: an automation evaluation pass. For each active rule the engine reads the watched value, compares it to the prior (in_range, streak) state, and on a firing edge appends a firing to a hash-chained log (green). For a clean-room- bound rule the action must then clear both the room's egress policy and the Net-Potential-Gain gate (amber) before it is dispatched with a signed receipt; if either denies, the firing is still recorded but the action does not act (red).

Table equivalent

StepWhat happens
Evaluation passThe engine iterates every active rule
ReadThe source adapter reads the current value of the watched object
Prior stateThe engine loads the last (in_range, streak) for that object
Firing edge?Fire only when the condition becomes true (optionally after a streak)
RecordAppend the firing to a hash-chained firing log; upsert the new state
Clean-room egressFor a room-bound rule, the room's egress policy must admit the action
Value gateThe Net-Potential-Gain gate must admit a mutating action
ActOn both admits, dispatch the action and its signed receipt

Clean-room automation bindings​

A rule bound into a clean room is multi-party, so its action, the firing's side effect, is an egress channel that must not bypass the room's governance. The engine consults an injectable guard for every rule that resolves the clean room a rule is bound to, whether the watched object is within that room's scope (a room rule may not observe or act on another room's or a bare workspace's objects), and whether the action's egress is admitted by the room's egress policy. A room firing acts only when both admit: the egress guard, then the Net-Potential-Gain gate for mutating action kinds. A bare workspace rule keeps its simpler behavior.

This keeps automations inside the same boundary discipline as the rest of the platform: a clean room's data and side effects stay governed even when the trigger is automatic, and the engine never hard-couples to clean-room internals, the egress-policy resolution is injected from outside.

Across the deployment matrix​

  • Single-cell, the engine runs its evaluation pass on the cell; rules watch that cell's objects and the firing log is local.
  • Multi-cell: each cell evaluates the rules for the workspaces and clean rooms it hosts; there is no central automation coordinator every cell must reach.
  • Sovereign / air-gapped, evaluation, firing, and the clean-room egress and value gates run locally with no external trigger service in the path.
  • Cloud-enabled: the same engine and the same governance; a firing is gated identically whether or not the cell has connectivity.

In the console​

Automations are managed as an Automations tab in the workspace and clean-room console, at /workspace/:id/automations and /cleanroom/:roomId/automations ("Automations, rules & triggers"), gated on the membership capability workspaces.console.read. The clean-room mount is the same tab and is where a firing becomes a governed egress (a clean-room binding).

The tab lists the available source kinds as chips, metrics, capacity bands, streams, and edge telemetry, and shows the rule list with a per-row enable/disable toggle. New rule opens a multi-step rule builder with a client-side dry-run preview; each rule offers Edit and a History view that reads the rule's signed, hash-chained firing lineage, the same firing log described above, surfaced for the operator. See Administration & Configuration for the surface map.