# Coverage dimensions
Generated: 2026-09-13T04:33:48.239Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: object-model.coverage-dimensions
title: Coverage dimensions
summary: Organize cases by the behavior axes that matter to product correctness.
kind: reference
product_area: object_model
status: stable
updated: 2026-09-07
canonical: /docs/object-model/coverage-dimensions
---
# Coverage dimensions
## Definition
Coverage dimensions are the axes used to explain what behavior space a case set represents. A dimension can describe source freshness, request type, risk level, product area, policy boundary, or another classification that matters for review and benchmark interpretation.
Use this reference when a benchmark score is not enough and the team needs to ask which kinds of behavior are represented or missing.
## Fields, states, or lifecycle rules
- Dimensions should describe meaningful behavior axes, not arbitrary tags.
- Ontology values should keep each dimension's labels consistent enough for coverage planning.
- Coverage dimensions can reveal untested segments even when aggregate benchmark scores look strong.
- Changing a dimension schema can change how old benchmark evidence is interpreted.
- This page describes object semantics, not a public schema contract.
## Related objects
Coverage dimensions should be read with [Ontology](/docs/object-model/ontology), [Case pool](/docs/object-model/case-pool), [Benchmarks](/docs/object-model/benchmarks), and [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology).
{% example-demo title="Coverage dimensions boundary" %}
Dimension: Source support level.
Ontology values: Explicit support, implied support, conflicting source, no source.
Interpretation: A compatibility benchmark can show whether failures concentrate in cases where the source does not explicitly support the claim.
{% /example-demo %}
## Source confidence
Code-backed: Dimension and classification types plus the Dimensions and Ontology list and detail routes establish Dimensions, ontology values, origin, examples, and Case classification. Whether a Dimension is meaningful or complete remains a coverage-design judgment.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Dimensions and ontology](/docs/concepts/dimensions-and-ontology)
- [Ontology](/docs/object-model/ontology)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
---
id: coverage.dimensions-ontology
title: Dimensions and Ontology
summary: Define reusable behavior axes and their allowed values, then inspect how cases and benchmarks cover them.
kind: reference
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/dimensions-ontology
---
# Dimensions and Ontology
## Definition
Dimensions are reusable project-level axes for describing how cases differ. Each Dimension contains ontology values: the named members used to classify cases and measure representation. A Dimension might be **Source condition**, with values such as **Current**, **Superseded**, **Conflicting**, and **Missing**.
Use **Project Foundations → Coverage Facets → Dimension** to create, generate, inspect, and maintain them.
## Fields, states, or lifecycle rules
### What a Dimension contains
| Element | Purpose |
| --- | --- |
| Name and description | Explain the behavior axis and its boundary |
| Ontology values | Define the values used for classification |
| Examples | Show classified cases and the reason for a value assignment |
| Statistics | Show case-pool and benchmark distribution by ontology value |
| Benchmark focus | Show whether values are required, sampled, diagnostic, or ignored in benchmark setup |
Dimensions and ontology values are project foundations. A benchmark does not copy them. **Get Started** assigns benchmark-specific roles to the project values, and **Representation** reports how the selected cases cover them.
Use the table to compare each Dimension's definition with its ontology and current classification footprint before opening the detail view.
### Create or generate a schema
Create a Dimension manually when the axis and vocabulary are already understood. Use the dimension-schema generator when project context or source material should produce a reviewable proposal. Generated proposals can include a definition, why the Dimension matters, proposed ontology members, and warnings.
A proposal is not the active schema. Review each proposed Dimension and value before accepting it. Avoid accepting near-duplicates simply because they use different wording.
> Classification boundary
>
> Creating or editing a Dimension does not instantly classify every existing case. Missing or stale classifications can be queued and monitored separately. Treat unclassified cases as missing evidence, not as an implicit ontology value.
### Design rules
- Make the Dimension answer one stable question. Split axes that mix several independent concerns.
- Give every ontology value a definition that distinguishes it from neighboring values.
- Prefer values that can be applied consistently to real cases.
- Do not use a Dimension to encode case quality, policy approval, or a desired model score.
- Review distributions after changing values. A clean schema can still leave important cases unclassified.
- Delete only after checking Case Pool and benchmark usage; removal changes the project coverage vocabulary.
### Benchmark roles
In benchmark Get Started, each Dimension and ontology value can receive a focus role:
- **Required:** the benchmark is expected to cover this value.
- **Sampled:** include it as part of the desired mix.
- **Diagnostic:** track it for analysis without making it part of the main denominator.
- **Ignored:** exclude it from the benchmark coverage intention.
- **Unset:** no explicit benchmark instruction has been recorded.
Those roles shape Coverage Story generation and interpretation. They do not alter the project-level definition of the value.
{% example-demo title="Example: source condition" %}
The project defines a Source condition Dimension with Current, Superseded, Conflicting, and Missing values. One benchmark marks all four as required; another marks Current as required and the remaining values as diagnostic. The same project vocabulary supports different benchmark intentions without duplicating the Dimension.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Generate a dimension schema](/docs/coverage-engineering/generate-dimension-schema)
- [Work with Project Topics](/docs/coverage-engineering/project-topics)
- [Plan Benchmark Coverage](/docs/coverage-engineering/plan-benchmark-coverage)
- [Analyze dataset representation](/docs/benchmark-datasets/representation)
{% /related-card-grid %}
## Source confidence
Code-backed: the current Dimension list, detail, settings, proposal, classification, examples, and statistics surfaces establish these fields and lifecycle boundaries.
---
id: concepts.dimensions-ontology
title: Dimensions and ontology
summary: Learn how dimensions and ontology values define the coverage space for a Teammately project.
kind: concept
product_area: object_model
status: stable
updated: 2026-09-07
canonical: /docs/concepts/dimensions-and-ontology
---
# Dimensions and ontology
## Definition
Dimensions and ontology describe how Teammately classifies cases into behavior segments that humans can reason about. Dimensions name the axes that matter, while ontology values provide the controlled labels used for coverage planning, case review, and result analysis.
## Why it matters
This matters because aggregate benchmark results can hide an unsafe gap. A candidate may pass common cases while missing a stale-source segment, a boundary condition, a product tier, or a policy exception that reviewers care about.
## Coverage vocabulary check
| Good coverage vocabulary does... | Weak vocabulary does... |
| --- | --- |
| Names behavior slices that change judgment or risk. | Uses labels that only describe where the case came from. |
| Keeps ontology values consistent enough for comparison. | Lets free-form tags drift until segment results are meaningless. |
| Makes missing or thin segments visible before review. | Treats a large case count as representative coverage. |
## Where it appears in the product
Create and maintain Dimensions and ontology values under **Coverage Facets → Dimensions and Ontology**. Benchmark Datasets uses them to inspect representation, while Benchmark Evaluations can group existing evidence by supported Coverage Facets. The Case Pool and Case Review surfaces use the same vocabulary when classifying and preparing Cases.
## Artifacts it affects
Dimensions affect Case classification, Benchmark Dataset representation, Coverage Stories, synthesis targets, Case Review, and result grouping. Changing the current vocabulary does not rewrite the labels or interpretation of historical Snapshots and Runs.
{% example-demo title="Stale-source segment" %}
An enterprise-search team adds a **Source freshness** Dimension with current, superseded, and unknown values. Benchmark Datasets then reveals that superseded-source Cases are thinly represented. The team prepares additional Cases, reviews their classifications, and creates a new Snapshot before using that segment in evaluation interpretation.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Generate a dimension schema](/docs/coverage-engineering/generate-dimension-schema)
- [Inspect Dataset representation](/docs/benchmark-datasets/representation)
- [Review prepared Cases](/docs/coverage-management/case-review)
- [Diagnose classification](/docs/troubleshooting/dimension-classification)
- [Refresh changed coverage](/docs/coverage-engineering/coverage-refresh)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Coverage Dimensions](/docs/object-model/coverage-dimensions)
- [Ontology](/docs/object-model/ontology)
- [Project Topics](/docs/coverage-engineering/project-topics)
- [Case Construction Patterns](/docs/coverage-engineering/case-construction-patterns)
{% /related-card-grid %}
## Source confidence
Code-backed: Dimension types and the Dimensions and Ontology surfaces define the project vocabulary and editable fields; Benchmark Dataset Representation shows how that vocabulary is used to inspect selected Cases.
---
id: object-model.ontology
title: Ontology
summary: Use ontology values to classify cases consistently within each coverage dimension.
kind: reference
product_area: object_model
status: stable
updated: 2026-09-07
canonical: /docs/object-model/ontology
---
# Ontology
## Definition
Ontology values are the controlled labels used inside a coverage dimension. They keep case classification consistent enough for teams to plan coverage, compare benchmark segments, and explain gaps.
Use this reference when free-form tags are making coverage hard to read or when a benchmark segment needs stable vocabulary before results are trusted. Ontology values remain project-scoped foundations.
## Fields, states, or lifecycle rules
- Ontology values belong to dimensions; they should not drift into unrelated free-form tags.
- Values should be specific enough to separate meaningful behavior, but not so narrow that coverage becomes fragmented.
- Changing ontology values can change segment-level benchmark interpretation.
- Ontology should support coverage decisions, not replace expert judgment or policies.
- This page does not define a public taxonomy API.
## Related objects
Ontology should be read with [Coverage dimensions](/docs/object-model/coverage-dimensions), [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology), and [Generate a dimension schema](/docs/coverage-engineering/generate-dimension-schema).
{% example-demo title="Ontology boundary" %}
Dimension: Source support level.
Ontology values: Explicit support, implied support, conflicting source, no source.
Interpretation: Segment results are easier to trust because the team knows which support condition each case represents.
{% /example-demo %}
## Source confidence
Code-backed: Dimension types and the Dimension settings, ontology-row, and proposal components establish ontology members as labels owned by a Dimension and used for classification. Vocabulary quality and cross-reviewer consistency require project review.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Generate a dimension schema](/docs/coverage-engineering/generate-dimension-schema)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}