How Assurance records fit together
Organisations, projects, locations, movements, loads, and the evidence that connects them.
On this page
Organisation → Project → Location → Movement → Load
An organisation owns its workspace and grants access. A project groups the work. A location identifies a physical place within that project. A movement is the material journey and its assurance case; a load is an individual vehicle or batch occurrence.
The legacy API calls its location discovery endpoint /sites. Keep existing integrations using their documented contract; do not assume a site is a project or that a display name is a unique identifier.
Keep source IDs and Nexus references
Store the Nexus reference returned by each write with the source record. A booking ID, document ID, and ticket revision have different meanings. Decide grouping before creating records, and retain those decisions when a source system retries or corrects a record.
Keep existing externalId values compatible. Namespaced lookup and alias management are not available merely because they are described in a future integration plan.
Evidence has its own lifecycle
A document supports a movement, load, or information request. Its intended target matters. Sending bytes, attaching evidence, receiving a review result, and resolving the case are different stages.
A correction must preserve the original document and its history. Do not overwrite source files or treat the absence of an error as proof that a review passed.
Your facts and Nexus decisions
Your system supplies operational facts such as bookings, vehicle details, and quantities. Record where each fact came from. Nexus review outcomes and authorised human decisions have separate provenance.
An integration must not manufacture a human sign-off, substitute a reported logistics status for an assurance verdict, or create access to another organisation. Use the product’s authorised human action when one is required.