---
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.

![Generated Dimension proposal with a definition, proposed ontology values, and separate Accept and Reject actions.](/docs-assets/assets/screenshots/dimension-generation-proposal.png)

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 %}