# Import Case Examples
Generated: 2026-09-13T04:33:50.036Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: integrations.import-case-examples
title: Import Case Examples
summary: Bring real product behavior examples into a Project and reconcile them against Project Input Schema before benchmark use.
kind: task
product_area: data_integrations
status: stable
updated: 2026-09-07
canonical: /docs/integrations/import-case-examples
---
# Import Case Examples
## Prerequisites
- A target Project and permission to work with Cases.
- The current Project Input Schema, including required input architecture and case-material fields.
- Source examples with stable provenance or customer correlation IDs.
- Any files referenced as Case materials.
- An operator who can resolve ambiguous column mappings and rejected rows.
## Before and after
| before | after |
| --- | --- |
| Source rows mix input, prior messages, context, outputs, and notes | Each admitted Case has canonical input, named Case materials, and customer-owned attributes |
| File references are local paths or source-system links | Required files are Teammately artifacts with processing state |
| Source identifiers are known only outside Teammately | Correlation IDs remain attached without replacing backend-issued Case IDs |
| No benchmark membership is implied | Imported Cases are reusable Project Assets and can be selected deliberately for benchmark work |
## Import workflow
### Task steps: Import Case examples
1. Open Project Settings and inspect **Project Input Schema**. Confirm whether the Project expects plain text, chat, or structured input and which Case materials are required.
2. Prepare a small representative sample. Separate the Case input from candidate output, human correction, and source-system bookkeeping.
3. Open the Case import flow from the Project's Cases or Case Pool surface and upload the supported source file.
4. Map source columns to input, named Case materials, and customer attributes. Do not map candidate output into Case input merely because it shares a row.
5. Preview the normalized Cases. Inspect conversations, structured values, file associations, empty required fields, and duplicate source identifiers.
6. Resolve validation and artifact-processing failures before admitting the full collection.
7. Complete the import, then inspect the admitted Cases in Assets. Confirm Case identity, current version, source context, and material readiness.
8. Add Cases to coverage or a Benchmark Dataset only after the team has reviewed whether they belong there.
## Object and state changes
Import creates reusable Project Cases and can create artifact-processing work for referenced files. Reimporting a synchronized source example can create a new Case version when canonical content changes.
Import does not automatically approve a Case, assign coverage facets, add it to every Benchmark, create a Dataset Snapshot, attach candidate outputs, or declare the Case representative.
## Success criteria
- Every admitted Case matches the current Project Input Schema.
- Input, conversation history, Case materials, attributes, and outputs remain distinct.
- Required artifacts are ready or visibly pending; none are silently missing.
- Source correlation survives without replacing Teammately Case identity.
- Rejected rows have an understood field-level reason.
- Benchmark membership remains a separate deliberate action.
## Common failure modes
- Treating every source column as arbitrary metadata instead of mapping the canonical input.
- Flattening a multi-turn conversation into one unstructured string.
- Attaching the model's answer as input rather than as external Run output.
- Relying on filenames or input text as durable Case identity.
- Importing the full corpus before validating a representative sample.
- Assuming upload completion means artifact processing and Case admission completed.
- Sending required context as a Reference Material when it must travel with each Case.
{% example-demo title="Support transcript import" %}
A source row contains a ticket ID, three messages, the assistant's answer, region, and the policy PDF used by the support specialist.
The importer keeps the ticket ID as customer correlation, represents the three-message history as chat input, attaches the PDF to the configured `policy_document` Case material, and keeps region as an attribute. The assistant answer is not stored in Case input; it can later enter as an external Run output or an accepted target through its owning workflow.
{% /example-demo %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Project Input Schema](/docs/project-settings/input-schema)
- [Cases](/docs/assets/cases)
- [Integrations](/docs/integrations)
- [Case object](/docs/object-model/cases)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Dataset upload](/docs/troubleshooting/dataset-upload)
- [Unclear Cases](/docs/troubleshooting/unclear-cases)
- [Missing outputs](/docs/troubleshooting/missing-outputs)
{% /related-card-grid %}
## Source confidence
Code-backed: the active Case, Case Pool upload, mapping, and Project Input Schema sources define the workflow and validation boundary. File limits and exact automated import serialization remain outside this stable UI task until the Public API contract is implemented.
---
id: operating.import-prepare-cases
title: Import and prepare cases
summary: Bring cases into the project, conform them to Project Input Schema, inspect materials, and prepare benchmark selection.
kind: task
product_area: operating_manual
status: stable
updated: 2026-08-23
canonical: /docs/operating-manual/import-and-prepare-cases
---
# Import and prepare cases
Bring existing examples into the project and make them usable by experts, coverage work, and Harness execution without losing their input or material boundaries.
## Prerequisites
- A saved Project Input Schema.
- Source examples with identifiable primary input.
- Required case materials and accepted artifact formats.
- A selected project and permission to manage Cases.
## Steps
1. Review **Project Settings → Input Schema** and confirm plain-text, chat, or structured architecture.
2. Identify the primary input for each source example and map it to `content.input`.
3. Map supporting values or artifacts to declared `content.case_materials` keys.
4. Reject or correct records missing required materials, using unsupported artifact types, or violating the structured schema.
5. Import or create the Cases through the available product path.
6. Open representative Cases and inspect the rendered case view. Confirm that inputs, materials, labels, and source authority are understandable without private explanation.
7. Classify or connect the relevant Coverage Facets.
8. Select reviewed Cases in Benchmark Datasets and create a snapshot when the membership defines a new evaluation boundary.
The upload step stages source records. Continue through column mapping and inspect representative rendered Cases before selecting them for a Benchmark.
## Object and state changes
This task creates project Cases and may attach artifact records, material references, coverage classifications, and benchmark selection. The rendered case view is derived from canonical content. Selecting a Case for one benchmark does not remove it from the reusable project pool or select it for every benchmark.
## Success criteria
- Every Case conforms to the Project Input Schema.
- Required materials are present and use accepted formats.
- The rendered case view preserves the intended input and evidence.
- Cases can be understood by an expert and delivered to a Harness.
- Benchmark selection and snapshot state are explicit.
## Common failure modes
- Putting supporting documents into an unstructured metadata field.
- Treating candidate responses as the primary case input.
- Importing artifacts the project schema does not admit.
- Selecting unclear Cases into a benchmark before review.
- Changing case content while comparing Runs against an earlier snapshot.
{% example-demo title="Example: import chat cases with documents" %}
A project uses chat architecture and requires a `policy_document` material. The operator maps each conversation to canonical messages, attaches the controlling PDF, rejects rows without the document, and inspects rendered case views. Only reviewed Cases are selected for the benchmark snapshot.
{% /example-demo %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Cases](/docs/assets/cases)
- [Project Input Schema](/docs/project-settings/input-schema)
- [Benchmark Datasets](/docs/benchmark-datasets)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Dataset upload](/docs/troubleshooting/dataset-upload)
- [Unclear cases](/docs/troubleshooting/unclear-cases)
- [Missing outputs](/docs/troubleshooting/missing-outputs)
{% /related-card-grid %}
## Source confidence
Code-backed: the active Cases surface and case-content contract support canonical input, materials, rendering, and schema validation. Exact import mechanisms can depend on the available product configuration.
---
id: project-settings.input-schema
title: Project Input Schema
summary: Define the canonical input architecture, case-material fields, and accepted artifact formats for project cases.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/input-schema
---
# Project Input Schema
## Definition
Project Input Schema is the project-managed contract for future cases. It declares the primary input architecture, optional structured-input schema, named case-material fields, and artifact families or file extensions the project accepts.
The active architectures are **plain text**, **chat**, and **structured**. The schema is a project singleton rather than a versioned benchmark object. When no setting exists, the default accepts one plain-text user message and no case materials or artifacts.
## Fields, states, or lifecycle rules
- `architecture` is `plain_text`, `chat`, or `structured`.
- Structured architecture requires a bounded `structuredInputSchema`.
- `caseMaterialSchema` is a closed, flat object. Each material key has a label, optional description, required flag, type, and any accepted artifact rules.
- Material keys use lowercase letters, digits, and underscores, start with a letter, and remain flat.
- `acceptedArtifacts` declares project-level artifact families. Supported families are image, document, tabular, presentation, source text, and audio.
- A case-material artifact rule must be a subset of the artifact families admitted at the project root.
- Saving a new schema governs future case validation. Operators should inspect existing cases before making a change that would make current content invalid.
## Canonical case content
The primary case payload is `content.input`. Optional supporting values and artifacts live in `content.case_materials`. The product renders `record_content.case_view` so people and execution adapters can inspect the canonical content consistently; that view is a projection rather than an alternate authoring contract.
Static support passed to a Harness uses `case_material_refs`. An executable or queryable environment uses an optional `world_instance_ref`. Do not collapse static documents, images, or values into the world boundary merely because a candidate consumes them during a Run.
{% example-demo title="Example: structured support case" %}
A project selects structured input with `question` and `customer_tier` properties. It declares a required `policy_document` case material that accepts PDF documents and an optional `account_history` tabular material. A case is valid only when its structured input matches the schema and the required document is present in the accepted format.
{% /example-demo %}
## Source confidence
Code-backed: the active settings route and backend validator define the input architectures, closed case-material schema, artifact families, defaults, and canonical case paths. This page explains the product contract without presenting internal handlers as a public API.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Project Settings](/docs/project-settings)
- [Product quickstart](/docs/quickstart)
- [Work with cases](/docs/assets/cases)
- [Design Review Screen](/docs/assets/review-screens)
{% /related-card-grid %}
---
id: assets.cases
title: Cases
summary: Understand canonical project cases, their input and materials, and how they become members of benchmark datasets.
kind: reference
product_area: assets
status: stable
updated: 2026-08-22
canonical: /docs/assets/cases
---
# Cases
## Definition
A Case is a project-level situation used for expert contribution, benchmark coverage, or candidate evaluation. It has canonical input content and may include declared supporting materials. Cases live in the Assets pool and can be selected into one or more benchmark datasets.
The Project Input Schema determines how the primary input and materials are represented. A benchmark snapshot determines which selected cases belong to one versioned evidence boundary.
## Fields, states, or lifecycle rules
- Canonical primary input is stored under `content.input`.
- Optional supporting values or artifacts are stored under `content.case_materials` according to the project's declared keys.
- `record_content.case_view` is a rendered projection used for inspection and delivery; it is not a second editable payload.
- Inputs can use plain-text, chat, or structured architecture as configured by the project.
- Materials can include admitted artifact families and must satisfy any required-field and file-extension rules.
- A project Case is not automatically part of every benchmark. Benchmark Datasets owns selection and snapshots.
- Generated or imported Cases should be reviewed for clarity, source authority, and schema conformance before they are trusted as benchmark evidence.
- Static case materials and executable Worlds remain separate. A document supplied to a Harness does not become a world merely because it affects execution.
## Case identity and change
Treat the persisted case identity as opaque. Do not construct IDs in client code or documentation. When case content changes materially, benchmark interpretation must use a snapshot or version boundary that makes the selected content clear.
Responses produced by a Harness are evaluation outputs attached to a Run. They are not the primary case input. Expert-authored acceptable examples can inform standards or contribution work, but the current evaluation contract should remain explicit about which candidate produced each response.
{% example-demo title="Example: multimaterial case" %}
A chat case asks whether an exception applies. Its required `current_policy` PDF and optional `account_history` table are stored as case materials admitted by Project Input Schema. The rendered case view presents the conversation and both materials. A benchmark snapshot selects the case, and a Run records the evaluated Harness response separately.
{% /example-demo %}
## Source confidence
Code-backed: the active Assets Cases route and case-content services define canonical input, case materials, and the rendered case view. Public import or export APIs are outside this reference unless separately documented.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Configure Project Input Schema](/docs/project-settings/input-schema)
- [Work with Benchmark Datasets](/docs/benchmark-datasets)
- [Manage benchmark coverage](/docs/coverage-management)
{% /related-card-grid %}
---
id: troubleshooting.dataset-upload
title: Case upload troubleshooting
summary: Repair uploads with rejected rows, missing inputs, incorrect column mapping, or Cases that arrive without usable context.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-09-07
canonical: /docs/troubleshooting/dataset-upload
---
# Case upload troubleshooting
## Symptoms
- The file is rejected before column mapping.
- Required input fields are absent or cannot be selected.
- The preview puts outputs, metadata, or conversation context in the wrong fields.
- The upload completes but expected Cases are not visible in the Case Pool.
- Imported Cases are visible but cannot be reviewed or classified reliably.
## Likely causes
- The source file has unusable headers, duplicate columns, or blank input rows.
- Required Case input is unmapped or mapped from the wrong column.
- Conversation context, output identity, or metadata was flattened into the wrong field.
- The import completed, but the operator expected candidate Cases to become Benchmark members automatically.
## Diagnose the upload in order
1. Confirm the selected file is the intended source and uses a supported tabular shape for the upload surface.
2. Inspect headers and several real rows outside Teammately. Remove blank header rows, merged presentation cells, duplicate column names, and records that contain no usable input.
3. Return to **Map columns**. Map the Case input first, then candidate or reference output only when that identity is known. Map contextual columns as context or metadata rather than concatenating them into the input.
4. Review the preview for nulls, truncated objects, serialized JSON, and swapped user/assistant fields.
5. Submit a small representative file before importing the whole source.
6. After completion, open the Case Pool and verify row counts, a simple Case, a boundary Case, a conversation Case, and a row with missing optional data.
## Fix
- **No required input:** choose the correct input column or add a normalized input field to the source file.
- **Conversation collapsed into text:** preserve the structured turn context supported by the Project instead of guessing a public conversation schema.
- **Output mapped as input:** correct the mapping and re-upload; do not silently edit already selected benchmark evidence.
- **Missing context:** map supporting columns, then decide whether the existing imported Cases should be superseded or retained as an identifiable attempt.
- **Duplicate Cases:** compare stable source identifiers and Case content before adding candidates to a Benchmark.
## Prevention
Keep an untouched source file, a documented mapping decision, and a small QA sample. Treat database or internal representation details as implementation, not as the upload contract. The product preview is the last checkpoint before rows become Case Pool candidates.
{% example-demo title="Example: transcripts import without account tier" %}
The upload succeeds, but reviewers cannot explain why enterprise exceptions apply. The operator finds that `account_tier` was left unmapped. They add it as context, re-upload a representative sample, confirm the field in Case presentation, and only then import the full set. The incomplete candidates are not added to a Benchmark.
{% /example-demo %}
## Source confidence
Code-backed: the Case Pool upload, column-mapping, queue, and Case Pool surfaces establish file selection, mapping, submission state, and post-upload visibility. Supported customer file details remain whatever the current UI validates; this page does not create a public ingestion schema.
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Import and prepare Cases](/docs/operating-manual/import-and-prepare-cases)
- [Case Pool](/docs/coverage-engineering/case-pool)
- [Metadata and context](/docs/reference/metadata-and-context)
- [Unclear Cases](/docs/troubleshooting/unclear-cases)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference" %}
- [Cases](/docs/object-model/cases)
- [Case Pool](/docs/object-model/case-pool)
- [Metadata and context](/docs/reference/metadata-and-context)
{% /related-card-grid %}