The human-data market used to be easy to describe.
Scale was the annotation vendor. Surge was the preference-data vendor. Mercor was the specialist-recruiting network. Handshake was the talent marketplace. Each vendor had a lane, and each lane had a separate owner inside the AI lab.
That map is no longer accurate.
The work can overlap because a post-training team may need the reviewer, calibration state, rubric, disagreement record, adjudication, and later evaluation context alongside the produced data.
That is not four categories. It is one operating system.
What changed
The market changed in three places at once.
First, some difficult tasks require domain judgment while other tasks remain appropriate for trained generalists. The correct workforce mix depends on the task, risk, rubric, and source material.
Second, the output increasingly includes evidence around the data. Who reviewed it? Which rubric applied? Was a disagreement resolved? Can the customer reconstruct the handoff later? Mercor's June 25, 2026 update confirms a LiteLLM-linked supply-chain attack and narrows the company-confirmed affected population compared with earlier media allegations. Any broader stolen-data or customer-response claim requires explicit attribution.
Third, the buyer moved from a narrow data-ops manager to a cross-functional release owner. Human data now touches safety, compliance, product, research, and finance. The vendor that wins cannot just deliver rows. It has to preserve the operating record.
Provider relationships and product scopes changed materially during 2025 and 2026. Those changes do not prove a universal buyer response or a permanent vendor map. Buyers should inspect current product documentation, proposals, security terms, data rights, and handoff obligations.
Why point solutions break here
A sourcing marketplace starts with people. It can tell you who might be available. That is useful, but availability is not calibration.
An annotation vendor starts with tasks. It can move units of work through a queue. That is useful, but task throughput is not release governance.
A benchmark vendor starts with tests. It can rank models. That is useful, but a leaderboard is not an audit trail for the work that produced the next model.
A lab needs all three surfaces tied together. The reviewer profile must connect to the work item. The work item must connect to the evaluation. The evaluation must connect to the launch check. The launch check must connect to a regression bank that remembers what failed before.
If those records live in four systems, the lab is not buying specialization. It is buying seams.
The new buying question
The question for a frontier lab is not which vendor can find experts, annotate data, or run an eval in isolation.
The better question is this: which system preserves the full record from specialist sourcing to model release?
That question changes the vendor comparison. It makes the old category labels less important and the data model more important. A lab may tolerate a vendor that is weaker on one feature if the system keeps the required record intact. Reconstructing release evidence across disconnected systems creates avoidable audit and operating work, especially as EU AI Act obligations phase in under category-specific timelines.
AuraOne Human Data supports scoped candidate discovery, structured interview evidence, workforce records, annotation, review, and delivery. Models supports criteria, selected regression records, and operator-controlled release evidence. Qualification, assignment, model execution, and release remain dependent on configured workflows and human decisions.
The modules are not the product. The record is the product.
What to do this quarter
Do not start by replacing every vendor.
Start by mapping the record. Pick one high-value workflow and trace it from role brief to sourced specialist, from specialist to reviewed task, from reviewed task to model update, from model update to release approval. Count how many systems hold part of the truth. Count how many exports, scripts, spreadsheets, and Slack threads are required to answer the question: why did this model ship?
Then run one workflow through one record.
Define pilot outcomes before starting. Relevant measures may include record completeness, reviewer calibration visibility, export quality, reconciliation effort, and whether selected failures can become reusable cases. Do not assume a fixed cycle-time or quality improvement.
The durable buying question is whether the provider can produce the work and preserve the record the customer actually needs.