Run a policy

Amon Sul applies configured policy to an entity, such as an invoice or claim. The integrating application supplies the entity’s business meaning. Amon Sul runs the declared work, interprets its result through policy, and records the execution.

How the pieces fit

Piece	Its job	Example
Entity	The thing whose process you are following	An invoice awaiting review
Action	One operation: CALL, CHECK, CODE, or ODATA	Check required invoice data
Sequence	Connect actions and pass inputs and outputs between them	Fetch data, check it, then calculate a result
Policy or matrix	Decide which sequences are available at a status and how their outcomes route	Keep the invoice under review when data is missing
Published version	Fix the definition used for that version	The reviewed policy and its referenced sequence versions
Lane	Separate execution data and integration targets	Production and a nonproduction test lane

Actions execute work. Sequences connect that work. Policies interpret its facts. Putting the next business status inside an action’s code hides a policy decision in the execution layer; define that routing in the policy instead.

Prepare the definitions

Build or select the actions, their input/output contracts, and the sequence that connects them. Map each action’s inputs from caller data and earlier outputs. Declare the exit conditions that the policy must interpret.

A local CALL action shows the operation and its input mapping. This published configuration is read-only. Its preview is illustrative; no test request was run.

The local Credit claim sequence connects five actions. Actions shows the flow and the selected step’s mappings; Sequence Inputs describes caller input.

Attach the sequence to the relevant policy status and define the routes for its outcomes. A successful run can also preserve the current status when the policy explicitly chooses that result. For importable examples and exact field names, use the Matrix JSON guide.

Drafts are editable working definitions. Publish the definitions that should be executable; published versions are immutable. Review the referenced versions when publishing a policy so the executable configuration is the one you intend.

See the screen guide’s policy mapping example for the place where sequence outcomes and technical failures route to statuses.

Select the execution context

Select the tenant and lane containing the entity and its policy binding. Definitions are shared across lanes, but entities, bindings, external systems, credentials, and webhook destinations belong to a lane.

If a sequence calls an external system, confirm that the execution lane has an active system with the required code and appropriate credentials. Amon Sul does not fall back to the production target when a test-lane target is missing.

Browser operations use the active lane. An integrating system uses the lane and association authenticated by its machine key; changing a request payload cannot select a different lane. See Lanes for that boundary.

Start and inspect the run

Open the entity and use a sequence offered for its current policy status, or start it through the integrating application. Availability depends on the binding, status, access, and whether another run owns the entity’s processing lock. Supply the inputs required by the sequence contract.

flowchart LR
  E["Entity and current status"] --> Q["Admit sequence in its lane"]
  Q --> A["Execute ordered actions"]
  A --> O["Produce facts and exit conditions"]
  O --> P["Apply policy routing"]
  P --> H["Record result and notify subscribers"]

Follow the execution in the entity history and Action Log. Keep the run and action identifiers when investigating a result. There are three separate questions to answer:

1. Execution: did the action complete, or did a technical error prevent it?
2. Outcome: which exit condition did it produce?
3. Routing: which status did the policy select, or did it preserve the status?

This local entity shows its registration event and current dealer status. It has no sequence executions yet; the image does not demonstrate a completed policy run or every track of its composite policy.

For example, a required-data CHECK can complete correctly and report missing data. That is a business outcome for the policy to interpret, not necessarily a broken worker. Correct the relevant data and follow the next permitted action.

Follow delivery to another application

An execution’s events can notify configured webhook subscribers. Finishing the run and receiving the callback are separate stages. If the destination has not updated, correlate the execution event with its delivery and the destination’s receipt before running the sequence again.

An HTTP destination may accept a mutation before a worker records the result. Use the run evidence and the destination’s audit record to establish what happened. The execution limits and common problems explain the limits and the investigation path.