Skip to main content
This page follows one statement-of-work request through every system it touches, from the Triage decision to the audit question months later, to show how the Intent ID and the idempotency keys behave at each hop. It is for architects and auditors evaluating the trace.
All identifiers, people, suppliers and amounts on this page are illustrative, and so is the chain itself. It is a reference architecture assembled from the documented mappings for these four destinations, all of which are Specification mapped; it is not a delivered deployment, and no customer tenant is implied.
The spine. Intent ID itn_Vq3kX9mR2d is minted once, immutable and URI-safe. Every publish step uses a deterministic idempotency key, {intent_id}-{intent_version}-{target_system}, so retries are designed not to create duplicates. A version bump creates new keys and leaves the old ones inert.

​
A manager asks for an outcome, not headcount

Lena Brandt, platform lead in the EMEA services programme, needs the EU reporting warehouse migrated before the Q4 close: fixed scope, roughly twelve weeks. Triage diagnoses the request instead of routing it straight to a requisition form.

​
What Triage concluded

  • work_type: service
  • Channel: SoW, confidence 0.87
  • Risk: medium
Contingent labour was considered and rejected: the ask is a deliverable with acceptance criteria, not a seat to fill. That alternate and the reason for rejecting it are recorded in the Compliance File.

​
The Compliance File

The request summary, the classification rationale and confidence, the constraints and assumptions, the alternates considered and the required approvals are bundled and referenced from the Intent Record at df://emea-services/itn_Vq3kX9mR2d/v2. The field carrying that reference is defence_file_ref: the schema keeps the document’s former name until a versioned schema rename, so expect that mismatch in the JSON below. It travels with the decision into every downstream system. Compliance File describes the document.

​
The decision becomes a portable asset

Version 1 was minted straight from Triage output. Mapping preflight for the Coupa step found one gap: cost_center_id is mandatory there, so composerID raised an enrichment request back to Lena instead of failing the publish. Her answer produced version 2. There was no reject-and-resubmit loop and no re-keying.
Intent Record v2

​
Four destinations, one deterministic plan

The Channel Map, the rules that say which kind of work goes to which destination, resolves the SoW channel for this programme into an ordered destination chain. Each step is a separate composerID publish carrying its own mapping profile and idempotency key: the destinations do not call each other. Swap Coupa for SAP Ariba by swapping a mapping profile; the Intent Record does not change.
1

Competitive sourcing in Globality

Object: sourcing event. Idempotency key itn_Vq3kX9mR2d-2-globality. See Globality.
2

Contract in Ironclad

Object: SoW workflow and record. Idempotency key itn_Vq3kX9mR2d-2-ironclad. See Ironclad.
3

Execution and evidence in DocuSign

Object: envelope. Idempotency key itn_Vq3kX9mR2d-2-docusign. See DocuSign.
4

Committed spend in Coupa

Object: requisition, then purchase order. Idempotency key itn_Vq3kX9mR2d-2-coupa. See Coupa.

​
External IDs, captured and correlated

Every create and update is keyed, logged and written back. Each destination object also carries the Intent ID (a custom field, a workflow property, an envelope field), so correlation survives outside composerID too.

​
The record stays truthful after go-live

Webhooks feed the intent timeline from every destination. In August, a EUR 4,200 change order was keyed directly into the Coupa PO: human-in-the-loop drift. Reconciliation caught the delta between the destination and the last-published intent, and programme policy said require re-approval, not silently accept. The milestones are the programme’s narrative; only the two entries shown in code are timeline event types, and Events holds the full list the TimelineEvent schema fixes. Any republish after the change order uses version 3 keys (itn_Vq3kX9mR2d-3-coupa). Retries of stale version 2 keys stay inert by design.

​
One query by Intent ID

Months on, finance asks the question every programme eventually gets: “Why did we spend EUR 148k on this engagement?” It is one query by Intent ID, and it returns:
  • The Compliance File, with the rationale and the alternates considered
  • The Globality sourcing event and award
  • The Ironclad SoW record
  • The signed DocuSign envelope and certificate of completion
  • The Coupa requisition, purchase order and invoices
  • The drift event and its re-approval
Every hop is timestamped against itn_Vq3kX9mR2d.

​
Next steps

Decision reference

How the Intent ID is minted, versioned and written into each destination’s own field.

Publishing

Plan, preflight, publish, and the idempotency key behind every step.

Events

The timeline, webhooks in and out, and how drift is detected.