One effect, in order Diagram

The short answer

• The kernel records the step, the worker checks and proposes the effect to the gate, the handler runs only on allow, and the worker settles the result and completes the intent

Not shown here

• Denial and escalation paths, retries and the person's approval record, which branch from the verdict step
• Connected but out of scope: Check pipeline, Admission, poly-runtime, Ledger, Polyx advisor

Doctrine

• An effect meets five refusals before the policy engine decides: origin, memory, budget, grant and mandate each refuse or escalate finally whatever a policy says; only then does the Polyaxion gate propose

One effect, in order

What happens, in order, to a single effect a machine emits?

This is the one place poly joins two engines that did not know about each other: a kernel that runs effects at least once and a gate that mediates calls in two phases. The order in which the checks, the gate and the handler meet is the design.

The long read

The runtime dispatches an action on the polyrun kernel. If the machine accepts it, the step commits with its outbox row and, in the same transaction, the ledger's step event.

The Effect worker claims the row. Before the policy engine is asked anything, the worker applies five refusals in a fixed order: the envelope origin, the memory and flow check, the budget, the grant and the mandate. Each is final whatever a policy says. Only an effect that passes them is proposed to the Policy gate, with the labels and class of the effect and the emitting step's snapshot.

The gate asks Polyaxion and returns allow, deny or escalate. The worker records the verdict in the ledger. On allow it calls the handler, which performs the effect at least once and reports what it observed. The worker settles that observation with the gate and dispatches the completion action to the kernel. On deny or escalate it dispatches the declared failure action instead, with the reason.

Terms used here

gate: The two-phase mediation of an effect: propose before the call, settle after it. The Polyaxion engine decides allow, deny or escalate.
outbox: The table in which a step leaves its effect intents. The effect worker takes them out one at a time, at least once.
ledger: The record of every step, advice, decision, outcome, gate verdict and effect of a run, hash-chained per run with signed heads and a periodic anchor.
idempotency key: A value sent with a write so that the receiver can recognise a retry of the same request and do the work once. In poly it is the intent id, and the runtime sets it.
irreversible effect: An effect whose result cannot be taken back once it has happened, such as a refund or a message sent. poly requires such an effect that may be attempted twice to say how it is kept from running twice.