Trodo

How a row's Expected becomes ground truth: typed by a person, accepted from a passing output, or proposed by your own model and confirmed. Every label records where it came from and how much to trust it.

A row's Expected is its label: what the system should have produced. Rows curated from production start without one, because what the system said is not proof that it was right. The Label column shows each row's status, and the dataset header counts them.

Status	Meaning
Unlabelled	No Expected yet.
Proposed	Your model drafted an Expected. It waits beside the row; the row's Expected is unchanged until someone confirms it.
Confirmed	Expected is set and someone (or a passing evaluation) vouched for it.

Where labels come from

Every label records its source and a weight, so a fine-tune or an eval can choose how much to trust it.

How	Source	Status	Weight
A person types or edits Expected	explicit	confirmed	1.0
A person confirms a proposal	derived	confirmed	0.6
Your model proposes one	derived	proposed	0.4
A passing output is accepted as Expected	implicit	confirmed	0.2
Expected is cleared	none	unlabelled	—

Editing a proposal before confirming it makes the label explicit. Rejecting a proposal puts the row back to what it was. Save to dataset from an experiment writes a derived label: confirmed when that cell passed, proposed when it did not.

Label rows

Open a row and use the Expected field, or tick rows in the grid and use the bulk actions:

Accept output: the row's Output becomes its Expected. Only for rows whose evaluations all passed and that nobody marked wrong.
Confirm: accept the proposed Expected.
Reject: drop the proposal.
Propose: ask your model to draft an Expected for each selected row.

Bulk actions take up to 200 rows at a time and list any row they skipped, with the reason. After Propose, the header shows Proposing n/N… until the job finishes; the drafts then appear in the Label column.

Proposals

Propose sends each row's Input, Output and Evaluations (every verdict, its reasoning, the reason a person marked it wrong, and any step labels) to a model with the dataset's instruction, and gets back a draft Expected, its reasoning and a confidence. The row's drawer shows the draft next to the Output so you can confirm, edit or reject it.

Set this up in Labelling settings on the dataset:

Instruction: what a good answer looks like for this dataset. This is what the model is graded against, so write it as you would brief a new labeller.
Model: which of your project's model keys and models to use. Defaults to the first chat key of the project.
Propose Expected on every new failed row: draft a proposal as soon as a failed unit lands in the dataset.

Proposals run on your own model key, never on Trodo credits, so the provider bills you for the tokens. Each row drafted is also one Execution from your plan's pool, checked before the job starts: if the rows do not fit, nothing is drafted. A row that already has a confirmed label is not re-proposed.

Label with an experiment

An experiment is the other way to fill Expected in bulk, and the one to use when a stronger prompt or model can answer what the production system got wrong.

Run an experiment on the dataset with the prompt and model you trust, and attach the evaluators that decide what a good answer is.
Open the run and choose Save outputs to dataset, then Expected output. Pick which rows (all, passed, failed, improved, regressed) and whether to fill empty Expected only or overwrite.
Each saved row gets a derived label: confirmed (weight 0.6) where the cell passed its required scorers, proposed (0.4) where it did not, waiting for you to confirm or reject.

Every experiment runs against a pinned snapshot of the dataset, taken automatically when you run on the live rows, so the labels you save always trace back to the exact rows and versions that produced them.

Grading a verdict

Two kinds of feedback live on an eval's Results page, and they mean different things:

A thumbs on the verdict grades the eval. Up: the eval was right. Down: it was wrong, and you say what it should have been and why.
A label on a step says where. Under each step of the path, Label… offers Right or Should have been, typed to that step's own output: Pass or Fail for a yes/no judge, one of its options for a router, a slider over the declared range for a score, free text for a step with no declared output. The options always come from the eval version that graded that result.

Neither writes the span's Expected. What the eval should have said is not what the agent should have said. On a span row, both appear under Evaluations; on a verdict row, the correction is the Expected.

Marking a verdict wrong

A thumbs-down opens a review of every step on the path. Each step needs an answer, Right or Should have been, then the verdict (Pass or Fail) and why. Save waits for all of it. The answers decide where the fix goes:

You said	Stored as	What happens
At least one step should have been different	`fix_kind: step`, plus a step label per step	The step labels travel with dataset rows and into training; Lucid opens with the corrected steps and proposes a change to those steps.
Every step was right	`fix_kind: eval`	The eval is missing a check. Lucid opens with that framing and looks for what the eval never examined.

A step marked Right is stored too (agree), so a passing verdict whose steps someone confirmed reads differently from one nobody looked at.

Many at once

Tick results and use Mark N wrong for the verdict, or Label a step… for one step across all of them: pick the step, then the answer. For a yes/no step, The other way flips each result's own answer; for a choice or a score, one value applies to all. Results that did not run that step, or whose version declared different options, are skipped and listed.

A row whose verdict passed but has a corrected step is not accepted as Expected by Accept output: the pass is disputed.

Export: send the confirmed rows to training
Curate from production: fill a dataset
Experiments: run a prompt across the labelled set

Labels