---
id: operating.first-correctness-loop
title: First correctness loop
summary: Complete one traceable path from project context and benchmark coverage to expert judgment, evaluation evidence, and improvement.
kind: task
product_area: operating_manual
status: stable
updated: 2026-09-07
canonical: /docs/operating-manual/first-correctness-loop
---

# First correctness loop

Complete one narrow loop that another operator can reconstruct. Choose one specialist behavior slice and preserve the path from project knowledge through coverage, expert contribution, governed standards, benchmark evidence, and any candidate change.

## Decision checkpoint

| State | Next action | Do not continue when... |
| --- | --- | --- |
| Project intent or sources are implicit | Complete Agent Setup | Agents cannot find the controlling context |
| Case shape varies | Configure Project Input Schema | Existing and planned cases do not share a valid contract |
| Important behavior is unnamed | Define Coverage Facets and benchmark guidance | The selected cases are merely convenient examples |
| Correctness remains tacit | Request a focused Expert Contribution | The expert lacks cases or source evidence |
| Cases and standards are ready | Snapshot the dataset and run an evaluation | Candidate, benchmark, mapping, or settings are ambiguous |
| Candidate weakness is confirmed | Start an Improvement Session | The target cannot be measured from pinned evidence |

## Prerequisites

- One project, one benchmark, and one narrow specialist behavior.
- An accountable operator and domain expert.
- Representative examples or enough Reference Materials to construct them.
- A candidate that can be saved as a Harness version.

## Before and after

| Before | Work | After |
| --- | --- | --- |
| Knowledge is distributed across people and sources | Project Context and Indexed Reference | Agents have inspectable project understanding |
| Benchmark examples lack deliberate structure | Coverage Facets, Coverage Management, and dataset selection | The behavior slice and snapshot are explicit |
| Judgment is tacit | Expert Contribution and Correctness Governance | Policies and rubrics preserve authority and applicability |
| Candidate quality is anecdotal | Benchmark Evaluation | Responses and rubric results bind to exact versions |
| Improvement is an informal edit | Improvement Session | Goal, candidate, receipt, and frontier remain connected |

## Steps

1. Write a concise Project Agent Brief and connect the controlling Reference Materials.
2. Configure Project Input Schema for the input architecture and required case materials.
3. Define the relevant Dimensions, Project Topics, and Case Construction Pattern.
4. Add or construct a small case set, inspect its representation, and record any known gap.
5. Request an Expert Contribution with selected cases and a concrete correctness objective.
6. Reconcile the resulting policy, rubric, case, or coverage observation in its owning surface.
7. Select the benchmark dataset cases and create or choose the intended snapshot.
8. Save the candidate Harness version and run a Benchmark Evaluation.
9. Inspect failures at case and rubric level; compare only after confirming evidence boundaries.
10. Start an Improvement Session if candidate work is justified, or return upstream to the specific coverage, correctness, or case artifact that needs change.

## Object and state changes

The loop can create or update project context, Reference Materials items and indexed blocks, Project Input Schema, Coverage Facets, Cases, benchmark coverage guidance, Contributions, contributed artifacts, policies, rubrics, dataset selection and snapshots, Harness versions, Runs, evaluation results, and Improvement Sessions. Each transition retains its own authority and scope.

## Success criteria

- The selected behavior slice has a named coverage reason.
- Expert judgment is attributable and materialized only through an explicit lifecycle.
- Case content follows the Project Input Schema.
- Evaluation evidence identifies exact candidate and benchmark versions.
- The next action names one responsible artifact or candidate boundary.

## Common failure modes

- Beginning with a broad benchmark and vague expert request.
- Treating Reference Materials as governed standards.
- Adding generated cases without a named coverage gap.
- Running an editable Harness Draft.
- Starting improvement from an aggregate result without pinned measurement evidence.

{% example-demo title="Example: one exception slice" %}
The first loop targets exception requests with conflicting sources. The project indexes both sources, defines the source-authority facet, asks an expert to establish the controlling rule, creates the corresponding rubric, snapshots ten reviewed cases, evaluates one saved Harness version, and starts improvement from the three exact grounding failures.
{% /example-demo %}

## Related reference pages

{% related-card-grid title="Related reference pages" %}
- [Agent Setup](/docs/agent-setup)
- [Benchmark Datasets](/docs/benchmark-datasets)
- [Expert Contributions](/docs/expert-contributions)
- [Benchmark Evaluations](/docs/benchmark-evaluations)
- [Improve](/docs/improve)
{% /related-card-grid %}

## Related troubleshooting pages

{% related-card-grid title="Related troubleshooting pages" %}
- [Unclear cases](/docs/troubleshooting/unclear-cases)
- [Low expert agreement](/docs/troubleshooting/low-expert-agreement)
- [Benchmark results changed unexpectedly](/docs/troubleshooting/benchmark-results-changed-unexpectedly)
{% /related-card-grid %}

## Source confidence

Doctrine-backed: this workflow applies the current five-capability model and links to code-backed pages for every exact product operation.