# Dimensions and ontology
Generated: 2026-09-13T04:42:55.434Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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: 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: coverage.generate-dimension-schema
title: Generate a dimension schema
summary: Ask Teammately for coverage-dimension proposals, then accept only the dimensions and ontology values that describe meaningful behavior.
kind: task
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/generate-dimension-schema
---
# Generate a dimension schema
## When generation helps
Generate ideas when a project has enough Cases or product context to reveal recurring differences, but the team has not yet named the axes needed for coverage planning. Generation is useful for discovery and vocabulary. It does not prove that a proposed dimension is complete, mutually exclusive, or appropriate for benchmark governance.
## Prerequisites
State the target behavior, what the existing Case set fails to distinguish, and any constraints the proposal must preserve. A prompt such as “separate refund requests by source authority and exception eligibility” produces a more reviewable proposal than “make better dimensions.”
### Task steps: Generate and review dimension ideas
1. Open **Coverage Engineering → Coverage Facets → Dimensions and Ontology**.
2. Start **Generate dimension idea**.
3. Add context describing the behavior boundary, important Cases, and the decision the dimension should support.
4. Generate the proposal and read its dimension name, definition, proposed ontology members, why-it-matters note, and review warnings.
5. Compare it with current Dimensions and ontology values for overlap, ambiguous labels, and gaps.
6. Accept only proposals the team can classify consistently. Reject unsuitable proposals or regenerate with narrower context.
7. Inspect the accepted Dimension, refine its definition if necessary, and sample real Cases before using it in coverage plans.
## Object and state changes
The proposal timeline preserves generated attempts and decisions. Each proposed Dimension can be accepted or rejected independently. Acceptance creates product state; it does not automatically classify every Case, revise a Benchmark, or approve generated Cases.
Review the Dimension definition and every proposed ontology value before accepting the proposal.
Project-context refreshes may produce updated recommendations and explain which context changes were considered. Treat those as review cues. A changed proposal is not evidence that the existing schema is wrong.
## Success criteria
- Does the Dimension represent one behavior axis rather than several bundled concerns?
- Are ontology values distinct enough that two reviewers would usually classify the same Case alike?
- Is there a clear treatment for unknown, conflicting, or not-applicable cases?
- Does it add information beyond existing Dimensions, Project Topics, or Case Construction Patterns?
- Will the classification support an actual coverage or evaluation decision?
## Common failure modes
- Supplying generic instructions that produce broad, overlapping Dimensions.
- Accepting a fluent proposal without comparing it with existing coverage facets.
- Treating acceptance as automatic Case classification or Benchmark approval.
- Using ontology values that reviewers cannot distinguish on real boundary Cases.
{% example-demo title="Source-authority dimension" %}
The team asks for a dimension that separates how an assistant handles conflicting product sources. Teammately proposes **Source authority** with values for canonical source, secondary source, conflicting sources, and unavailable source, plus a warning that “secondary” needs a project-specific definition. The team defines that boundary, samples Cases, and accepts the proposal. Classification and benchmark selection remain separate work.
{% /example-demo %}
## Source confidence
Code-backed: the Dimensions and Ontology route and generation components expose proposal instructions, a timeline, per-Dimension acceptance or rejection, definitions, ontology members, rationale, and review warnings. Consistency and fitness for a project remain human review decisions.
## Related reference pages
{% related-card-grid title="Continue the workflow" %}
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Dimension classification troubleshooting](/docs/troubleshooting/dimension-classification)
- [Coverage gaps](/docs/coverage-engineering/coverage-gaps)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Diagnose Dimension problems" %}
- [Dimension classification troubleshooting](/docs/troubleshooting/dimension-classification)
- [Stale Dimensions](/docs/troubleshooting/stale-dimensions)
- [Unbalanced coverage](/docs/troubleshooting/unbalanced-coverage)
{% /related-card-grid %}
---
id: troubleshooting.dimension-classification
title: Dimension classification troubleshooting
summary: Resolve missing, ambiguous, or inconsistent Case classifications before they distort coverage analysis.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-09-07
canonical: /docs/troubleshooting/dimension-classification
---
# Dimension classification troubleshooting
## Symptoms
- Many Cases show no value for an important Dimension.
- Similar Cases receive different ontology values without a clear reason.
- One Case appears to belong to several mutually exclusive values.
- A coverage gap disappears or appears after labels change, although the Case set did not.
- Reviewers cannot tell whether **unknown**, **not applicable**, and missing classification mean different things.
## Likely causes
- The Dimension definition or ontology values overlap.
- Required Case context is absent from the classification view.
- The schema changed after existing Cases were classified.
- The Dimension bundles independent behavior axes or leaves absence undefined.
## Diagnose the schema before the Cases
1. Open the Dimension and read its definition, ontology values, examples, and origin.
2. Decide whether the values are intended to be mutually exclusive, multi-label, ordered, or merely descriptive. Do not infer this from label names alone.
3. Sample Cases from each value plus unclassified Cases. Compare the full Case context, not only the short input shown in a table.
4. Look for overlapping definitions, missing fallback treatment, context fields unavailable to classification, or a Dimension that bundles more than one behavior axis.
5. Check whether the Dimension or ontology changed after the Cases were classified.
## Fix
- Correct an individual Case classification when the schema is clear and the Case was mislabeled.
- Improve the Dimension definition or ontology descriptions when reviewers interpret them differently.
- Split a Dimension when one label depends on two independent behavior axes.
- Add an explicit unknown or not-applicable treatment when absence carries meaning.
- Reclassify affected Cases after a schema change, then review coverage plans and Snapshot boundaries before relying on segment results.
Do not repair a misleading coverage chart by editing counts or selecting convenient Cases. Correct the Dimension or classification state that produced it.
## Prevention
Define the classification rule and unknown treatment before broad use, attach representative examples to each value, and test boundary Cases with more than one informed reviewer. Review affected classifications whenever the Dimension schema changes.
## Verification
Have two informed reviewers classify a small boundary sample using only documented context. Agreement is evidence that the schema is usable; disagreement should produce a clearer definition, better context, or an explicit unresolved boundary—not forced consensus.
{% example-demo title="Example: overlapping source-support values" %}
Cases alternate between **implied support** and **conflicting source** because one document implies compatibility while another denies it. The team clarifies that any authoritative contradiction uses **conflicting source**, adds examples, and reclassifies the affected Cases. They review the benchmark plan before creating a new Snapshot.
{% /example-demo %}
## Source confidence
Code-backed: Dimension list/detail surfaces, record-table classification utilities, and classification types establish how Dimension values appear on Cases. The product cannot determine whether a Project's vocabulary is conceptually sound without human review.
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Generate a dimension schema](/docs/coverage-engineering/generate-dimension-schema)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Stale Dimensions](/docs/troubleshooting/stale-dimensions)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference" %}
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Ontology](/docs/object-model/ontology)
- [Metadata and context](/docs/reference/metadata-and-context)
{% /related-card-grid %}