Design note. What exists today: Triage makes the decision and composerID publishes its decision reference into configured downstream systems. What this article describes: a capability or engineering principle we are considering as composerID develops. It is not a claim that this functionality is currently available in production.
Publishing something into another system is one problem. Knowing what happened afterwards is another. A requisition gets approved, amended, filled or cancelled, and the system that published it has no automatic way of knowing.
composerID does not currently need to solve that second problem to publish a decision reference. But it becomes important if composer grows into a broader integration layer, so this design note records what we have learned about it.
Three ways systems report change
Some systems send updates: when a record changes, they call you. Some need to be checked: you ask on a schedule and compare what you find with what you knew. And some require customer configuration before they will say anything at all: the machinery exists, but each customer has to switch it on and point it somewhere.
Engineers have names for these. A webhook is the system calling you when something changes. Polling is checking on a schedule. An event framework is a platform’s configurable machinery for emitting notifications.
What our platform research found
The posture is a property of each platform, documented by its vendor, not a choice an integration layer gets to make:
| Posture | How a subscriber learns of change | Examples from vendor documentation |
|---|---|---|
| Push | The platform sends signed webhooks. | Beeline, Ironclad, DocuSign |
| Poll | The record is read back and compared. | Fieldglass, Workday report services |
| Event framework | The customer configures the platform’s own event mechanism. | Workday Business Process Framework, SAP event services |
| None native | Outbound notification is customer-built, so polling is the reliable path. | ServiceNow business rules |
Any future reconciliation feature has to work with what each platform actually offers, and be honest with the customer about what “noticed the change” means on each one: instantly for a webhook, at the next check for polling.
Principles for whatever we build
Three rules we would hold any future design to. Pushed events should be verified as genuine before they are trusted, because anyone can send a message to a public address. Change should be measured against what was actually published, not against what the record ought to look like today, so that a pending edit on our side is never mistaken for someone else’s change. And whatever the source, the result should normalise into one history, so a reader never needs to know which platform pushed and which was polled.
None of that is current composerID functionality. It is the map we would build from.
Written with Claude. This post was drafted with Claude, Anthropic’s AI model, working from the composerID repository: the registry, the schemas, the reference sandbox and the vendor documentation it cites. Edited and published by the composerID team.