# What is correctness infrastructure? Generated: 2026-09-13T04:39:06.844Z Source build: local Canonical docs: https://teammately.ai/docs --- id: intro.correctness-infrastructure title: What is correctness infrastructure? summary: Learn how five connected capabilities turn specialist judgment into cases, executable standards, evaluation evidence, and improvement. kind: concept product_area: introduction status: stable updated: 2026-08-22 canonical: /docs/introduction/correctness-infrastructure --- # What is correctness infrastructure? Correctness infrastructure is the operating layer that lets a team specify, test, and improve the behavior of specialist AI. It connects the behavior space that matters, the expert judgment that defines acceptable behavior, the cases that challenge a system, the evidence produced by repeatable evaluation, and the engineering work that follows. {% visual-hero src="/docs-assets/assets/correctness-infrastructure-workbench.png" alt="Workbench connecting coverage design, expert judgment, cases, evaluation evidence, and improvement." %} The visual is a category anchor. The selectable capability names and current product mappings below are authoritative. {% /visual-hero %} ## Definition Teammately expresses correctness infrastructure through five capabilities: 1. **Coverage Engineering** designs what the benchmark must represent. 2. **Correctness Elicitation** captures policies, exceptions, applicability, and expert rubrics. 3. **Weave** constructs cases, variants, multimodal materials, and supported worlds from the coverage design. 4. **Trialground** runs harnesses and weights against benchmark cases and records rubric evidence. 5. **Coevolve** explores stronger candidate branches and missing correctness or coverage. The sequence is connected rather than strictly linear. An evaluation failure may expose a missing rubric. An expert contribution may reveal a new coverage facet. An Improvement Session may find that the benchmark needs a harder case before a harness change can be trusted. ## Decision checkpoint | Question | Inspect first | Expected durable result | | --- | --- | --- | | Does the benchmark represent the important behavior space? | Coverage Engineering | Dimensions, Project Topics, Case Construction Patterns, and benchmark coverage state | | What should count as correct for this situation? | Correctness Elicitation | Governed policies, applicability, and binary rubrics | | Do we have cases that exercise the difficult combinations? | Weave | Reviewable cases, variants, materials, and dataset membership candidates | | How did this candidate behave against the benchmark? | Trialground | Runs, responses, Rubric results, comparisons, and rankings | | What change is justified by the evidence? | Coevolve | A bounded Improvement Session with candidates and evaluation receipts | > Keep the category centered > > Evaluation execution is one capability inside correctness infrastructure. The category also includes the expert-derived specification, deliberate coverage, case construction, and evidence-backed improvement that make evaluation meaningful. ## From expert effort to reusable infrastructure Expert time is most valuable when it resolves ambiguity that agents and engineers cannot settle from existing evidence. Teammately therefore prepares a structured contribution: the relevant cases, reference materials, candidate interpretations, possible policies, rubric questions, and unresolved conflicts. Once an expert responds, the contribution can affect more than the immediate task. It can refine the coverage map, materialize a policy or rubric, qualify a case, or identify the next evaluation. This creates a higher return on expert effort. The product does not ask specialists to repeatedly label disconnected outputs; it preserves why a judgment was made and where that judgment applies. ## Product realization The project foundation holds reusable context and assets. Correctness Governance owns policies and rubrics. Coverage Facets owns Dimensions, Project Topics, and Case Construction Patterns. Assets owns cases, harnesses, and other project-level resources, including reusable Comparison Directions and Review Screens. Agent Setup gives agents reusable project understanding through Project Context and Reference Materials. Expert Contributions configure scoped agent behavior and select the presentation and variation assets needed for the work. A benchmark workspace then creates a scoped operational loop. Benchmark Datasets defines the case set and snapshots. Coverage Management exposes represented and missing behavior. Expert Contributions requests governed human work. Benchmark Evaluations produces versioned evidence. Improve starts from that evidence and coordinates candidate exploration. {% layer-map title="Five capabilities of correctness infrastructure" %} {% /layer-map %} {% example-demo title="Policy exception handling" %} A support assistant must answer exception requests. Coverage Engineering identifies exception type, customer state, and source freshness as important facets. Correctness Elicitation records the expert rule for when an exception can be stated or must be escalated. Weave prepares ordinary, conflicting-source, and boundary cases. Trialground shows that a candidate handles ordinary cases but invents approval on ambiguous ones. Coevolve tests a harness change and keeps the resulting candidate tied to the exact failed cases and rubric evidence. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [The correctness lifecycle](/docs/introduction/correctness-lifecycle) - [The correctness loop](/docs/product-loop) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Product map](/docs/getting-oriented/product-map) - [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships) - [Object model](/docs/object-model) {% /related-card-grid %} ## Source confidence Doctrine-backed: this page defines the current public category and capability model. Product-surface pages provide code-backed operational detail. --- id: intro.what-is-teammately title: What is Teammately? summary: Understand Teammately as correctness infrastructure for building trustworthy specialist AI with expert judgment and AI agents. kind: concept product_area: introduction status: stable updated: 2026-08-22 canonical: /docs/introduction/what-is-teammately --- # What is Teammately? Teammately is correctness infrastructure for teams building specialist AI. It turns in-house experts' judgment into an operating system for designing benchmark coverage, making correctness explicit, constructing challenging cases, evaluating candidate behavior, and deciding what to improve next. AI agents prepare and connect the work so scarce expert attention is spent on consequential judgment rather than manual organization. > Category boundary > > Teammately centers the definition and development of trustworthy AI behavior. Logs, traces, model endpoints, coding environments, and external data can enter the workflow, but the product's durable value is the connected correctness system built from expert judgment, cases, standards, evaluation evidence, and improvement history. ## Definition The system has five connected capabilities. [Coverage Engineering](/docs/coverage-engineering) defines the behavior space a benchmark must represent. [Correctness Elicitation](/docs/concepts/correctness-elicitation) turns tacit preferences, exceptions, and disagreements into policies, applicability conditions, and binary rubrics. [Weave](/docs/concepts/weave) constructs cases, response variants, case materials, and—where supported—worlds from that structure. [Trialground](/docs/concepts/trialground) evaluates Harnesses and weights against benchmark Cases and preserves responses and Rubric results. [Coevolve](/docs/concepts/coevolve) explores candidate improvements and keeps every retained direction tied to current benchmark evidence. These capability names explain how the system works. Procedures use the labels visible in the product, such as Correctness Governance, Agent Setup, Benchmark Datasets, Coverage Management, Expert Contributions, Benchmark Evaluations, and Improve. ## Decision checkpoint | If the team needs... | Capability | Product surfaces to open | | --- | --- | --- | | A deliberate map of important behavior | Coverage Engineering | Coverage Facets and Coverage Management | | Reusable standards grounded in specialist judgment | Correctness Elicitation | Correctness Governance and Expert Contributions | | Challenging cases and supporting materials | Weave | Assets, Benchmark Datasets, Case Construction Patterns, and Case Foundry | | Repeatable evidence about candidate behavior | Trialground | Harnesses and Benchmark Evaluations | | Evidence-backed candidate improvement | Coevolve | Improve and Improvement Sessions | ## Why teams use it A benchmark score cannot define correctness on its own. Specialist systems depend on domain rules, exceptions, source authority, interaction patterns, and consequences that generic criteria do not capture. Teammately gives experts and AI engineers a shared artifact graph: an expert contribution can inform a policy, a policy can produce a rubric, a coverage gap can motivate a case, a case can expose a harness weakness, and an evaluation can become the starting evidence for an Improvement Session. This reuse is the practical meaning of scaling expert judgment. Teammately prepares coverage structure, candidate cases, possible standards, and unresolved questions before asking an expert. The expert's response remains attributable and can be materialized into governed artifacts instead of disappearing into meeting notes. ## Product scope Project-level foundations hold reusable knowledge and assets: Correctness Governance, Coverage Facets, Assets, Agent Setup, and Project Settings. Benchmark workspaces bind those foundations to a concrete evaluation program through Benchmark Datasets, Coverage Management, Expert Contributions, Benchmark Evaluations, and Improve. Teammately preserves correctness evidence and makes the next engineering question inspectable. Customer teams remain responsible for downstream product, governance, deployment, and operational choices. > Human ownership > > AI agents can prepare, draft, classify, generate, evaluate, and propose. A suggestion is not a governed policy, accepted expert contribution, benchmark membership decision, or retained candidate merely because an agent produced it. Use the state shown by the owning product surface. {% example-demo title="Grounded enterprise search" %} Coverage Engineering identifies conflicting-current-source questions as an important behavior slice. Correctness Elicitation records the expert rule that material claims must cite the controlling source or state uncertainty. Weave creates cases with current and superseded documents. Trialground evaluates a retrieval harness and exposes unsupported blends of the two sources. Coevolve starts from those failures, tests a source-selection change, and retains only candidates supported by evaluation evidence. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Product quickstart](/docs/quickstart) - [The correctness loop](/docs/product-loop) - [First correctness loop](/docs/operating-manual/first-correctness-loop) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Product map](/docs/getting-oriented/product-map) - [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships) - [Product boundaries](/docs/introduction/product-boundaries) {% /related-card-grid %} ## Source confidence Doctrine-backed: this page follows the current public top-page story and the approved product-to-UI mapping. Linked code-backed pages define exact routes, states, and controls. --- id: intro.correctness-lifecycle title: The Teammately correctness lifecycle summary: Follow specialist AI work from project foundations through coverage, elicitation, construction, evaluation, and improvement. kind: concept product_area: introduction status: stable updated: 2026-08-22 canonical: /docs/introduction/correctness-lifecycle --- # The Teammately correctness lifecycle The correctness lifecycle describes how a team turns domain knowledge into an improving specialist AI system. It begins with reusable project foundations, narrows into a benchmark workspace, and cycles through coverage, expert contribution, evaluation, and improvement without losing the evidence that explains each change. ## Definition The lifecycle has three scopes: 1. **Project foundation.** Define Project Context and Reference Materials, configure the Project Input Schema, govern policies and rubrics, establish Coverage Facets, and manage reusable Assets. Reusable Review Screens and Comparison Directions are authored under Assets; Contribution-specific agent behavior and asset selection happen in benchmark work. 2. **Benchmark work.** Select a benchmark dataset and snapshot, manage coverage, request expert contributions, and bind the work to a benchmark version. 3. **Evaluation and improvement.** Evaluate saved harness versions, inspect cases and rubric results, compare candidates, and start an Improvement Session from pinned evidence. The public five-capability model runs through these scopes. Coverage Engineering shapes representation. Correctness Elicitation captures judgment. Weave constructs the challenge set. Trialground produces evaluation evidence. Coevolve turns that evidence into bounded candidate work. ## Decision checkpoint | Current condition | Next lifecycle action | Boundary to preserve | | --- | --- | --- | | Agents lack the project purpose or controlling knowledge | Complete Agent Setup | Project Context and Reference Materials remain distinct from governed policies | | Case shape is ambiguous | Configure Project Input Schema | `content.input` and case materials follow one declared architecture | | Coverage exists but correctness is tacit | Request an Expert Contribution | Human responses remain attributable before materialization | | Cases and standards are ready | Create or select a benchmark snapshot and evaluate a saved Harness version | The run stays bound to exact versions and settings | | Evaluation evidence exposes a candidate weakness | Start an Improvement Session | The Goal Contract and starting evidence remain pinned | | Candidate exploration exposes a benchmark gap | Return to coverage, standards, or cases | Do not interpret missing evidence as candidate failure | ## Why ordering matters Running evaluations before the benchmark has deliberate coverage can produce precise but misleading results. Writing rubrics without expert-grounded policies can turn vague preferences into brittle checks. Generating cases without a Project Input Schema can create records that reviewers or harnesses interpret differently. Starting improvement from an aggregate score can hide the cases and standards that actually justify a change. The lifecycle prevents those shortcuts by giving each artifact an owner and scope. Project foundations are reusable across benchmarks. Benchmark datasets and versions define the evidence boundary. Contributions provide human authority. Runs and comparisons expose candidate behavior. Improvement Sessions retain the chronology between a goal, a proposed change, and its evaluation receipt. ## How learning returns to the system The lifecycle closes when new evidence changes an upstream artifact. A failed run may show that a policy is too broad, a rubric is ambiguous, a case lacks required material, or a coverage tuple is absent. An expert can contribute a new policy, rubric, case, or coverage observation. An Improvement Session can test a harness candidate while also reporting missing correctness or coverage. Each return path should name the responsible artifact. Simultaneously changing cases, standards, harness code, and evaluation settings makes the next result difficult to explain. {% example-demo title="Specialist procurement assistant" %} The team configures structured procurement inputs and indexes its buying rules. Coverage Engineering maps product category, contract state, and exception type. An expert contribution resolves when an exception requires escalation and materializes the policy and rubric. Weave prepares cases with conflicting contract material. Trialground evaluates a saved harness version and exposes failures on expired agreements. Coevolve tests a source-date validation change while retaining the original benchmark evidence. {% /example-demo %} ## Where the lifecycle stops Teammately makes correctness work inspectable and reusable. It does not determine the customer's downstream deployment, operational, or governance action. The product supplies governed artifacts, benchmark evidence, and improvement history so the accountable team can make that decision with a clear record. ## Related workflows {% related-card-grid title="Related workflows" %} - [First correctness loop](/docs/operating-manual/first-correctness-loop) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Project Input Schema](/docs/project-settings/input-schema) - [Expert Contributions](/docs/expert-contributions) - [Improvement Sessions](/docs/improve) {% /related-card-grid %} ## Source confidence Doctrine-backed: this lifecycle joins the current public capability model to code-backed product scopes. Linked pages define individual object and state behavior. --- id: product-loop title: The Teammately correctness loop summary: See how coverage, elicitation, case construction, evaluation, and improvement reinforce one another. kind: concept product_area: introduction status: stable updated: 2026-08-22 canonical: /docs/product-loop --- # The Teammately correctness loop The correctness loop is how a team repeatedly turns domain knowledge into stronger AI behavior. It follows the five public capabilities while preserving a trace from every result back to the project context, expert contribution, case, policy, rubric, benchmark version, Harness version, and evaluation setting that made the result meaningful. ## Definition 1. **Design coverage.** Establish Dimensions, Project Topics, and Case Construction Patterns, then decide which combinations the benchmark must represent. 2. **Elicit correctness.** Use focused expert contributions to resolve policies, exceptions, applicability, disagreements, and binary rubric language. 3. **Construct the challenge set.** Create or import canonical cases, attach required materials, generate difficult variants, and curate benchmark dataset membership. 4. **Evaluate behavior.** Run an exact saved Harness Version against an exact Benchmark Version and inspect responses, Case-level Rubric evidence, comparisons, and rankings. 5. **Improve from evidence.** Start an Improvement Session with a bounded Goal Contract, explore candidates, evaluate them through the canonical path, and retain a current frontier. 6. **Return new learning.** Update coverage, correctness, cases, or the candidate according to what the evidence actually showed. ## Decision checkpoint | Evidence says... | Responsible part of the loop | Change first | | --- | --- | --- | | Important behavior has no cases | Coverage Engineering or Weave | Coverage facet, construction pattern, or case set | | Experts cannot apply the standard consistently | Correctness Elicitation | Policy scope, applicability, or rubric wording | | A case cannot be interpreted or executed reliably | Weave and Project Input Schema | Input shape, case material, or world boundary | | One saved candidate fails applicable rubrics | Trialground | Harness candidate or its runtime configuration | | Several candidate branches improve different slices | Coevolve | Goal constraints, next experiment, or retained frontier | | Result movement cannot be explained | Benchmark version and evaluation boundary | Versions, settings, mapping, or run metadata before any product change | ## How expert effort compounds The loop should ask an expert only after agents have prepared the relevant structure and evidence. A Contribution can include selected Cases, source attachments, scoped statements, draft Policies, Rubric questions, or coverage uncertainty. Completed expert work can materialize as an attributable contributed Policy, Rubric, Case, or coverage observation through the owning workflow. That same judgment can guide future case construction, determine which rubrics apply during evaluation, and identify missing correctness during improvement. Reuse across the loop is more valuable than maximizing the number of disconnected review actions. ## How product scope changes through the loop Project foundations are reusable. Project Context, Reference Materials, policies, rubrics, Coverage Facets, Cases, and Harnesses do not belong to only one benchmark. A benchmark workspace selects and versions the relevant subset, manages coverage, coordinates contributions, evaluates candidates, and records improvement. This scope distinction prevents accidental drift. Editing a project-level policy may affect several benchmarks. Changing dataset membership should create a new benchmark evidence boundary. Saving a Harness draft is different from selecting an exact saved Harness version for a Run. ## Before and after | Before | Loop work | After | | --- | --- | --- | | Domain knowledge is distributed across people and files | Agent Setup and Correctness Elicitation organize it | Project context and governed correctness artifacts are inspectable | | Examples are convenient rather than deliberate | Coverage Engineering and Weave shape the challenge set | Dataset representation and missing coverage are explicit | | Candidate behavior is discussed from anecdotes | Trialground runs a versioned evaluation | Case-level rubric evidence and comparisons are available | | Improvement is a sequence of untracked edits | Coevolve starts from pinned evidence | Candidate branches, receipts, chronology, and current frontier remain connected | {% example-demo title="Changing a retrieval harness" %} An evaluation shows failures only when current and superseded documents appear together. The team first confirms that the coverage slice and grounding rubric are valid. An Improvement Session pins those cases and the failing Harness version, then tests source-date filtering and citation-selection candidates. A stronger candidate becomes part of the current frontier only after a canonical evaluation produces the expected rubric evidence. If the work uncovers an unseen source-conflict pattern, that observation returns to Coverage Management. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Product quickstart](/docs/quickstart) - [Run a benchmark evaluation](/docs/benchmark-evaluations/run-evaluation) - [Start an Improvement Session](/docs/improve/start-improvement-session) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Product map](/docs/getting-oriented/product-map) - [Project Input Schema](/docs/project-settings/input-schema) - [Expert Contributions](/docs/expert-contributions) {% /related-card-grid %} ## Source confidence Doctrine-backed: this page explains the approved operating loop. Linked product pages are the authority for exact controls and lifecycle states.