> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Quality presets and what they prove description: >- Standard, Verified, High assurance and Custom evaluation each check something different. Read what each preset actually tests, what it leaves untested, and how to choose one for your work. route: /docs/compute/workflows/quality-presets page_id: docs-compute-workflows-quality-presets page_type: concept content_layer: guided documentation surface_profile: guided_docs audience: Compute customers deciding how much checking their work needs voice: D reader_question: Which quality preset should I choose, and what does it actually prove? primary_action: Choose a preset and quote the run source_locale: en-US source_status: APPROVED source_version: docs-compute-workflows-quality-presets-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What a preset is Your request carries a `quality` object with one `preset`. It decides how much checking runs beside the work, and what evidence lands in your result. A preset does not change the work itself. It changes what you can say about the work afterwards. There are four. ## Standard Standard runs schema and deterministic validation. It confirms that output matches the declared schema, that deterministic rules hold, and that every item carries its identifier and a status. It cannot tell you an answer is right. A well-formed wrong answer passes Standard cleanly, because nothing in Standard reads the answer for meaning. Use it where structure is the risk and correctness is obvious on sight. ## Verified Verified adds independent sample verification. A sample of items is checked again, independently, and the comparison is recorded in `verification.json`. Where the checks differ, the difference is preserved under `disagreements/` rather than resolved silently. You see the disagreement, not a tidied summary. It cannot tell you anything about items outside the sample. Sample evidence describes the run's tendency, never each individual row. ## High assurance High assurance raises the verification rate, or raises the number of independent checks each item receives. That narrows the gap Verified leaves. It does not close it. Independent checks can still be wrong in the same direction, and more checking makes that less likely rather than impossible. Use it where you will act on the output without a person reading it first. ## Custom evaluation Custom evaluation applies your own rubric or reference set. Hard gates reject items outright, scored dimensions score them, and evidence rules say what a check must cite. It proves exactly what your rubric asks and nothing else. An uncalibrated rubric produces confident scores with no meaning behind them, so calibrate before you rely on it. ## No preset makes a workflow correct Every preset is a measurement, and every measurement has a boundary. None of them is a correctness promise, and none of them removes your judgment from the loop. Abstentions and disagreements are normal outcomes, not defects. An item with insufficient evidence abstains, and that abstention is more useful than a confident guess would have been. Read `verification.json` alongside your accepted rows. It tells you what was actually checked on this run. ## Choosing one Start at Standard when the failure you fear is structural. Move to Verified when a wrong answer costs more than the extra checking does. Choose High assurance when the output feeds a decision nobody will review. Choose Custom evaluation when you already have your own definition of good and can write it down. Your quote states the maximum charge for the preset you chose, and approval stays a separate act. When you need your own criteria, start with [building a rubric](/docs/compute/workflows/rubrics).