# Reference and golden outputs
Generated: 2026-09-13T04:39:33.342Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: object-model.reference-outputs
title: Reference and golden outputs
summary: Understand Case-scoped example responses without treating them as generic approval state or candidate behavior.
kind: reference
product_area: object_model
status: stable
updated: 2026-09-07
canonical: /docs/object-model/reference-and-golden-outputs
---
# Reference and golden outputs
## Definition
A golden or reference output is a Case-scoped example response available on supported review, mapping, or Snapshot surfaces. It can help a reviewer understand intended behavior for that Case, but it is not a global Policy, a saved Harness Version, or a generic customer approval state.
Use this reference only where the product explicitly exposes a golden or reference response. Do not rename every expert answer, reviewed response, or imported candidate output as an “accepted output.”
## Fields, states, or lifecycle rules
- Keep the reference response attached to the Case and evidence context that justifies it.
- A candidate Run response does not become a reference response merely because it passed a Rubric.
- Reviewer comments and Contribution rationale remain attributable review input, not output state.
- A reference-output change can require a new Case, Snapshot, or Benchmark Version boundary when it affects governed interpretation.
- Policies and Rubrics remain the reusable correctness standard; a reference output illustrates one Case.
- This page does not define an export format or public output schema.
## Related objects
Read reference outputs with [Outputs](/docs/object-model/outputs), [Cases](/docs/object-model/cases), [Correctness Governance](/docs/correctness-governance), and [Expert Contributions](/docs/expert-contributions).
{% example-demo title="Case-scoped reference response" %}
A compatibility Case includes a reference response that says the available source does not confirm support and directs the user to an explicit compatibility check. The response illustrates desired behavior for that Case. The reusable requirement still belongs in the applicable Policy and Rubric.
{% /example-demo %}
## Source confidence
Code-backed: output mapping, Snapshot artifacts, linked Policy Cases, and Contribution review surfaces expose golden or reference responses as Case-scoped evidence with explicit review or overwrite actions. The sources do not establish a universal accepted-output lifecycle.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Map external outputs](/docs/benchmark-evaluations/output-mapping)
- [Review prepared Cases](/docs/coverage-management/case-review)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Inspect evaluation results](/docs/benchmark-evaluations/inspect-results)
{% /related-card-grid %}
---
id: object-model.outputs
title: Outputs
summary: Distinguish managed Run responses, imported output-only Runs, and Case-scoped reference outputs.
kind: reference
product_area: object_model
status: stable
updated: 2026-08-23
canonical: /docs/object-model/outputs
---
# Outputs
Understand the outputs Teammately reviews, compares, and turns into correctness evidence.
## Definition
An output is response evidence associated with a Case, but its identity depends on the workflow that produced it. A managed Evaluation Run generates a response from a saved Harness Version. An imported output-only Run maps externally produced responses to immutable Case IDs. A Case may also expose a golden or reference response where the current surface supports it.
Do not collapse these into one generic “accepted output” lifecycle. Imported outputs are not Harness Versions, Run responses are not automatically reference answers, and reviewer comments are not outputs.
## Fields, states, or lifecycle rules
- A managed Run response is bound to the Run, saved Harness Version, Benchmark Version, and Case.
- An imported output-only Run joins external rows to immutable Case IDs and retains imported candidate metadata.
- Output-only Runs can be scored and inspected, but cannot be activated, optimized in Improve, or used as Harness columns in Compare or Arena.
- A golden or reference output is Case-scoped example evidence where exposed; it does not become a global Policy.
- Mapping errors can make evidence misleading even when the external response data is unchanged.
- This page documents object boundaries, not model execution, provider behavior, or public output schemas.
## Related objects
Read outputs with [Cases](/docs/object-model/cases), [Reference and golden outputs](/docs/object-model/reference-and-golden-outputs), [Run an evaluation](/docs/benchmark-evaluations/run-evaluation), and [Map external outputs](/docs/benchmark-evaluations/output-mapping).
{% example-demo title="Target model outputs boundary" %}
Case: A user asks whether a product is compatible with equipment they own.
Candidate output: The assistant says the product will work.
Interpretation: The benchmark failure belongs to the candidate output, but the reviewer still needs the case context and applicable rubric to explain why it failed.
{% /example-demo %}
## Source confidence
Code-backed: Benchmark Dataset output mapping and Evaluation Run detail distinguish imported output-only evidence from managed Run responses; review and Case-content sources preserve the Case boundary. Provider execution and customer serialization are outside this reference.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Run an evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Map external outputs](/docs/benchmark-evaluations/output-mapping)
- [Connect model outputs](/docs/integrations/connect-model-outputs)
- [Inspect evaluation results](/docs/benchmark-evaluations/inspect-results)
{% /related-card-grid %}
---
id: object-model.cases
title: Cases
summary: Understand cases as the situations Teammately uses to represent important AI behavior.
kind: reference
product_area: object_model
status: stable
updated: 2026-08-23
canonical: /docs/object-model/cases
---
# Cases
## Definition
Cases are the behavior situations Teammately uses for review, coverage, and benchmark evidence. A case should preserve the input, source context, metadata, and version boundary needed to understand what behavior is being judged.
Use this reference when a workflow depends on whether an example is reviewable, benchmark-ready, stale, duplicated, or missing the context a reviewer needs.
## Fields, states, or lifecycle rules
- A case is not the same thing as an output; the case holds the situation and context, while the output is the behavior being judged.
- A case can be useful for coverage planning before it is ready for benchmark use.
- Case versions matter when source context, metadata, or expected behavior changes.
- A benchmark result is weak if the failed output cannot be traced back to the exact case version.
- Exact import schema and export behavior belong to source-backed integration pages, not this object reference.
## Related objects
Cases should be read with [Outputs](/docs/object-model/outputs), [Case versions](/docs/governance/case-versioning), [Case pool](/docs/object-model/case-pool), and [Benchmarks](/docs/object-model/benchmarks). Use [Importing cases](/docs/operating-manual/import-and-prepare-cases) when the next step is bringing source examples into Teammately.
{% example-demo title="Cases boundary" %}
Raw record: A transcript includes a customer question, assistant answer, account context, and later human correction.
Case: The reviewable unit preserves the customer question and account context.
Output: The candidate answer is attached separately so reviewers know which behavior is being judged.
Interpretation: If the candidate fails later, the run result can point to the exact case and output rather than to a vague transcript.
{% /example-demo %}
## Source confidence
Code-backed: Case view types and the Cases asset route establish the product object and its presentation; internal Case-content types establish how input and contextual material remain separate from outputs. These implementation sources support object semantics, not a customer-facing serialization contract.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Case model overview](/docs/assets)
- [Case Pool](/docs/coverage-engineering/case-pool)
- [Case pool](/docs/object-model/case-pool)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
---
id: correctness.policies-rubrics
title: Policies and Rubrics
summary: Understand the governed relationship between behavior policies, applicability, binary rubrics, linked cases, and expert provenance.
kind: reference
product_area: correctness_governance
status: stable
updated: 2026-08-23
canonical: /docs/correctness-governance/policies-and-rubrics
---
# Policies and Rubrics
## Definition
A **Policy** is a reusable statement of expected specialist AI behavior. Its applicability explains the situations in which the rule controls. A **Rubric** is an evaluation criterion that turns the policy into observable evidence for a case and candidate response.
Correctness Governance owns both artifact types. Expert Contributions can supply proposed or accepted policy and rubric material, while the governance surfaces preserve the artifact's current state, links, activity, and provenance.
## Fields, states, or lifecycle rules
- Policies have identity, descriptive rule content, scope or applicability, linked cases, linked rubrics, activity, and approval context.
- Rubrics have identity, criterion wording, policy or case relationships, evaluation relevance, and lifecycle context.
- A policy can connect to several rubrics when its behavior requirements need separate checks.
- A rubric should express one inspectable criterion wherever independent diagnosis matters.
- Linked cases demonstrate applicability or behavior; benchmark dataset membership remains a separate benchmark-scoped decision.
- Proposed applications and agent suggestions remain proposals until the owning workflow records acceptance.
- Expert contribution provenance should remain visible when contributed material becomes a governed artifact.
- Editing a project-level standard does not retroactively change the standard boundary used by an already recorded Run.
Read the rule, state, links, and owner together; a plausible title alone does not establish governed authority.
## Reading the pair
Begin with the policy when deciding what should happen and why. Inspect applicability before assuming the policy governs a case. Then read the linked rubric as the testable question applied to candidate behavior. If the rubric cannot be answered from the response and visible case evidence, revise the criterion or the case rather than relying on reviewer intuition.
When standards overlap, distinguish complementary criteria from contradictory authority. Preserve unresolved conflict until an accountable expert contribution or governance action settles the intended rule.
{% example-demo title="Example: escalation policy and rubrics" %}
A policy states that unresolved eligibility exceptions must be escalated. One rubric checks that the response does not promise the exception; another checks that it gives the correct escalation path. Separating the checks lets an evaluation show whether a candidate avoided the unsupported promise but still failed to guide the user correctly.
{% /example-demo %}
## Source confidence
Code-backed: active policy and rubric detail routes expose linked cases, linked rubrics, approval and activity context, and evaluation relationships. Exact editable fields can vary by artifact state.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics)
- [Write binary rubrics](/docs/correctness-governance/binary-rubrics)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}