> ## Documentation Index > Fetch the complete documentation index at: https://www.composer.id/llms.txt > Use this file to discover all available pages before exploring further. # The life of one Intent > One statement-of-work request followed end to end: decision, sourcing, contract, signature, committed spend and audit, under one Intent ID. 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](/concepts/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. ```json Intent Record v2 theme={"system"} { "intent_id": "itn_Vq3kX9mR2d", "intent_version": 2, "program_id": "emea-services", "created_at": "2025-06-02T09:14:22Z", "work_type": "service", "channel_recommendation": "sow", "confidence": 0.87, "risk_posture": "medium", "constraints": { "location": { "country": "DE", "remote": "hybrid" }, "start_date": "2025-07-07", "duration_weeks": 12, "budget": { "cap": 150000, "currency": "EUR" } }, "stakeholders": { "requestor": "l.brandt", "business_owner": "l.brandt", "cost_center_id": "CC-4417" }, "defence_file_ref": "df://emea-services/itn_Vq3kX9mR2d/v2", "current_state": "published" } ``` ## Four destinations, one deterministic plan The [Channel Map](/concepts/publishing), 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. ```mermaid theme={"system"} flowchart LR T["Triage decision"] --> I["Intent Record itn_Vq3kX9mR2d v2"] I -->|"1 Sourcing event"| G["Globality"] I -->|"2 SoW workflow and record"| R["Ironclad"] I -->|"3 Envelope"| D["DocuSign"] I -->|"4 Requisition to PO"| C["Coupa"] G -.->|"webhooks"| L["Intent timeline"] R -.->|"webhooks"| L D -.->|"webhooks"| L C -.->|"webhooks and drift"| L L -.->|"reconciliation"| I ``` Object: sourcing event. Idempotency key `itn_Vq3kX9mR2d-2-globality`. See [Globality](/destinations/globality). Object: SoW workflow and record. Idempotency key `itn_Vq3kX9mR2d-2-ironclad`. See [Ironclad](/destinations/ironclad). Object: envelope. Idempotency key `itn_Vq3kX9mR2d-2-docusign`. See [DocuSign](/destinations/docusign). Object: requisition, then purchase order. Idempotency key `itn_Vq3kX9mR2d-2-coupa`. See [Coupa](/destinations/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. | When (2025) | Destination | External object and status | Intent ID carried as | | ----------- | ----------- | --------------------------------------------------------- | ----------------------------- | | 8 Jun | Globality | `GLB-EVT-88412`: created | Event reference | | 15 Jun | Globality | Award to the selected supplier: awarded | Event reference | | 16 Jun | Ironclad | `WF-2419` and `RCD-99871` (Statement of Work): launched | Workflow property `intentId` | | 17 Jun | DocuSign | Envelope `9f2c1e77-...`: sent | `textCustomField` `intent_id` | | 19 Jun | DocuSign | Certificate of completion: completed | `textCustomField` `intent_id` | | 22 Jun | Coupa | `REQ-55208`, then PO `CPO-104233`: PO issued, EUR 144,000 | Custom field `intent-id` | ## 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. | When (2025) | Milestone | Detail | | ----------- | ------------------------ | -------------------------------------------------------------------------------------------------- | | 7 Jul | Delivery started | The awarded supplier mobilised; fixed-scope milestones, no timesheets | | 14 Aug | Drift detected | `reconciliation.detected`: PO amount 144,000 to 148,200, edited in Coupa | | 15 Aug | Change order re-approved | `intent.version_bumped`: the business owner approved the change, and the intent moves to version 3 | | 2 Oct | Invoices matched | EUR 148,200 settled against `CPO-104233` | | 2 Oct | Closed | Timeline sealed: decision to reconciliation, one key | The milestones are the programme's narrative; only the two entries shown in code are timeline event types, and [Events](/concepts/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 How the Intent ID is minted, versioned and written into each destination's own field. Plan, preflight, publish, and the idempotency key behind every step. The timeline, webhooks in and out, and how drift is detected.