# Represent conversations in Cases Generated: 2026-09-13T04:39:08.445Z Source build: local Canonical docs: https://teammately.ai/docs --- id: object-model.conversation-inputs title: Represent conversations in Cases summary: Preserve multi-message context inside canonical Case input without inventing a separate Conversation Case object. kind: reference product_area: object_model status: stable updated: 2026-08-23 canonical: /docs/object-model/represent-conversations-in-cases --- # Represent conversations in Cases ## Definition A canonical Case input can represent a multi-message interaction when correctness depends on prior turns, accumulated context, or state carried across an exchange. “Conversation” describes the shape of the Case input; it is not a separate first-class object or a public schema guarantee. Use this reference when review or evaluation depends on exactly which messages were available before the response being judged. ## Fields, states, or lifecycle rules - Preserve the message order and roles needed to interpret the Case. - Identify the response being judged separately from prior user or assistant messages. - Store supporting documents or structured material according to the Project Input Schema instead of flattening everything into message text. - Removing, reordering, or summarizing material can change the Case and should follow the normal Case version boundary. - Output mapping joins an external response to the Case ID; it does not repair missing conversational context. - This page does not define a public conversation serialization contract. ## Related objects Read this representation with [Cases](/docs/object-model/cases), [Outputs](/docs/object-model/outputs), [Project Input Schema](/docs/project-settings/input-schema), and [Metadata and Context](/docs/reference/metadata-and-context). {% example-demo title="Plan context carried across turns" %} A user first identifies an enterprise plan, then asks whether a feature is available. The later response can only be judged correctly if the earlier plan message remains part of the canonical Case input. If that message is removed, create a new Case version rather than trying to restore it during output mapping. {% /example-demo %} ## Source confidence Code-backed: Case-content services support structured project input and material fields, while record presentation and Case-view types preserve the context used for review. The sources support conversation-shaped Case input but not a distinct Conversation Case object or public import schema. ## Related task pages {% related-card-grid title="Related task pages" %} - [Configure the Project Input Schema](/docs/project-settings/input-schema) - [Import and prepare Cases](/docs/operating-manual/import-and-prepare-cases) - [Inspect evaluation results](/docs/benchmark-evaluations/inspect-results) - [Troubleshoot unclear Cases](/docs/troubleshooting/unclear-cases) {% /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: 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: reference.metadata-context title: Metadata and context summary: Use record context and metadata fields to make Teammately cases easier to filter, review, and analyze. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/metadata-and-context --- # Metadata and context ## Definition Metadata and context are the supporting fields that make records and cases understandable after they move through import, review, coverage, and benchmark workflows. Context explains the situation; metadata helps filter, segment, trace, and compare it. Use this page when a case is technically present but not useful because reviewers cannot see why it belongs in a behavior slice or what source information should be considered. ## Fields, states, or lifecycle rules - Context should preserve the information a reviewer needs to judge the case. - Metadata should support filtering, coverage planning, benchmark segmentation, and run interpretation. - Metadata is not a substitute for output identity or source context. - Dropped or inconsistent metadata can make coverage look balanced while hiding a missing behavior segment. - This page does not define a public metadata schema or export format. ## Related objects Metadata and context should be read with [Cases](/docs/assets/cases), [Importing cases](/docs/operating-manual/import-and-prepare-cases), [Case versions](/docs/governance/case-versioning), and [Coverage Engineering](/docs/coverage-engineering). {% example-demo title="Metadata and context boundary" %} Raw record: A support transcript includes a customer request, account tier, candidate answer, and later human correction. Context: The account tier and correction explain why the answer was unsafe. Metadata: The case can be segmented as exception request, enterprise tier, and human-corrected source. Interpretation: If that context or metadata is dropped, review and coverage work can still run but the evidence becomes harder to trust. {% /example-demo %} ## Source confidence Code-backed: Cases and record presentation expose contextual fields to reviewers, while Case Pool column mapping and upload-queue types show how imported columns become usable record context. Field availability depends on Project configuration; this is not a universal metadata schema. ## Related task pages {% related-card-grid title="Related task pages" %} - [Cases](/docs/assets/cases) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Connect model outputs](/docs/integrations/connect-model-outputs) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %}