The three jobs
Triage decides, composerID publishes, your systems execute. composerID exists to keep those three jobs separate, and to give every record they produce one shared reference: the Intent ID.1
Triage decides
Someone needs work done. Triage asks the diagnostic questions, classifies the request and recommends a route. The output is a decision with its reasoning attached. Triage owns this job; nothing downstream second-guesses it.
2
composerID publishes
composerID mints the Intent ID for the decision, reads the destination’s own configuration, resolves the decision into the destination’s vocabulary, and publishes a valid record carrying the Intent ID. It does not make the decision again and it holds no competing copy of the workflow.
3
Your systems execute
The vendor management system, HR system, procurement platform or contract system carries on doing what it was bought to do. The requisition, the order and the position live where they always lived, each carrying the same reference.
The Intent ID
The Intent ID is the reference every system shares. It is deliberately plain: it matches^[A-Za-z0-9_-]{10,64}$, so it survives being written into other systems’ identifier fields, and it never changes. Amendments increment intent_version; the identifier stays.
In the Triage-fed chain the Intent ID is minted deterministically from the assessment response that produced the decision, so a replayed completion event re-derives the same Intent ID and cannot fork the record. The Intent ID page covers its shape, versioning and where it lands in each destination.
Before anything is written
Vendor documentation describes the standard API. A customer’s own tenant adds mandatory fields, custom fields, picklists and approval rules that no vendor document knows about. composerID reads the tenant’s configuration first and resolves the decision against it in a preflight step. A gap becomes a question back to the requester, expressed in the requester’s own words, rather than a failed call after they have moved on. See Publishing for the preflight and enrichment loop.Publishing is safe to retry
Networks time out and buttons get clicked twice. Every publish is identified by a deterministic key,{intent_id}-{intent_version}-{target_system}, and the adapter looks for an existing record carrying the Intent ID before it creates one. A repeated publish returns the original receipt.
For a given decision and version there is at most one record per destination, and composerID can name it.
What crosses the boundary
A destination receives a valid request plus the Intent ID. It does not receive the diagnostic questions and answers, the score, the ranked alternatives or the evidence pack behind the decision.The boundary is structural, not procedural. The payload an adapter publishes from contains only request fields, so there is no configuration path from diagnostic material to a destination field. Score and manuscript explains the two paths in full.
Knowing what happened next
Where a destination pushes events, composerID subscribes to the start of each lifecycle it cares about, verifies each delivery and lands it on the Intent ID’s timeline. Duplicates are discarded on the delivery’s own event id: thedelivery_id the generic envelope carries for that purpose, and the event id the Beeline receiver de-duplicates on. Where a destination offers an event-history endpoint, recovery after an outage replays history rather than hoping the push arrived. Events and the timeline covers verification, the timeline and reconciliation.
The Intent API described across these pages is served today by the reference sandbox, over mock destination tenants, and held to the documented contract by a conformance pack that runs in continuous integration. Destination pages state how far each integration has progressed: Specification mapped, Documented or Roadmap.
Next steps
The Intent ID
Shape, minting, versioning and where it is written.
Publishing
Plan, preflight, publish, and the idempotency key.
Quickstart
Run the reference sandbox and publish a decision.