> ## 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.

# Actions

> The only governed mutation boundary: plan, review, execute, record.

Actions are plan → execute. The two phases are not symmetrical.

## Plan

A plan is **stateless**. It reads the action's declared dependencies at the
latest published capture and returns exactly what will change. It writes
nothing — no draft, no pending row, no confirmation token. There is no plan
store, so there is no such thing as executing a plan that went stale in a drawer.

```bash theme={null}
atelier actions plan BookVendor --target V-1 \
  --input comment='confirmed' > plan.json
```

## Execute

Execution is the only thing that mutates, and it is what produces the record. It
re-resolves the authoritative dataset transaction and refuses a stale plan.

```bash theme={null}
atelier actions execute plan.json
atelier reviews list
atelier events list
```

## Decision evidence

Every plan and every `ActionExecuted` fact carries one bounded
`decision_evidence` object containing **exactly** the target fields declared by
the action's `reads` contract.

This is the durable witness for why the decision rendered as it did. It is
deliberately not a source snapshot or an arbitrary row dump: an unbounded dump
would grow without limit, carry data under retention rules the ledger was not
designed for, and make it ambiguous which part the decision actually turned on.

## Outbound operations

An outbound `invoke` is one exact model-declared HTTP operation using the closed
POST / PUT / PATCH / DELETE method set and one closed body contract (JSON, form,
multipart-form, multipart-related, or raw file).

The sequence is fixed:

<Steps>
  <Step title="Record durable intent">
    Execution records intent and enqueues the job atomically.
  </Step>

  <Step title="Reconstruct the operation">
    One provider-neutral worker rebuilds the revisioned operation and injects its
    declared static fields, credentials, and replay token — credentials only
    *after* durable intent, and never into the retained request.
  </Step>

  <Step title="Apply the delivery contract">
    The operation's `keyed`, `convergent`, or `once` contract governs delivery.
  </Step>

  <Step title="Record the terminal event">
    Status, a bounded response digest, declared acknowledgement scalars, and a
    closed structured failure when applicable.
  </Step>
</Steps>

A file body may consume only an exact platform-native immutable file-version
reference resolved during planning. The ledger retains its identity, MIME type,
size, and digest — never its bytes. Provider response bodies are never retained.

<Warning>
  The external call is not part of the database transaction and is never described
  as exactly-once.
</Warning>

## Who can call them

Agents call the same actions humans do, through the same approval path. There is
no agent-specific executor and no privileged mutation path.

The built-in assistant is a delegated processor under the current human's
authority. It may inspect and plan, and stream a plan transiently to that human;
it cannot execute an action or decide a review. When the human confirms, the
browser replans under that human's own current authority and calls the ordinary
public executor — so the person confirms the effects as they are now.