Someone in your business needs work done. Before anything useful can happen, three separate jobs have to be carried out: someone has to decide how the work should be done, that decision has to reach the right systems, and those systems have to carry out the work. Most workforce tooling muddles at least two of those jobs together. Keeping them separate is the point of this product.
Triage decides
Someone needs work done. Triage asks the questions needed to understand the requirement: what the work is, how long it lasts, what constraints apply. From the answers it determines the appropriate route. The same request might turn out to be a contractor, a permanent hire, a fixed-scope statement of work or an outsourced team, and the right answer is rarely obvious from the first sentence of the request.
Triage owns that job completely. Nothing downstream second-guesses it.
Composer publishes
Once Triage has made that decision, composerID publishes its decision reference into the configured systems that need to know about it. The decision reference is a short code that identifies the decision, so that a record in one system can always be traced back to the decision that produced it.
Composer does not make the decision again. It does not re-open the questions, re-score the options or keep its own competing copy of the workflow. It takes the decision as made and carries its reference downstream.
Your systems execute
Your vendor management system, HR system, applicant tracking system, ERP, procurement platform or contract system continues doing what it was bought to do. The requisition, the purchase order, the position and the contract all live where they always lived, run by the systems your teams already know.
Composer does not try to replace those systems. It gives them a common reference, so they are all describing the same decision.
What goes wrong when the jobs merge
The recurring failure patterns in workforce technology mostly come from one system trying to do two of these jobs.
The VMS as the front door. A vendor management system is very good at running contingent labour. It is a poor place to decide whether a request should be contingent labour at all. When the intake form lives inside the VMS, every request becomes a requisition by default, and the statement-of-work and permanent-hire routes get discovered after the fact.
The intake tool as the system of record. The opposite mistake. An intake layer starts storing the “real” record because the downstream system is slow to integrate, and within a year there are two sources of truth and a reconciliation job between them.
Keeping the publishing job narrow avoids both. Composer holds no competing record, and it asks no system to change how it works.
The whole idea in four sentences
Triage decides. Composer publishes. Your systems execute. One decision reference connects the three.
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.