Ask where a piece of work “goes” in an enterprise and the honest answer is: it depends what kind of work it is.
- A contractor goes to the vendor management system (the VMS), which runs contingent labour: the requisition, the supplier response, the worker.
- A permanent hire goes to the applicant tracking system (the ATS), which runs the candidate pipeline, and to the HR system, which holds the position.
- A statement of work goes to the procurement platform and the contract system, because it is a purchased outcome with an agreement behind it.
- The financial commitment behind any of these lands in the ERP, the enterprise resource planning system that holds the money.
- A service request often lives in a service-management platform, where it started life as a ticket.
Same business, same manager, same budget. Completely different destinations, depending on one early decision about what the work actually is.
The consequence
Before you integrate anything, you have to know what kind of work you are dealing with. A publishing layer that only speaks to the VMS handles one branch of the tree, and the branch is chosen before any system is touched.
That is why Triage makes the decision first and composerID publishes it afterwards. The decision determines the destination. Getting that order right is the whole design.
Why the words shape the product
If a product describes itself as a VMS integration, three things quietly follow. Its data model becomes a requisition, so statements of work and permanent positions get squeezed into requisition-shaped fields. Its vocabulary becomes one vendor’s, so every other platform is described by how it differs. And its buyer becomes the contingent workforce programme, so the procurement and talent acquisition teams, who own half the destinations, are never in the room.
Our own copy rule follows from that: general pages say “destination system”, never “the VMS”. VMS language belongs on VMS pages.
Partners, not competitors
One distinction worth keeping. Intake-to-procure platforms such as Zip and ORO Labs do guided buying: steering catalogue purchases to preferred suppliers and routing approvals. That is a different job from deciding what kind of workforce request something is, and we treat those platforms as complementary partners rather than competitors. Triage decides what the work is; an intake platform can route the resulting purchase; the systems of record execute.
One reference across the whole landscape
Because the landscape is plural, the useful thing to standardise is not the front door and not the system of record. It is the reference. One decision reference, created when the decision is made, published into whichever systems that decision turns out to need, so the requisition, the contract, the order and the position all answer to the same name. The landscape stays plural. The thread through it does not.
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.