Generation node

The Generation node turns raw items into labeled data. It is one of the node types a pipeline can contain. Labeled items are checked against the quality criteria you define, and the node returns the labels together with the verdicts. The review path under Quality control determines which items are checked and by whom. The agent sets each option as it builds the node, and every option can also be edited by hand on the node’s cards until deploy. You alone set the review model, under Quality Assurance (see the shared quality model), and onboarding’s on/off switch, on the node’s Onboarding card. A single run feeds the node at most 10,000 items — a platform-wide per-run cap; Label a large dataset in batches covers larger workloads.

Expert labelers produce labels by default. On request, an LLM produces them instead (synthetic labeling). Who does the labeling covers that choice. Input and output fields, instructions and the labeling interface, quality criteria, and quality control apply either way. The expert labeling settings at the end apply only when experts do the labeling.

Who does the labeling

Expert labelers produce the labels by default. On request, an LLM produces them instead. See Label with an LLM instead of experts.

Setting	Values	Default	Notes
Labeler	Expert labelers or an LLM (synthetic labeling)	Expert labelers	Synthetic labeling is unavailable for data-collection nodes
Generation model	GPT-5.6 Terra, GPT-5.6 Luna, Claude Sonnet 5, Gemini 3.1 Pro Preview, Gemini 3.5 Flash	GPT-5.6 Terra	Synthetic labeling only. A node pinned to a retired model keeps it, disabled and badged Unavailable
Reasoning effort	Low, Medium, High	Medium	The GPT models only; rejected on the Gemini and Claude models. In the editor the effort carries over to any model that supports it, and clears on one that does not; asking the agent for an effort a model cannot take is refused
Extra model guidance	Free text	Empty	Sent to the model on top of the task instructions

Under synthetic labeling, the audience, pricing, per-expert cap, onboarding, and audience reuse below do not apply, and the Onboarding card disappears from the node. Switching to synthetic forces the review path to LLM review. Asking the agent to switch also clears audience reuse; flipping the card yourself only hides the picker, so a reuse setting left behind blocks the deploy with Sharing workforce with a previous version is not available for synthetic data generation. Switching back differs by surface too: the card restores the audience, pricing, per-expert cap, and review path you had, while an agent switch leaves them to be set again. Onboarding settings survive either way.

Expert labeling is billed per item as the expert payout (see Pricing). Synthetic labeling has three token charges — input, cached input, and output — at the chosen model’s per-million-token rates. The model and effort choice fix the token estimate per item. An output’s repetition count does not increase it. Higher reasoning effort raises the estimated tokens per item and the resulting token charge. Lower effort lowers both.

Input and output fields

The node reads the input fields you declare and returns one output field for each label the labeler produces. Each follows the shared field model for whether it is required or optional and whether it repeats. Quality control adds the per-criterion verdict fields and a review metadata field, shaped as the shared quality model describes. The agent defines the fields from your task.

Under synthetic labeling the node adds one more output field, named <node name>_evaluation_summary. It holds the item’s overall review verdict, which is always pass or fail — a narrower set than a per-criterion verdict, whose other values appear only in the counts — plus the number of generation attempts and a count of the per-criterion verdicts from the final attempt. An item that every attempt failed to get past LLM review still finishes, and this field is what marks it, so nothing is lost and you can tell the two outcomes apart. To send those items down a branch of their own, give a Match node this field and test the location $.overall_verdict against fail.

Deployment enforces the field contract:

• At least one input field and at least one output field.
• Every field carries a description and one of the platform’s data types.
• A repeating field’s maximum count is a whole number from 1 to 50, and its location marks the repeating position exactly once. A field that does not repeat must not mark one.
• When the node has more than one field, every output field links to at least one other field, and links may point only to the node’s own fields.
• A video output states a minimum and a maximum duration, with the minimum not above the maximum. The maximum also sets the rate of the video-review charge (see Quality control).
• A choice output offers at least two options. Option names are non-empty, and both the names and the stored keys (lowercase words joined by underscores) are unique.

Instructions and the labeling interface

The labeler follows a written instruction document and works in a custom labeling interface where fields are shown and controls are filled in. A short display name appears alongside the task (the node’s Display name card). The agent builds both the instructions and the interface. Under synthetic labeling the same instructions guide the model, and you can add model-only guidance on top (see Who does the labeling).

Deployment rejects empty instructions and sets no instruction-specific length limit. The only ceiling is the 150,000-character cap on any single node setting. The 8,000-character bound the agent works to is its own guideline. The display name is required and at most 128 characters. Deployment rejects a missing or longer name. None of these carry a direct cost.

Quality criteria

Every output field on this node must be covered by at least one quality criterion. Each criterion can also carry an optional instruction of up to 5,000 characters, handed only to the LLM reviewer and never shown to experts. What a criterion is and the floor it must clear to deploy are covered in the shared quality model. The setting under Quality control determines which reviewer applies the criteria. When LLM review is on, each criterion adds one review check per item, or more when the checked field builds on repeating fields. Human review is priced per review, and an item can be reviewed more than once. Criteria do not affect that price.

Quality control

The shared quality model describes how labeled items are reviewed against the criteria. This section covers the settings and prices specific to this node. You set the review path, human-review sample, and review time by asking the agent or by hand under Quality Assurance.

Setting	Values	Default	Notes
Review path	LLM review, human review, or both	LLM review	Forced to LLM review under synthetic labeling
Review model	GPT-5.4, GPT-5.4 Mini, Claude Sonnet 4.6	GPT-5.4	LLM path only, picked in the node’s Quality Assurance settings. A node configured earlier may keep GPT-5 or GPT-5 Mini, selectable only where already chosen
Human-review sample	10% to 100% of items	100% (human review only), 30% (both)	LLM review always covers every item
Review time per item	At least 10 seconds	—	Required whenever human review is on. The node will not deploy without it

A criterion’s verdict field is required when the criterion targets a required output and optional when it targets an optional output.

Each charge is priced on its own basis, and for each the estimate assumes a per-item count. A human-reviewed item can be reviewed more than once when it is sent back for rework, which is why its expected and maximum counts differ:

Charge	Priced per	Expected	Maximum
LLM review	Per check. A more capable review model costs more per check	One check per item per criterion, times the repetition maxima of repeating fields in the checked field’s chain	Same as expected
Human review	Per review, from the expert payout scaled by the review time relative to the labeling time, plus a 10% premium	2 reviews per sampled item (human review only), or 1.2 with both paths on	3 reviews per item
Video tool	Per reviewed item when LLM review covers a video output, shown as Video tool in the cost breakdown. Its rate grows with the video’s maximum duration	One charge per reviewed item. A repeating output raises the rate per charge while the number of charges stays the same	Same as expected

Expert labeling settings

These settings apply only when expert labelers do the labeling. Under synthetic labeling they do not apply (see Who does the labeling).

Audience

The audience filters which experts are eligible to label by language, specialization, and country. Each filter lists several values.

General projects label data you already have and require ID-verified experts. Data-collection projects, where experts produce new content, may instead use the wider unverified pool. A data-collection node must also include a media-upload control (recording or uploading video, or uploading a file) in its interface, or deployment is rejected. Specializations are unavailable with the unverified pool.

The audience carries no price of its own. The per-item cost is the expert payout under Pricing. Pool size feeds the estimate of how many experts will be onboarded (see Onboarding).

Pricing

Pricing sets what each labeling task pays and how long it is expected to take.

Setting	Values	Default	Notes
Price per task	US dollars, greater than zero	1.00	The agent starts from 0.20 and adjusts to the task
Time per task	Seconds, at least 10	1,800	The agent starts from 120
Per-expert cap	1 to 50 tasks	Off	Value ignored while the cap is off

Deployment checks only the ranges above: a price greater than zero and a time of at least 10 seconds. The agent enforces a further floor when it writes the price: a minimum hourly rate of 4 US dollars for ID-verified experts and 3 for the unverified pool.

The per-task price you set is the expert’s payout, billed once per labeled item. Your charge adds the platform commission on top. The cost breakdown shows the base payout plus 33% commission.

Finding experts at deploy

When a node with a human audience deploys, the platform runs Smart Search: it matches your requirements against the expert pool and proactively invites the top candidates, who still take the node’s onboarding. The deployment screen reports its progress and how many experts it invited. With no requirements of your own, the platform builds them from the node’s name, description, instruction, and audience filters. The requirements themselves are set by the agent, not on a card, and they go stale — a deploy warning — if the node’s description or instruction changes afterwards. Nodes that reuse an audience, and synthetic nodes, skip Smart Search.

Onboarding

Onboarding is an optional one-time training course that is on by default. Experts complete it before they take paid items. The agent writes the course on the node’s Onboarding card, and you can edit it there by hand. Only you turn the course on or off. The course consists of steps containing pages of content blocks: text to read, a quiz, a practice exercise, a consent block, or worked examples drawn from labeled data.

Deployment enforces the course contract when onboarding is on:

• 3 to 6 steps, each holding at least one block.
• A stated role, goal, and success criteria for the expert.
• At least one quiz. A quiz needs its question text, at least two named options, and a correct answer marked among them.
• Exactly one hands-on part: either a practice exercise or a worked-examples block. Worked examples require the task interface to be built first.
• No block left empty: text needs content, a consent block needs its consent text, a practice exercise needs a task description and grading criteria, and each worked example needs at least one filled-in check.

Onboarding does not apply under synthetic labeling, though the settings are kept (see Who does the labeling). When you reuse an audience (see Audience reuse), experts who already passed the earlier course skip it.

Onboarding is billed once per expert who joins the task. The charge derives from the course length relative to the per-task time and price, computed as on the Quorum node, which owns the formula. The expected expert count grows with the item count and shrinks as each expert can take on more tasks. A tighter per-expert cap raises it because more experts are needed to cover the same items.

Audience reuse

A node can reuse the expert audience of a Generation or Quorum node in a previously deployed pipeline. This audience includes the labeling and human-review experts. Reuse is off by default. Two methods choose the source node, one of them agent-only:

Method	Eligible source nodes
Curated picker — in the Audience & Pricing card or through the agent	Candidates from other pipelines of the same project, deployed within the last 61 days, counting each node’s latest deployment
Direct entry — agent only	Any deployed source node your team owns, including one in another project, without the picker’s age, same-project, or other-pipeline bounds

The source must have a recorded deployment and belong to your team. Otherwise, the setting is rejected. If the source deployment ran with onboarding, the reusing node must keep onboarding on or deployment is rejected. Labeling experts are always reused. Human reviewers are reused only when the source is a Generation node whose deployment used human review. Otherwise, the node recruits its own reviewers. Experts who passed the source node’s onboarding get access without repeating it. Reuse is cleared when you switch to synthetic labeling and is unavailable in synthetic mode.

Reuse carries no charge of its own. It can lower onboarding cost because already-trained experts skip the course.

Related

• Overview of pipeline nodes — the other node kinds and how they compare
• Quality control — the shared review model these verdicts and review paths build on
• Fields and data — the field model behind required, optional, and repeating fields