# Case upload troubleshooting
Generated: 2026-09-13T04:39:11.343Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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 %}
---
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: coverage.case-pool
title: Case Pool
summary: Use the Case Pool to collect, triage, enrich, and promote candidate cases.
kind: concept
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/case-pool
---
# Case Pool
## Definition
Case Pool is the project-level working set for reusable Cases and Case sourcing activity. The current UI routes Case inspection through **Assets → Cases** and keeps **Sourcing Tasks** under Coverage Engineering. Together they let operators inspect Case content and provenance, follow preparation tasks, classify coverage, and select Cases for one or more Benchmarks.
## Why it matters
Cases often arrive before the team knows whether they are clear, representative, or tied to a meaningful coverage need. The Case Pool provides a project boundary where imported, generated, or contributed Cases can be reviewed without treating every item as benchmark evidence.
## Where it appears in the product
Use Assets → Cases for the reusable Case collection. Use Sourcing Tasks to inspect find, synthesize, classification, and preparation activity. From selected Cases, use the supported add-to-benchmark action to change editable Benchmark Dataset membership. Use Benchmark Datasets to inspect the selected set and create Snapshots.
## Artifacts it affects
Each Case keeps backend-issued identity, canonical content, materials, source or contributor context, Coverage Facet assignments, and benchmark inclusion where available. Task state is not Case approval, and benchmark inclusion is not Snapshot membership. Preserve those separate states when reporting progress.
## Operational check
Before selecting a Case, inspect its canonical input, required materials, source trace, coverage assignments, and any supported reference output or evaluator relationship relevant to the intended Benchmark. Check for near duplicates and verify that selection closes a named need rather than merely increasing row count.
Selection is explicit: choose the intended Benchmark in this dialog. The action changes editable dataset membership, not a historical Snapshot.
{% example-demo title="Routing a sourced Case" %}
A sourcing task finds a production-informed question involving a superseded policy attachment. The operator opens the Case in Assets, confirms the current Input Schema and both materials, assigns the source-authority Coverage Facet, and adds it to the support Benchmark's current dataset. The team reviews Representation and creates a new Snapshot later; the selection action alone does not change historical Runs.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Assets](/docs/assets)
- [Importing cases](/docs/operating-manual/import-and-prepare-cases)
- [Synthesize cases](/docs/coverage-engineering/synthesize-cases)
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Product quickstart](/docs/quickstart)
{% /related-card-grid %}
## Source confidence
Code-backed: current Case Pool navigation separates reusable Assets Cases from Sourcing Tasks, while Case sourcing types expose provenance, coverage targets, classification context, and benchmark inclusion. Benchmark Dataset pages own selection and Snapshot evidence.
---
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 %}