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.

Who labeled and reviewed the item

With human experts, the node also returns a field named after the node with _annotator_id at the end, for example translate_text_annotator_id. It holds the ID of the expert whose answer was accepted. When an answer is sent back and another expert redoes the item, the field names the expert of the accepted answer, not the earlier ones.

When human review is on, the node returns one more field, ending in _qa_annotator_id. It holds the ID of the expert who made the last human review decision on the item.

• Both fields are optional. They are missing on an item that was canceled at this node before an answer was accepted, on items that finished before the fields existed, and, for the review field, on items that human review did not sample. An item accepted without review, on a run cancel or at the 14-day node timeout, ends as canceled and has its expert field. The field is in the dataset, and when the End node returns it, the run export and the API show it in partialOutput.
• Synthetic labeling returns neither field, because no expert labels or reviews the item.
• The fields are written to your dataset next to the answers. To use them inside the pipeline, add them as inputs of the next Code node. To get them in the run export, add them to the outputs of the End node. Both cards add them as optional.

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 64 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	Whole seconds, at least 30 and at least 3 per quality criterion, up to 359,999 (99:59:59)	—	Required whenever human review is on. The node will not deploy without it. A reviewer who takes a review task keeps it for the review time plus 1 hour, and for at least 8 hours. A task that a reviewer takes and drops stays with that reviewer until this time ends

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 item whose LLM review watches a video field, shown as Video tool in the cost breakdown. Its rate grows with the total maximum duration of the videos watched	One charge per item. A repeating field raises the rate per charge while the number of charges stays the same	Same as expected

Human review stops at a cap that is set when the run deploys: 3 reviews for each item of the run, the Maximum of the human review charge in the run’s cost estimate. The cap counts every item of the run, not only the items the estimate expects at this node. A branch behind a Match node that receives more than its even share of items still gets human review.

Before deploy, the node counts its review pool: the experts who match the audience and either hold the platform’s review qualification and were active in the last 14 days, or have recent review experience. Recent review experience means at least one completed review task and a recent visit to the platform. Smart Search invites these experts when the run deploys. A node that reuses an earlier audience without its human reviewers counts only the qualification holders, because Smart Search does not invite experts to it. The platform rebuilds this data once a day. With an empty pool, deployment is rejected. When the pool is too small for the node’s expected review count, deployment shows a warning that you can accept. The platform assumes that one in ten experts of the pool reviews, for up to 12 hours of review time each. The warning names the pool size and the size needed. When at least ten experts match, it also names the reviews they can cover. It suggests widening the audience or switching to LLM review. A node with human review only also gets the option of both paths. To deploy anyway, confirm the unresolved warnings at the deploy gate. A node that reuses the human reviewers of an earlier deployment (see Audience reuse) skips this count.

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. The audience card shows how many experts match the saved filters. When you ask the agent about the pool, it can count the same saved filters, so its number matches the card.

Any project type may use ID-verified experts or the wider unverified pool. A data-collection node, where experts produce new content, must 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.

With the unverified pool and an exam, the node limits how many experts can join it. The limit is set when the run deploys, from three inputs: the tasks the run’s cost estimate expects at this node (not the run’s total), the per-expert cap, and the measured share of experts who pass the exam. It is at least 100 and at most 10,000 experts. Behind a Match node, the estimate spreads items evenly across the branches, so each branch gets a limit for its share. With ID-verified experts, or without an exam, the limit stays at the default of 10,000.

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, inside the audience’s range below	6.00	The agent starts from 0.40 and adjusts to the task
Time per task	Whole seconds, from 10 to 359,999 (99:59:59)	1,800	The agent starts from 120
Per-expert cap	1 to 50 tasks	Off	Value ignored while the cap is off

The audience sets the allowed price range per hour of work. It becomes a range per task as the hourly rate times the time per task, divided by 3,600 and rounded to the cent:

Audience	Price per hour of work	Suggested
ID-verified, no specialization	$12 to $90	$21
ID-verified, with a specialization	From $12; the top follows that specialization’s rates	Set by the specialization
Wider unverified pool	$3 to $24	$6

A 30-minute task for ID-verified experts without a specialization accepts $6.00 to $45.00. The audience must also match at least one expert, and its languages, specializations, and countries must exist in the audience catalog. The editor shows a problem under its field, saving through the API rejects it, and an agent’s write is saved with the problem reported back. The node will not deploy until it is fixed.

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