When a risk or security team reviews a new piece of software, the first question is usually the simplest one: what data does it send, and to whom?
For composerID the answer is short, because its current role is deliberately narrow. Triage may know a great deal about a workforce decision:
- why the request was classified the way it was,
- the answers that led to the decision,
- the alternatives that were considered,
- and the decision itself.
composerID does not need to copy all of that reasoning everywhere. Today its central job is to publish the decision reference, the short code that identifies the decision, into the configured destinations.
Share the reference, not the whole decision
A downstream system does not need the reasoning behind a decision to do its own work. The vendor management system needs a valid request; it does not need to know that a permanent hire was considered first, or how close the scoring was. That reasoning belongs to your organisation, behind your own access controls, in the system where the decision was made.
Anyone entitled to the reasoning can follow the reference back to it. That is the pattern in one sentence: share the reference, not the whole decision.
Why less is stronger
Every field that crosses a boundary between systems is a field somebody has to account for: in a security review, in a data-protection agreement, in an incident. An integration that moves less is easier to trust, easier to review and easier to switch off. Publishing a reference is close to the minimum an integration can move while still being useful, and that is a feature, not a limitation.
It also keeps one customer’s systems out of each other’s business. Two records in two different platforms can share a decision reference without either platform learning anything else about what the other holds.
Written down, per destination
As we research each destination platform, its page in our documentation records what a published record would contain, built from the vendor’s own published specification, so the claim can be checked rather than taken on faith. Those pages describe researched designs; each one states how far it has progressed, and none of them claims a live customer integration where one does not exist.
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.