How To Read State
Axiom uses lifecycle fields to describe platform-visible resource state. Tenant-specific labels, reason codes, product wording, and workflow policy remain tenant-owned catalogue or configuration content. If the generated reference does not publish a transition, do not infer it from a screen, example, or field name.
| Developer question | Use this source |
|---|---|
| Which fields exist on the wire? | API Reference and raw OpenAPI schemas. |
| Can this operation change state? | Operation method, summary, request body, idempotency posture, and maturity metadata. |
| What should an application display? | Published lifecycle/status values plus tenant-owned labels supplied through admitted configuration. |
| What is not yet available? | Record it as an API, catalogue, authority, or workflow gap instead of hiding it in client code. |
Build-Now Resource Map
| Resource family | State fields to expect | Alpha posture |
|---|---|---|
| Parties | Party identity status and role membership state where present. | Use for identity context. Do not turn role names into hard-coded customer types. |
| Policies | Policy, version, quote, and product lifecycle/status fields where present. | Read displayed status from the API; mutation workflows require explicit operation authority. |
| Claims and events | Claim/event status, assessment availability, audit context, and document output availability. | Build read-oriented views first. Assessment, payment, reserve, and close actions remain authority-bound. |
| Payments, invoices, and schedules | Payment or schedule status where published by the endpoint schema. | Do not assume pause, resume, cancellation, or retry behaviour unless the operation documents it. |
| Webhooks and async ingress | Delivery status, accepted transport records, and correlation fields where published. | Alpha delivery is at-least-once; stable event catalogues and replay policy are governed separately. |
State Rules For Client Applications
- Display unknown or unavailable lifecycle values plainly; do not map them to invented business meanings.
- Keep tenant-owned labels and reason codes outside platform code and public documentation.
- Use the generated operation page to decide whether a screen is read-only or action-capable.
- Preserve
X-Correlation-IDand endpoint/status evidence for every failed state-changing call. - Require explicit authority, idempotency, retry, and failure semantics before building mutation-heavy workflows.
First Application Slice
The safest first client slice is read-oriented: prove health, obtain admitted access, mint tenant context, list a small resource set, open a detail view, and display status exactly as returned. Any desired transition that is not published by the API becomes a named gap for contract, tenant catalogue, authority, or workflow design.