> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Automations

> Standing rules that start governed Actions, Workflows, and operational agents.

An automation is a standing rule declared in a product construction module under
`modules/`. One condition starts one Action, Workflow, or operational agent.
Each occurrence runs under the automation's declared service authority. Actions
still enforce their ordinary input, permission, and review requirements.

## Triggers

| Condition               | Occurrence                                                               |
| ----------------------- | ------------------------------------------------------------------------ |
| `time`                  | A cron instant in the declared time zone.                                |
| `object.created`        | Creation of an object of the declared type.                              |
| `object.properties_set` | A change to watched properties, optionally filtered by their new values. |
| `dataset.changed`       | Publication of a new content version of the declared dataset.            |
| `stream.changed`        | An observed or idle event for one series in a declared stream.           |
| `file.created`          | Creation of a file, optionally filtered by its name prefix or suffix.    |
| `event`                 | A declared domain Event or authenticated named signal.                   |

A time condition chooses `fire_once` or `skip` for missed ticks. A stream
condition delivers every occurrence by default, or keeps the newest pending
occurrence per series with `coalesce: latest`. Its optional horizon supplies
the start of the history window to the target.

Inputs can contain declared literals and bindings to values supplied by the
occurrence, such as its subject key, file version, dataset transaction, or
scheduled instant.

## Delivery and execution

An Action commits its domain Events before their automation reactions run.
Each reaction has its own delivery outcome and retry budget. One failed reaction
does not block another or change the source Action's result. Recovery preserves
the activation that accepted the original event, even after the product changes.

Transient delivery failures retry. A terminal failure settles that occurrence;
a failed time occurrence can still leave the next tick armed. Target execution
has its own Run, where you inspect progress, reviews, and results.

## What a signal handler may keep

A provider-signed webhook may attest one bounded metadata-only occurrence to the
named-signal ingress. This is **not** a source subscription and not a source-data
read. The handler may retain only:

* the provider-stable occurrence identity
* the signal name
* the stable subject key

It must discard the request body and every source property value. It owns no
cursor and no retry queue.

A verified occurrence may additionally enqueue one signal-scoped capture of
exactly one named declared dataset — running through the same singleton lease,
complete-dataset staging, and atomic publication as a cadence tick, with no
separate ingestion path.

<Note>
  Provider subscription configuration stays provider-owned unless a specific
  connector explicitly earns a fixed signed ingress route.
</Note>

## Inspecting them

Open **Automations** to inspect the active rule, complete condition, next tick,
last dispatch, causal suppression, and delivery health. Follow its Runs to
inspect execution. A failed delivery remains visible even while the rule is
active or its next tick is armed.

```bash theme={null}
atelier automations signals
atelier events list
```