Skip to main content
First check whether labelling is available and which teachers are offered:
Use available, defaults.teacher_models and limits to plan the job. A catalogue of teacher names does not mean the service is enabled.

​
1. Upload unlabelled queries

Save UTF-8 JSONL, one context per line. You may put decisions on each row, or provide shared decisions when starting the job.
Keep the returned source id. A source can hold up to 2,000 rows and 16 MiB. The input receipt records the uploaded bytes and hash. Teacher labelling sends selected queries to the configured teacher model provider; choose data appropriate for that workflow.

​
2. Start a job

Set D1_SOURCE_ID to that returned ID. Select teacher IDs from the catalogue; this example uses its current default.
Poll /v1/labeling/jobs/{job_id}. Jobs progress through queued and running to review_ready, or end failed or cancelled. Cancellation may pass through cancelling. Review readiness means labels are available, not that they are correct.

​
3. Review and finalize

Read /v1/labeling/jobs/{job_id}/results page by page. Each result has its source index, context, decisions, teacher labels, valid and agreement. Valid means the teachers returned labels in the expected shape. Agreement means they chose the same labels. Neither substitutes for your review. For valid rows, targets averages the teachers’ one-hot votes. Inspect disagreements and systematic mistakes against your labelling rules. Invalid rows cannot be finalized. Set D1_LABEL_JOB_ID to your job’s ID. After reviewing and accepting rows 0 and 1:
Use the original row indices, not page positions. At least two selected rows and two distinct contexts are required for a dataset. Finalization returns that dataset and changes the job to finalized. A different later selection conflicts; create another job when the reviewed selection must change. The resulting dataset keeps teacher and source lineage. Inspect it as you would any dataset before tuning or training.