# Enterprise Playbooks Generated: 2026-09-13T04:34:30.536Z Source build: local Canonical docs: https://teammately.ai/docs --- id: playbooks.overview title: Enterprise Playbooks summary: Apply Teammately’s correctness lifecycle to common AI product operating scenarios. kind: concept product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks --- # Enterprise Playbooks Playbooks are scenario recipes for applying Teammately's correctness lifecycle to product-specific AI risks. They do not introduce separate product surfaces; they connect existing artifacts such as Cases, Expert Contributions, Policies, Rubrics, coverage, Benchmark Evaluations, and improvement evidence. ## Definition Enterprise Playbooks names the scenario layer of the docs. Use it when a team knows the kind of AI system or operating problem it has, but needs a concrete path through Teammately's existing correctness artifacts. ## Why it matters Enterprise AI teams often begin with examples, external logs, reviewer comments, or model outputs before they have explicit correctness standards. Playbooks route that material into current Teammately surfaces and state the decision gates that must be satisfied before evidence is trusted. ## Choose a playbook | Starting problem | Playbook | | --- | --- | | Retrieved sources, citation, abstention, or answer grounding | [RAG correctness benchmark](/docs/playbooks/building-correctness-benchmark-rag) | | Search intent, source authority, document conflicts, or freshness | [Enterprise search](/docs/playbooks/enterprise-search) | | Refunds, commitments, account context, or escalation | [Customer support AI](/docs/playbooks/customer-support-ai) | | Many rules, exceptions, or controlled source hierarchies | [Policy-heavy AI systems](/docs/playbooks/policy-heavy-ai-systems) | | A bounded question requires accountable specialist judgment | [Run Expert Contributions](/docs/playbooks/running-expert-contributions-enterprise-assistant) | | Contribution evidence needs to become reusable standards | [Turn judgment into Policies and Rubrics](/docs/playbooks/turning-expert-judgment-into-policies-and-rubrics) | | Qualified experts disagree | [Handle conflicting opinions](/docs/playbooks/handling-conflicting-expert-opinions) | | Important behavior may be absent from the selected Dataset | [Find coverage gaps](/docs/playbooks/finding-coverage-gaps-before-review) | | New evidence or a changed rule makes the current boundary stale | [Refresh a Benchmark](/docs/playbooks/refreshing-a-benchmark-from-new-signals) | | CI or another evaluation system already owns execution facts | [Use existing evaluation infrastructure](/docs/playbooks/using-teammately-alongside-existing-evaluation-infrastructure) | ## Where it appears in the product Look for playbooks in this section of the docs. Product screens use operational labels for Cases, Expert Contributions, Policies, Rubrics, coverage, Benchmark Evaluations, and Improve; playbooks organize those existing surfaces around common scenarios. ## Artifacts it affects Depending on the scenario, a playbook can affect imported Cases, supported reference responses, Contribution records, Policies, applicability, Rubrics, Coverage Facets, Dataset Snapshots, Benchmark Versions, Evaluation Runs, comparisons, Improvement Sessions, or customer-owned human review context. {% example-demo title="Choosing a scenario path" %} A support team with refund-policy failures should start with the customer support or policy-heavy system playbook. A search team with stale-source issues should start with the RAG or enterprise search playbook. A team that already has CI metrics should start with the existing-evaluation-infrastructure playbook. The common thread is the same: turn human judgment and source context into explicit standards, cover the risky behavior slices, and use Benchmark Evaluations to produce benchmark interpretation grounded in real results. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Agent Setup](/docs/agent-setup) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Agent instructions](/docs/agent-instructions) - [Case versions](/docs/governance/case-versioning) - [Represent conversations in Cases](/docs/object-model/represent-conversations-in-cases) - [Reference and golden outputs](/docs/object-model/reference-and-golden-outputs) - [Input-only and output-attached cases](/docs/assets/cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product doctrine defines the common correctness lifecycle and current capability boundaries. Each playbook links to code-backed operational pages for exact UI labels, object states, and evaluation limits. --- id: playbooks.rag-benchmark title: Building a Correctness Benchmark for a RAG System summary: Represent retrieval-grounded behavior through cases, context, policies, rubrics, and benchmark evidence. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/building-correctness-benchmark-rag --- # Building a Correctness Benchmark for a RAG System Use this playbook when correctness depends on retrieved context, source authority, and whether the answer should cite, abstain, or explain uncertainty. ## Entry conditions Use this when you can preserve the query, retrieved material, candidate response, and source identity for representative RAG behavior. If you have only aggregate retrieval metrics, first collect Case-level evidence; Teammately cannot infer source authority from a score. ## Route through Teammately 1. In **Agent Setup**, make the Project Agent Brief describe the retrieval architecture and connect the Reference Materials needed to interpret sources. 2. Configure Project Input Schema fields for the query, retrieved passages, source identifiers, and freshness or authority metadata actually available to the Harness. 3. Import representative Cases under **Assets → Cases**. Keep missing-source and conflicting-source Cases instead of filtering them out as bad data. 4. In **Coverage Facets**, model the slices that change grounding behavior: authority, freshness, answerability, retrieval completeness, and question type. 5. Request an **Expert Contribution** for Cases where the controlling source, required caveat, or abstention boundary is unclear. 6. Materialize and approve the resulting Policies and binary Rubrics in **Correctness Governance**. 7. Use **Coverage Management** to expose missing combinations, review new Cases, and select the intended set in **Benchmark Datasets**. 8. Run saved Harness Versions in **Benchmark Evaluations**. Read response and Rubric evidence; execution traces are not currently exposed. ## Decision gates - If the correct source was never retrieved, route the finding to retrieval or coverage work. - If the source was present but the response blended, ignored, or contradicted it, route the finding to Harness behavior. - If specialists disagree about which source controls, resolve correctness before expanding the Dataset. - If an important source condition has too few Cases, hold aggregate interpretation until representation improves. {% example-demo title="Benefits policy retrieval" %} An employee asks whether caregiver leave applies to contractors. The Case contains an obsolete handbook page and the current controlling policy, which does not state contractor eligibility. Experts approve a Policy requiring the controlling source and a Rubric that passes only when the answer cites it and withholds the unsupported eligibility claim. Results show one Harness succeeds when both passages are retrieved but still fails when the current policy is absent, separating answer behavior from retrieval coverage. {% /example-demo %} ## Evidence to collect - Canonical Case input containing the query and material actually available at execution. - Source identifiers, authority, and freshness facts that reviewers can verify. - Approved grounding, citation, contradiction, and abstention standards. - Dataset representation across answerable, conflicting, stale, missing, and multi-source conditions. - Saved Harness Version, Benchmark Version, execution settings, Run Metadata, response, and Rubric outcomes. ## Related docs {% related-card-grid title="Related docs" %} - [Configure Coverage Management](/docs/coverage-management/get-started) - [Represent conversations in Cases](/docs/object-model/represent-conversations-in-cases) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved five-capability model establishes the RAG correctness loop. Linked code-backed pages define the current Agent Setup, Case, Coverage Management, Expert Contribution, Dataset, and Evaluation surfaces and their capability fences. --- id: playbooks.customer-support-ai title: Using Teammately for Customer Support AI summary: Govern assistant behavior where correctness depends on policy, escalation, tone, and account context. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/customer-support-ai --- # Using Teammately for Customer Support AI Use this playbook when support behavior must respect customer policy, escalation rules, account context, and tone without reducing correctness to satisfaction scores. ## Start with one support decision Choose one decision family—refund eligibility, service credit, account change, plan entitlement, or escalation. Do not begin with “support quality” as a single standard; the required context and accountable owner differ across those decisions. ## Build the support boundary 1. Configure the **Project Input Schema** for the account, channel, transcript, entitlement facts, and source material the assistant actually receives. 2. Import ordinary and failed interactions under **Assets → Cases**, preserving prior turns when they affect the answer. 3. Define Coverage Facets for intent, customer state, available account evidence, policy exception, escalation need, and interaction mode. 4. Request Contributions from the support or operations owners who can decide allowed commitments and escalation boundaries. 5. Approve separate Policies and Rubrics for eligibility, commitments, escalation, and communication requirements; do not combine them into one “helpful response” check. 6. In Coverage Management, add boundary Cases for missing account context, frustrated customers, conflicting sources, and exception requests. 7. Evaluate saved Harness Versions and inspect the applicable Rubric failures by Case and coverage slice. ## Hold or proceed - Hold when the Case omits account facts that the real assistant would receive. - Route an unclear exception to an Expert Contribution instead of encoding a guessed rule. - Treat an unsupported promise as a correctness failure even if tone is acceptable. - Proceed to candidate improvement only after the governing Policy and Dataset boundary are stable. {% example-demo title="Refund exception handling" %} A customer requests a refund outside the standard window after a service outage. The Case contains the outage fact but not the account evidence required to approve an exception. Support owners establish that the assistant may explain the standard rule and escalate, but may not promise approval. Evaluation shows the candidate passes routine refunds and fails only when an outage is mentioned, giving the Harness owner a specific commitment boundary to fix. {% /example-demo %} ## Evidence to collect - Conversation-shaped Case input and the account or policy material actually available. - Attributable Contribution decisions about commitments, escalation, exceptions, and required language. - Separately governed Policies and Rubrics for each decision boundary. - Dataset representation across routine, ambiguous, exception, missing-context, and high-impact Cases. - Case-level response and Rubric evidence tied to exact Harness and Benchmark Versions. ## Related docs {% related-card-grid title="Related docs" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Review prepared Cases](/docs/coverage-management/case-review) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Agent Setup](/docs/agent-setup) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model establishes the flow from support evidence to expert-owned standards, designed coverage, and versioned evaluation. Linked pages define the active Case, Contribution, governance, and Benchmark surfaces. --- id: playbooks.enterprise-search title: Using Teammately for Enterprise Search summary: Build correctness standards for search and answer systems that must handle context, intent, and authority. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/enterprise-search --- # Using Teammately for Enterprise Search Use this playbook when an enterprise search or answer system must respect intent, source authority, document freshness, and uncertainty. ## Define the search contract Use this when search results or generated answers look plausible but specialists disagree about intent, controlling source, freshness, or when the system should return partial evidence instead of a confident answer. Teammately does not ingest private search traces automatically; represent the evidence you need as Cases and materials. ## Route source authority into evidence 1. Choose a bounded search domain and identify who owns source authority in that domain. 2. Configure input fields for the query, result set, document identity, owning team, effective date, and any access context visible to the assistant. 3. Import Cases for navigational search, direct answers, ambiguous intent, conflicting documents, superseded documents, and no-result behavior. 4. Ask specialists to resolve which source controls, what partial answer is allowed, and when uncertainty or escalation is required. 5. Approve source-selection and answer-behavior Policies and Rubrics separately. 6. Inspect Dataset Representation by department, source family, intent, conflict type, and freshness before creating the Snapshot. 7. Compare saved Harness Versions by the relevant Coverage Facets and open failed Cases to distinguish ranking, selection, and answer failures. ## Failure ownership - Wrong or missing document in the supplied result set: search/retrieval boundary. - Controlling document present but ignored: Harness answer behavior. - Source authority genuinely unresolved: Expert Contribution and governance. - Segment absent from the Dataset: Coverage Management and Case preparation. {% example-demo title="Conflicting HR search results" %} An employee searches for remote-work reimbursement rules and receives an obsolete FAQ plus a newer policy page. HR establishes that the policy page controls and that unlisted reimbursement categories must remain unresolved. One Harness ranks the correct page first but still blends the obsolete exception into its answer. Because the Case preserves both documents and the governing Rubric, the failure belongs to answer synthesis rather than search ranking. {% /example-demo %} ## Evidence to collect - Canonical queries, result sets, source identity, ownership, and effective dates. - Attributable specialist decisions for conflicts, ambiguity, partial answers, and no-result behavior. - Separate governed standards for source selection and answer behavior. - Representation evidence by domain, intent, source family, freshness, and conflict pattern. - Exact Harness and Benchmark Version identities plus Case-level Rubric outcomes. ## Related docs {% related-card-grid title="Related docs" %} - [Inspect Dataset representation](/docs/benchmark-datasets/representation) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Agent Setup](/docs/agent-setup) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model grounds source authority in expert judgment, Coverage Facets, Cases, governed standards, and Benchmark evidence. Linked pages define the current operating surfaces and evaluation limits. --- id: playbooks.coverage-gaps-before-review title: Finding Coverage Gaps Before Review summary: Use coverage dimensions, failures, and expert signals to decide where evidence is incomplete. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/finding-coverage-gaps-before-review --- # Finding Coverage Gaps Before Review Use this playbook when benchmark evidence looks plausible overall but the team needs to know whether important behavior slices are missing or underrepresented. ## Review-readiness trigger Use this before a customer relies on Benchmark evidence for human review, especially when results are dominated by common Cases, a critical Rubric has few applicable Cases, or specialists identify behavior that the Dataset does not represent. ## Coverage audit 1. Confirm the exact Benchmark Version and Run completeness before interpreting its distribution. 2. Open **Benchmark Datasets → Representation** and inspect the selected Dataset across the configured Coverage Facets. 3. Compare thin or empty slices with Coverage Stories, failed Cases, specialist observations, and must-level Rubrics with few applicable Cases. 4. Classify each issue: missing vocabulary, missing Case, unreviewed candidate, missing Dataset membership, or unclear correctness standard. 5. Route vocabulary changes to Coverage Facets, unclear standards to Expert Contributions, and missing Cases to Assets Synthesis or Case Foundry. 6. Review candidates in **Case Review**, select the intended Cases in **Benchmark Datasets**, and create a new Snapshot. 7. Run the relevant saved Harness Versions against the new Benchmark Version and state any still-unrepresented risk in the customer's review context. ## Evidence threshold Coverage is ready when critical slices are named, their selected Case counts are visible, candidate-only Cases are not counted as evidence, and remaining gaps are explicit. A balanced-looking aggregate count is not sufficient. {% example-demo title="Compatibility gaps" %} Dataset Representation shows many ordinary recommendations but only two accessory-compatibility Cases and no discontinued-model Cases. A Coverage Story records the gap. Case Foundry prepares cross-brand adapter, ambiguous model-number, and discontinued-model candidates; specialists review the source conditions in Case Review. Only the admitted Cases enter the new Snapshot, and the customer withholds compatibility conclusions until the rerun is complete. {% /example-demo %} ## Evidence to collect - Benchmark Version, Snapshot, selected Case count, and Dataset Representation. - Coverage Stories and specialist observations that identify consequential gaps. - Candidate lineage, Case Review decisions, and final Dataset membership. - New Snapshot and Benchmark Version after membership changes. - Rerun completeness and an explicit list of remaining unsupported conclusions. ## Related docs {% related-card-grid title="Related docs" %} - [Inspect Dataset representation](/docs/benchmark-datasets/representation) - [Work with Coverage Stories](/docs/coverage-management/coverage-stories) - [Review prepared Cases](/docs/coverage-management/case-review) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model requires deliberate coverage before Benchmark evidence is trusted. Linked code-backed pages define current Representation, Coverage Story, Case Review, Snapshot, and Run boundaries. --- id: playbooks.conflicting-expert-opinions title: Handling Conflicting Expert Opinions summary: Turn expert disagreement into sharper standards instead of unresolved review noise. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/handling-conflicting-expert-opinions --- # Handling Conflicting Expert Opinions Use this playbook when experts disagree and the disagreement needs to become an explicit standard, not a hidden source of benchmark noise. ## Classify the disagreement Use this when two or more qualified experts reach different judgments about the same Case, response, source hierarchy, Policy boundary, applicability condition, or Rubric. Do not average the answers before identifying the object in dispute. ## Resolution path 1. Preserve each answer, rationale, and source context within its Contribution provenance. 2. Determine whether the disagreement concerns a factual source, Case completeness, Policy rule, applicability boundary, Rubric wording, or a legitimate product tradeoff. 3. Reconstruct the strongest version of each position and test whether a missing context field or time boundary resolves it. 4. If both positions are valid in different situations, split the applicability or coverage boundary instead of forcing consensus. 5. Have the accountable owner approve the revised governed object in Correctness Governance. Contribution completion or a Checkpoint alone does not approve it. 6. Add boundary Cases that distinguish the resolved situations, review them, and create a new Benchmark Version when the evaluation boundary changes. 7. Run new evaluations without rewriting the earlier expert responses or Runs. ## Escalation outcomes - Missing evidence: leave the question unresolved and request the controlling source. - Different valid contexts: split applicability and add boundary Cases. - Incorrect Case context: revise the Case through its normal version boundary. - Incorrect reusable standard: revise and approve the Policy or Rubric. - Product tradeoff: record the accountable owner's decision without presenting it as expert consensus. {% example-demo title="Escalation threshold dispute" %} One specialist accepts ordinary troubleshooting for an enterprise-managed account; another requires escalation. Their rationales reveal that one assumed a read-only action and the other assumed a contractual configuration change. The team adds the missing action-type context, splits applicability, approves the revised Policy and Rubrics, and adds two boundary Cases. Both original judgments remain attributable to the context each expert saw. {% /example-demo %} ## Evidence to collect - Conflicting reviewer judgments, rationales, and source context. - The owning artifact: Case, source boundary, Policy, applicability, or Rubric. - Human owner resolution, including any unresolved governance tradeoff. - Boundary cases added to preserve the resolved standard. - Benchmark comparison results after the standard is approved. ## Related docs {% related-card-grid title="Related docs" %} - [Handling Boundary Cases](/docs/coverage-engineering/boundary-cases) - [Resolve conflicting correctness evidence](/docs/governance/conflict-resolution) - [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model keeps attributable expert judgment, governed approval, applicability, coverage, and evaluation evidence distinct. Linked pages define the current Contribution, conflict-resolution, and versioning surfaces. --- id: playbooks.policy-heavy-ai-systems title: Using Teammately for Policy-Heavy AI Systems summary: Govern AI behavior where correctness depends on many explicit rules and boundary cases. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/policy-heavy-ai-systems --- # Using Teammately for Policy-Heavy AI Systems Use this playbook when an AI system can appear fluent while still violating explicit rules, exceptions, ownership boundaries, or customer-impacting policy. ## Establish the policy inventory Use this when correctness depends on several controlled rules, exceptions, or source hierarchies and each rule has an accountable owner. If the team cannot identify controlling sources and owners, begin with Reference Materials and Expert Contributions rather than drafting a large generic Policy set. ## Govern policy-heavy behavior 1. Connect the controlling sources in **Reference Materials** and identify the owner and effective boundary for each rule family. 2. Use Expert Contributions to resolve exceptions, cross-policy conflicts, missing facts, and operational interpretation. 3. In **Correctness Governance**, create narrow Policies with explicit applicability and one-obligation binary Rubrics. 4. Link representative passing, failing, and boundary Cases to the governed standards. 5. Configure Coverage Facets for policy family, exception type, authority, required context, and consequence. 6. Use Coverage Management to find Policy families or exception combinations with thin representation. 7. Create a Snapshot and Benchmark Version only after the selected Dataset and governing standards are ready. 8. Evaluate saved Harness Versions and inspect failures by Policy, Rubric, and Coverage Facet before changing the candidate. ## Maintenance triggers Refresh the governed boundary when a controlling source changes, an exception is added, applicability changes, a Rubric no longer tests one observable requirement, or new Cases expose a conflict. Historical Runs remain evidence under their original Benchmark Version. {% example-demo title="Subscription entitlement assistant" %} An assistant answers whether an account can use an enterprise integration after a plan change. Specialists separate three governing boundaries: plan entitlement, contract exception, and administrator permission. Each gets distinct applicability and a binary Rubric. Evaluation shows that the candidate reads the plan correctly but assumes administrator permission and ignores contract overrides, so the team can fix two precise behaviors instead of tuning a generic entitlement score. {% /example-demo %} ## Evidence to collect - Policy sources, accountable owners, and effective boundaries. - Applicability triggers for each policy family and risk tier. - Must-level binary rubrics and any lower-priority preference criteria. - Coverage dimensions for exceptions, conflicts, stale policy, and missing context. - Benchmark evidence grouped by Policy, Rubric, and Coverage Facet, with unresolved authority questions kept explicit. ## Related docs {% related-card-grid title="Related docs" %} - [Handling Boundary Cases](/docs/coverage-engineering/boundary-cases) - [Work with Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics) - [Inspect Dataset representation](/docs/benchmark-datasets/representation) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model separates source context, expert interpretation, governed standards, coverage, and evaluation. Linked code-backed pages define the active controls for each layer. --- id: playbooks.benchmark-refresh title: Refreshing a Benchmark from New Signals summary: Update benchmark coverage and standards when new cases, review findings, or product changes appear. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/refreshing-a-benchmark-from-new-signals --- # Refreshing a Benchmark from New Signals Use this playbook when customer-provided production examples, Contribution findings, source changes, or target-system changes show that the current Benchmark no longer represents the intended behavior. ## Classify the signal before editing Identify whether the signal changes the correctness standard, coverage vocabulary, available Cases, selected Dataset membership, or candidate behavior. These changes have different owners and version consequences. ## Refresh path 1. Record the signal, source, effective date, and latest Benchmark Version it may affect. 2. Route a source or rule change to Reference Materials, Expert Contributions, and Correctness Governance. 3. Route a changed behavior axis to Coverage Facets and review the impact on existing classifications. 4. Route missing examples to Assets Cases, Synthesis, or Coverage Management Case Foundry; review candidates in Case Review. 5. Change selected membership under Benchmark Datasets and create a new Dataset Snapshot. 6. Create the Benchmark Version that represents the revised Dataset and governed evaluator boundary. 7. Run the same saved Harness Version against the new boundary when you need to isolate the benchmark change. Run a new Harness Version separately when candidate behavior also changed. 8. Explain results using the two named boundaries; Compare does not implicitly normalize evidence across different Benchmark Versions. ## Preserve history Do not edit an older Snapshot or Run to resemble current reality. Staleness means the evidence may no longer answer the current question; it does not erase what the old version measured. {% example-demo title="Refund policy change" %} A support team adds a new outage-credit exception. The existing Benchmark remains valid for the former rule but has no Cases for the new exception. Experts approve revised applicability and Rubrics; Case Foundry prepares eligible, ineligible, and missing-account-evidence Cases; Case Review admits them into the current Dataset. A new Snapshot and Benchmark Version show that the unchanged Harness still passes ordinary refunds but fails the new outage boundary. {% /example-demo %} ## Evidence to collect - The new signal, its source, and the benchmark version it affects. - Cases, reference responses where supported, Policies, Rubrics, or Coverage Facets changed by the signal. - Human approval for whether the change updates standards, coverage, or both. - Previous and refreshed Snapshot and Benchmark Version IDs, saved Harness Version, settings, and Run Metadata. - Case-level evidence that explains movement caused by the revised boundary rather than candidate behavior. ## Related docs {% related-card-grid title="Related docs" %} - [Coverage Refresh](/docs/coverage-engineering/coverage-refresh) - [Staleness Detection](/docs/governance/staleness-detection) - [Work with Dataset Snapshots](/docs/benchmark-datasets/snapshots) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved lifecycle routes new signals to the artifact that owns the change and preserves historical evidence. Linked code-backed pages define the current Coverage, Dataset, Snapshot, governance, and Evaluation operations. --- id: playbooks.enterprise-assistant-review title: Running Expert Contributions for an Enterprise Assistant summary: Collect expert judgment for assistants that must follow product, domain, and policy expectations. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/running-expert-contributions-enterprise-assistant --- # Running Expert Contributions for an Enterprise Assistant Use this playbook when an enterprise assistant needs domain experts to judge outputs before the team turns that judgment into standards and benchmarks. ## Contribution boundary Use this when a named specialist must resolve a bounded correctness question that prepared Cases and source context cannot answer automatically. Do not use a Contribution as a general request to “review the assistant.” ## Request and complete the work 1. Name the decision the expert owns and select the smallest set of Cases that exposes it. 2. Prepare the Project Agent Brief, source material, Case context, questions, and allowed response form before sending the request. 3. In the Benchmark's **Expert Contributions** workspace, choose the recipient, Tasks, materials, and any Checkpoints required to confirm progress or handoff. 4. Pilot the Contribution with one specialist and verify that the recipient can enter the executable Task and has enough context to answer. 5. Preserve expert responses, rationale, unresolved questions, and Checkpoint state as Contribution provenance. 6. Inspect **Contributed Artifacts** and reconcile candidate Policies, Rubrics, Cases, or coverage observations into their owning project surfaces. 7. Apply the owning approval and version controls. Contribution completion does not automatically approve a Policy, Rubric, reference response, or Dataset membership change. ## Contribution is complete when The required Tasks and Checkpoints have reached their terminal states, the expert's attributable answer is preserved, and every contributed artifact is either reconciled, rejected through its owning workflow, or left explicitly unresolved. {% example-demo title="Procurement assistant review" %} A procurement specialist receives five Cases that differ by spend authority, vendor category, and contract status. The Contribution asks one bounded question: who must approve each purchase, and what source controls that answer? The specialist completes the Tasks, explains two exceptions, and confirms the proposed boundary at a Checkpoint. Contributed Policies and Rubrics retain that provenance but become governed only after the accountable owner approves them in Correctness Governance. {% /example-demo %} ## Evidence to collect - Cases, candidate outputs, Project Agent Brief, source context, and constraints shown to reviewers. - Checkpoint or interview records that capture reviewer rationale. - Attributable expert answers, rationale, unresolved concerns, and Checkpoint state. - Contributed artifacts and their reconciliation into Cases, Policies, Rubrics, or coverage observations. - Benchmark coverage and run results produced after standards are approved. ## Related docs {% related-card-grid title="Related docs" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution) - [Inspect Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model treats expert work as attributable contribution rather than automatic approval. Linked code-backed pages define request composition, executable Tasks, Checkpoints, lifecycle, and contributed-artifact reconciliation. --- id: playbooks.expert-judgment-to-standards title: Turning Expert Judgment into Policies and Rubrics summary: Convert specialist judgment into explicit, versioned, and testable correctness standards. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/turning-expert-judgment-into-policies-and-rubrics --- # Turning Expert Judgment into Policies and Rubrics Use this playbook when Expert Contribution notes are rich enough to explain correctness, but not yet structured enough to run repeatable benchmark checks. ## Materialization trigger Use this when several attributable expert answers reveal a recurring obligation, prohibition, exception, or source requirement. A single comment may justify investigation but should not silently become a reusable standard. ## From Contribution to governed standard 1. In **Contributed Artifacts**, select the attributable answers and Cases that express the same decision boundary. 2. Separate the reusable behavioral rule from applicability, supporting rationale, Case-specific preference, and unresolved disagreement. 3. Create or revise the Policy in **Correctness Governance** and link representative included and excluded Cases. 4. Create one binary Rubric for each observable must-level requirement. Keep “insufficient evidence” distinguishable from behavioral failure where the evaluator supports it. 5. Back-check the draft pair against the expert-reviewed Cases. A Rubric that cannot reproduce the intended boundary needs revision before approval. 6. Have the accountable owner approve and version the governed objects. 7. Create the Benchmark Version that uses the approved evaluator boundary, then evaluate saved Harness Versions. ## Do not materialize Keep the input as Contribution evidence when experts remain divided, the source is missing, the rule applies only to one unusual Case, or the proposed Rubric adds assumptions the expert never made. {% example-demo title="Eligibility answer standards" %} Across several Contributions, benefits specialists repeatedly reject answers that infer account-specific eligibility without the required fields. The team materializes a Policy separating general rules from account determinations, defines its applicability, and creates a binary Rubric requiring either the necessary evidence or an explicit uncertainty statement. Back-checking succeeds on the reviewed Cases, the owner approves the pair, and later evaluation exposes confident unsupported claims as a precise Rubric failure. {% /example-demo %} ## Evidence to collect - Reviewed Cases, responses, and attributable Contribution rationale used to derive standards. - Grouped obligations, prohibitions, exceptions, and source requirements. - Approved policies, applicability logic, and binary rubrics with version history. - Back-check evidence showing whether Rubrics reproduce the intended expert boundary. - Benchmark runs and comparison results that use the approved standards. ## Related docs {% related-card-grid title="Related docs" %} - [Writing Binary Rubrics](/docs/correctness-governance/binary-rubrics) - [Inspect Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) - [Work with Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model keeps expert provenance, governed approval, and evaluator evidence distinct. Linked code-backed pages define contributed artifacts, Policy and Rubric controls, versioning, and evaluation. --- id: playbooks.alongside-existing-evals title: Using Teammately Alongside Existing Evaluation Infrastructure summary: Position Teammately as correctness infrastructure that can complement existing tests and metrics. kind: recipe product_area: playbooks status: stable updated: 2026-09-07 canonical: /docs/playbooks/using-teammately-alongside-existing-evaluation-infrastructure --- # Using Teammately Alongside Existing Evaluation Infrastructure Use this playbook when a team already has tests, traces, dashboards, or offline evals and wants Teammately to add expert-grounded correctness evidence rather than replace everything. ## Choose the integration boundary Use this when existing infrastructure already owns candidate execution, CI status, traces, or metrics and the team wants Teammately to own deliberate coverage, expert-grounded standards, and Benchmark evidence. Keep external systems authoritative for facts Teammately does not ingest or compute. ## Two supported evidence paths 1. Inventory the external Case identity, candidate identity, metrics, CI status, and links needed by customer operators. 2. Import representative inputs as Teammately Cases and design their coverage and governed evaluator boundary. 3. For a candidate Teammately can execute, save it as a Harness Version and create a managed Run. 4. For responses produced externally, export immutable Teammately Case IDs, generate one response per intended Case, and map them into an output-only Run. 5. Store useful external candidate or run identifiers in the configured Run Metadata fields. Do not claim Teammately verified an external metric merely because its identifier is present. 6. Inspect Teammately Rubric evidence in List. Use Compare and Arena only for saved Harness Versions; output-only Runs are not Harness columns. 7. In customer-owned human review context, present Teammately evidence and external CI or telemetry as separately sourced facts. ## Ownership matrix | Evidence | Owning system | | --- | --- | | Coverage Facets, Policies, Rubrics, Benchmark Versions | Teammately | | Managed Harness response and Rubric outcomes | Teammately Run | | Imported response mapping and Rubric outcomes | Teammately output-only Run | | External latency, CI status, trace, or deployment fact | External system | | Downstream operational decision | Customer | {% example-demo title="CI benchmark handoff" %} A team keeps latency and regression tests in CI. It exports Teammately Case IDs, produces candidate responses externally, and imports them as one output-only Run with the CI run ID in Run Metadata. Teammately reports must-level Policy failures for those responses; CI remains authoritative for latency. The customer's review context shows both facts with their sources and does not treat the imported candidate as a saved Harness Version. {% /example-demo %} ## Evidence to collect - External eval artifacts and the identifiers needed to trace candidates or runs. - The Teammately-owned Cases, standards, coverage, Benchmark Version, output mapping, Rubric evidence, and Run Metadata. - Mapping notes that explain which metrics remain outside Teammately. - Benchmark comparisons under approved human standards. - Review context that keeps external CI status separate from Teammately benchmark evidence. ## Related docs {% related-card-grid title="Related docs" %} - [Map external outputs](/docs/benchmark-evaluations/output-mapping) - [Configure Run Metadata](/docs/benchmark-evaluations/run-metadata) - [Compare Harness Versions](/docs/benchmark-evaluations/compare) - [Read run results](/docs/benchmark-evaluations/inspect-results) - [Run a benchmark](/docs/benchmark-evaluations/run-evaluation) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Agent Setup](/docs/agent-setup) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product boundary keeps Teammately correctness evidence separate from external infrastructure facts and customer decisions. Linked code-backed pages define managed Runs, output-only Runs, Run Metadata, and comparison eligibility. --- 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: orientation.end-to-end title: Operating Teammately end to end summary: Operate the current product from project foundations through benchmark coverage, expert contribution, evaluation, and improvement. kind: task product_area: operating_manual status: stable updated: 2026-09-07 canonical: /docs/getting-oriented/operating-teammately-end-to-end --- # Operating Teammately end to end Use this workflow to coordinate the full correctness system while keeping project foundations, benchmark work, expert authority, evaluation evidence, and candidate improvement separate. ## Decision checkpoint | Phase | Owning scope | Exit condition | | --- | --- | --- | | Establish project understanding | Project | Project Agent Brief and Indexed Reference are usable | | Define content and reusable assets | Project | Project Input Schema, Cases, Harnesses, and Coverage Facets are explicit | | Establish benchmark evidence | Benchmark | Dataset snapshot and coverage state are reviewable | | Resolve specialist correctness | Benchmark Contribution and project governance | Attributable artifacts have explicit lifecycle state | | Evaluate candidates | Benchmark version | Exact Runs and case/rubric evidence are available | | Improve behavior | Benchmark version | Goal Contract, candidates, receipts, and frontier are durable | ## Prerequisites - A workspace and project. - An accountable operator, domain expert, and AI engineer or candidate owner. - Source knowledge, examples, and a candidate system appropriate to the intended benchmark. ## Before and after | Before | Operation | After | | --- | --- | --- | | Agents lack a shared project model | Configure Agent Setup | Project understanding is reusable and inspectable | | Examples have inconsistent shape | Save Project Input Schema and prepare Cases | Inputs and materials share a canonical contract | | Coverage and correctness are implicit | Define Coverage Facets and request Contributions | Benchmark intent and specialist standards are explicit | | Candidate claims depend on anecdotes | Run Benchmark Evaluations | Evidence is bound to versions, cases, and rubrics | | Engineering iterations lack chronology | Use Improve | Goals, candidates, receipts, and current frontier stay connected | ## Steps 1. Configure Project Context and Reference Materials in **Agent Setup**. Create or select Comparison Directions and Review Screens under **Assets** when a Contribution needs them. 2. Save Project Input Schema and establish reusable Coverage Facets. 3. Create or import Cases and save candidate Harness versions under Assets. 4. Create or select a benchmark, configure Coverage Management, select Cases in Benchmark Datasets, inspect Representation, and preserve a snapshot. 5. Request focused Expert Contributions for unresolved standards, cases, or coverage. Reconcile contributed artifacts in their owning project or benchmark surfaces. 6. Confirm governed policies and rubrics and the benchmark version that will use them. 7. Run exact saved Harness versions through Benchmark Evaluations. Inspect Dashboard, List, Compare, Arena, and Run detail according to the question. 8. Start an Improvement Session only from evidence that identifies measurable candidate work. 9. Return newly discovered correctness or coverage gaps to Expert Contributions, Correctness Governance, Coverage Management, or Cases. ## Object and state changes This workflow touches project context, reference indexes, input schema, facets, assets, benchmark datasets and snapshots, coverage state, Contributions and contributed artifacts, policies, rubrics, Harness versions, Runs, evaluation results, and Improvement Sessions. Each object remains in its owning scope and retains historical evidence. ## Success criteria - Project and benchmark scope is explicit at every operation. - Agent preparation, expert judgment, and governed artifacts remain distinguishable. - Dataset and candidate versions make evaluation reproducible. - Improvement begins with a measurable goal and pinned evidence. - New learning returns to one responsible upstream artifact. ## Common failure modes - Putting benchmark-specific instructions into permanent Project Context. - Treating connected sources as approved standards. - Selecting generated Cases without case review or schema conformance. - Comparing Runs after multiple evidence boundaries changed. - Treating external-worker activity as observable before an artifact returns. {% example-demo title="Example: full grounding loop" %} A team indexes source repositories, defines source-authority coverage, imports canonical cases, and requests a Contribution to resolve conflicting guidance. The governed rubric enters a benchmark version, two saved Harness versions are compared, and an Improvement Session tests retrieval changes. A missing-source pattern discovered during improvement returns to Coverage Management. {% /example-demo %} ## 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 %} ## Related troubleshooting pages {% related-card-grid title="Related troubleshooting pages" %} - [Expert Contribution problems](/docs/troubleshooting/expert-contributions) - [Benchmark runs](/docs/troubleshooting/benchmark-runs) - [Unbalanced coverage](/docs/troubleshooting/unbalanced-coverage) {% /related-card-grid %} ## Source confidence Doctrine-backed: the sequence follows the current public capability model and active product topology. Linked pages provide code-backed operation details. --- 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.