Actions & Review

Every mutation in Manifest — human or agent, UI or API — is an action proposal that rides one pipeline. There is no second door.

The pipeline

1. Validation. The proposal's parameters are checked against the action type's declared shape and rules.
2. Policy. Authlink's PDP decides whether this principal may take this action on this type — including any obligations the decision carries (see Access Control).
3. Guards. Platform guards run — most visibly duplicate detection: the proposal's match keys are compared against existing instances, and a suspected duplicate is surfaced rather than silently created. Guards are advisory speed; the store's unique index on the primary key is the final, race-winning enforcement.
4. Tier. The action type's review tier decides what happens next:
   • Direct actions execute immediately once the above pass.
   • Reviewed actions are staged into the review queue and wait for a human decision.
5. Execution. An approved (or direct) action executes through the platform's single execution path, raising domain events on the instance's stream. The events are the audit trail.

The review queue

Staged proposals land in a queue the designated reviewers work: approve, reject, or refer. Decisions are themselves audited, and notification routing keeps reviewers and proposers informed of movement. The queue's depth and time-to-decision are first-class operational metrics.

Previewing an action

Any action can be previewed before it is proposed: POST /api/actions/{id}/preview takes the exact body execute takes, and answers with what execute would do. That covers:

• the outcome: applied now, sent for review, or refused;
• every property it would write, before and after;
• the events it would raise;
• each guard's verdict.

Nothing is staged, committed, written back, audited, or published.

• It runs the real pipeline. Binding, validation, every guard (server-match included), the verdict, and the amend target all run through the same code execute uses, so a preview and an execution of the same input agree. Unlike execute, a preview runs every guard, so all the problems show at once.
• It cannot change anything. The preview service is built without any repository, outbox, or audit handle, and its request is a query, which is never committed. Both facts are pinned by architecture tests.
• It is gated like execute. A caller the policy denies, or one whose required reason is missing, gets execute's error, so no one can preview what they could not do. A refusal the input decides is an answer, not an error.
• Everywhere: the launcher previews on Submit and shows the diff before Confirm. Agents call any action tool with preview: true, and the SDK has PreviewAsync on every action. Batches preview through /preview-batch.

Side effects

An action can declare up to ten side effects: things that happen after its change commits.

• Webhook: posts to a target configured per environment. The ontology holds only a name, never a URL.
• Notify: raises an inbox entry for the proposer, a role, or named principals.

Each side effect carries an explicit include list of parameters and committed properties. It never carries the whole instance, and never anything Personal. Publishing refuses a target that isn't configured or a Personal field (R-25).

• Queued with the commit. Side effects are written to the outbox in the same transaction as the change. A preview, a staging, a refusal or a failed apply queues nothing.
• Delivered at least once. Each delivery is retried with backoff and dead-lettered after its last attempt. Its id is the webhook's Idempotency-Key, so receivers deduplicate. Every outcome shows under Audit → Side effects.
• Never in the way. A failing side effect cannot block or undo the change. When the external system must agree before the commit, use a writeback target instead.

The full webhook contract is in docs/side-effects.md.

Automations

An automation rule acts when something happens: on a cron schedule, when instances enter or leave a saved set, or when a proposal moves through review. It then proposes an action or notifies someone. Rules are ontology designs, authored in the designer and released through a reviewed proposal.

An automation can only propose:

• It runs as its own service principal, so the PDP judges its grants.
• Its proposals go through the same pipeline as everyone's.
• The action's review tier still decides. A HumanReview action waits for a reviewer, whoever proposed it.

Every run is logged, so a redelivered trigger never files twice. Operators can pause a rule without a release. The full guide is in docs/automations.md.

Bulk and server-matched proposals

Batch flows exist for volume work: a bulk proposal carries many candidate creations at once, and server-side matching groups suspected duplicates so a reviewer decides groups, not rows — comparable to batch-apply semantics in other ontology platforms, with the same governance as single proposals.

Why one path matters

Because execution is the only way an aggregate changes, everything expensive to retrofit comes for free: complete audit, review coverage, obligation enforcement on writes, and the guarantee that an agent's mutation is governed exactly as a human's.