# Getting started

Use a nonproduction lane and a disposable entity for your first run. You need
tenant access and permissions to configure definitions, bindings, and integrations.
Ask your administrator for access to an existing workspace and a test lane.
Open that workspace's address and sign in there. A shared
identity in another product does not grant Amon Sul access; the workspace needs
its own membership, active local account and permissions. Read
[sign-in and workspace access](https://docs.amonsul.io/guides/sign-in-and-access/) for invitations and recovery.

## 1. Understand the model

Read [core concepts](https://docs.amonsul.io/concepts/core-concepts/), then open the
[screen map](https://docs.amonsul.io/guides/screens/). Actions, sequences, and policies are shared within
the tenant. Entities, bindings, and external systems belong to the selected lane.
A test lane does not create a private copy of the definitions.

## 2. Prepare a small policy

Start with a CHECK or CODE operation whose input and output you understand.
Create its action, connect it in a sequence, and map sequence-start inputs into
the action. Attach the sequence to a policy status and define the exit-condition
routes. Include the intended initial status and the route when data needs attention.

Use [Matrix JSON guide](https://docs.amonsul.io/developers/workflow-json/) for importable JSON.
Its [minimal bundle](https://docs.amonsul.io/downloads/minimal-matrix-bundle.json)
and [CHECK](https://docs.amonsul.io/downloads/check.json),
[CODE](https://docs.amonsul.io/downloads/code.json),
[CALL](https://docs.amonsul.io/downloads/call.json) and
[ODATA](https://docs.amonsul.io/downloads/odata.json) examples
are checked by contract tests. They are templates to review, not a guarantee that
your tenant has the example's external connection.

Have the definition administrator validate the bundle before importing.

Importing or publishing changes tenant definitions. Select the intended tenant
and review the bundle and its references before doing either.

## 3. Publish and bind

Publish the reviewed definition tree. A published version is read-only; create a
new version for later edits. Select the nonproduction lane, open Entities, and
configure the entity type's policy assignment there. Check that the assignment
points at the published version you intend.

For CALL or ODATA, create an active External System in this lane with the exact
`system_code` used by the action. Supply its lane-specific target and credentials.
A missing test target does not fall back to production.

## 4. Register and run

Register a disposable entity through your integrating application or the
[public API](https://docs.amonsul.io/developers/api/). The caller supplies `external_id`
and `entity_type`; the lane binding supplies the policy context.

Open the entity, inspect its status or tracks and available sequences, then start
the intended sequence with the values required by its input contract. If it is
blocked, read the reason and resolve that condition first. Record the run UUID.

## 5. Check the evidence

Follow [Run a policy execution](https://docs.amonsul.io/guides/policy-execution/). Compare the action's
execution result, exit condition, and policy route. Open Action Log for the
inputs, outputs, and matched routing evidence. If another application should
receive the result, inspect Webhook Deliveries and that application's receipt.

Change policy through a new version, or correct business data through its owning
application, then use the next permitted action. Investigate uncertain external
effects before retrying a run.
