# Ontology
Generated: 2026-09-13T04:36:40.038Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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 %}
---
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: 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.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 %}