AI generatedThe recent platform posts introduced the Crowd Platform, the Data Platform, and the AI Platform one by one. Each one is a real product with a landing page, an operator surface in the platform-v2 sidebar, and its own pricing. But the more interesting story is what happens when a buyer uses all three together, because they were designed to chain into a single workflow rather than to be picked from a menu.
The Crowd Platform is where the labels come from. You run a job — a survey, a moderation task, a quality evaluation — against a panel of workers, and the accepted answers become a labelled dataset. The Data Platform is the durable substrate those labels live in. The accepted answers are stitched back into a new dataset version, with an audit trail that links each answer to the worker, the input item, the review decision, and the timestamp. The AI Platform is where the dataset becomes a model. You pick one of the six open-source base models, point at the dataset version, run a LoRA finetune, and the result is a model entry in your registry that you can query from your own code.
The three platforms are not a stack diagram. They are three surfaces of the same workflow, and the underlying primitives — the panel, the versioned dataset, the model registry — are the same across all three. The marketing pages describe them as separate products because buyers buy them separately and enable them separately as modules. The implementation makes them one pipeline.
Picture a newsroom team that wants to fact-check a stream of social posts. They start with the Crowd Platform: a SurveyJS template that asks workers to classify each post as authentic, manipulated, or inconclusive, with a structured set of supporting evidence fields. The job runs against the panel, answers are accepted or rejected, and the accepted answers are stitched back into a Crowd Platform dataset.
The team then moves to the Data Platform. The crowd-job output is a labelled dataset; the team registers it as a new versioned dataset on the Data Platform, runs a deduplication pass to remove posts that were answered by multiple workers, and runs a language-tech pipeline to extract named entities from each post (the people, the places, the organisations mentioned). The result is a curated dataset version: posts, classifications, evidence, and entities, all linked.
The team then moves to the AI Platform. They pick qwen3.5-2b as the base model — small enough to host on premises, Apache 2.0 licensed, 256k context window — and run a LoRA finetune against the curated dataset version. The finetune adapter is registered in the model registry. The team benchmarks the adapter by submitting its outputs through the same crowd-rating flow used for any AI system, and the aggregated score tells them whether the model is good enough to ship.
Every step in that workflow references the previous step's version. The dataset version the AI Platform pulls from is the same version the Data Platform curated. The crowd-job accepted answers are the same answers the Crowd Platform produced. The audit trail from "this model answered that question" back to "this is the worker who classified that post" is one join.
The audit trail is the property that makes the three platforms one workflow rather than three integrations. The same primitive — a versioned reference with a hash and a parent-version link — sits behind every step. The Crowd Platform job's accepted-answers version is the parent of the Data Platform dataset version. The Data Platform dataset version is the parent of the AI Platform finetune run. The finetune run is the parent of the model registry entry.
The consequence is that any audit question on the resulting model can be answered by walking the version graph backwards. "Why did the model classify this post as misleading?" → "the finetune was trained against dataset version X" → "X was curated from crowd job Y's accepted answers" → "Y was answered by worker Z, who agreed with workers W and V, on date D." The same audit trail that gives a newsroom the answer to a regulator's question is the same audit trail that gives a trust-and-safety team the answer to a content appeal.
This is why the three platforms are shaped the way they are. The Crowd Platform is not a worker pool bolted onto a job engine; the Data Platform is not a generic file store with versioning; the AI Platform is not a finetuning service that takes a CSV. Each one is a node in a versioned graph, and the graph is what makes the whole thing auditable end-to-end.
The three-platform workflow is the right answer for buyers who need a model they own and a dataset they can defend. Newsroom teams that need to defend a content moderation decision to a regulator. Trust-and-safety teams that need to defend a take-down to the user who appealed. Compliance teams that need to defend a model outcome to an auditor. AI/ML teams that need a reproducible model for a downstream pipeline they own.
Typical buyers start with one platform — most often the Crowd Platform, because the labelling problem is the most common first step — and add the other two as the use case expands. The default-on module configuration for new tenants means the sidebar always shows the four modules, and the operator can start with the one that matches their current pain point and add the others when the workflow demands them.
To see the three platforms in action on a real tenant, book a demo call — we'll walk through your data from worker labels to a model you can host yourself. To read the individual platform posts, see the Crowd Platform, Data Platform, and AI Platform overviews.
