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

![Published API action configuration with method, system, endpoint and input parameter](https://docs.amonsul.io/assets/d082599f1d3c729d.jpg)

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

![Sequence action flow with five actions and mappings from run context and earlier outputs](https://docs.amonsul.io/assets/b38520fed6c720ab.jpg)

*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](https://docs.amonsul.io/developers/workflow-json/).

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](https://docs.amonsul.io/guides/screens/#read-a-policys-sequence-mappings)
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](https://docs.amonsul.io/concepts/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.

```mermaid
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?

![Existing claim entity with current matrix, processing timeline and registration history](https://docs.amonsul.io/assets/bdd5253b1ebddb8a.jpg)

*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](https://docs.amonsul.io/guides/execution-limits/) and
[common problems](https://docs.amonsul.io/guides/common-problems/) explain the limits and the
investigation path.