# Stale Dimensions
Generated: 2026-09-13T04:39:37.435Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: troubleshooting.stale-dimensions
title: Stale Dimensions
summary: Refresh Dimensions and ontology values that no longer explain the current behavior space without rewriting historical evidence.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-09-07
canonical: /docs/troubleshooting/stale-dimensions
---
# Stale Dimensions
## Symptoms
- New Cases repeatedly fall into **other**, unknown, or no value.
- An ontology value refers to a product state or source hierarchy that no longer exists.
- Important failures concentrate in metadata that no Dimension represents.
- A coverage plan looks balanced under old labels but reviewers describe a new boundary.
- Two values have become indistinguishable after a product change.
## Likely causes
- Product behavior or source authority changed while the coverage vocabulary did not.
- New Cases reveal an axis the existing schema never represented.
- Ontology values were renamed or repurposed without reviewing old classifications.
- The apparent staleness is actually incomplete Case classification.
## Confirm staleness
First distinguish a stale schema from incomplete classification. Sample new and old Cases using the current Dimension definition. If the existing values still describe the behavior and only new Cases are unlabeled, repair classification. If reviewers need a new concept, different source authority, or changed applicability to classify consistently, the Dimension or ontology may be stale.
## Fix
1. Record the change that made the current vocabulary inadequate.
2. Inspect the Dimension definition, values, examples, origin, and where it is used in coverage plans.
3. Decide whether to rename a value, add a value, split the Dimension, replace it, or preserve it with a historical time boundary.
4. Review representative Cases against the proposed schema before broad reclassification.
5. Reclassify affected current Cases and inspect whether coverage gaps or target distributions changed.
6. Update **Coverage Management → Get Started** and the overview deliberately. Do not change selected Dataset membership merely to preserve an old-looking distribution.
7. Create a new Snapshot when the classification or selected evidence boundary used by the Benchmark changes.
Historical Snapshots and Runs should retain their original interpretation. A new Dimension schema can supersede the current planning model without making the old model disappear.
## Prevention
Review Dimension definitions alongside product and source changes, keep representative examples for each ontology value, and inspect unclassified or catch-all Cases regularly. Name the schema and Snapshot boundary used when segment results inform a decision.
{% example-demo title="Example: channel labels stop explaining escalation risk" %}
A support Benchmark classifies Cases only by email and chat. After voice transcripts arrive, experts find that synchronous versus asynchronous interaction—not channel name—explains escalation behavior. The team creates a clearer interaction-mode Dimension, samples old and new Cases, updates Coverage Management, and creates a new Snapshot. Older results remain labeled under the prior schema.
{% /example-demo %}
## Source confidence
Code-backed: Dimension types, Dimensions and Ontology, Coverage Management, and Get Started show the editable vocabulary and its use in benchmark planning. The product does not automatically prove conceptual staleness; the trigger comes from changed evidence and reviewer interpretation.
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Refresh coverage after product change](/docs/coverage-engineering/coverage-refresh)
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Detect and route stale evidence](/docs/governance/staleness-detection)
- [Dimension classification troubleshooting](/docs/troubleshooting/dimension-classification)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference" %}
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Ontology](/docs/object-model/ontology)
- [Versions, staleness, and resolution](/docs/object-model/versions-staleness-and-resolution)
{% /related-card-grid %}
---
id: coverage.refresh
title: Refresh coverage after product change
summary: Reconcile coverage facets, Cases, benchmark membership, and Snapshots after the target system or its evidence changes.
kind: task
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/coverage-refresh
---
# Refresh coverage after product change
## When to use it
Refresh coverage when new Cases reveal an unrepresented behavior, source material or product behavior changes, experts qualify an earlier assumption, or a governed Policy changes which situations matter. This is a coordinated workflow across Coverage Engineering—not a single refresh action.
## Prerequisites
- Name the changed signal and the date or version at which it changed.
- Identify the Benchmark whose claims may be affected.
- Preserve the current Snapshot and historical Runs; do not edit them to resemble the new state.
- Decide who can confirm the changed behavior and who owns the resulting Benchmark Version.
### Task steps: Refresh benchmark coverage
1. Open the Benchmark's **Coverage Management** overview and identify which coverage claim is no longer supported.
2. Review **Coverage Facets**. Update Dimensions, ontology values, Project Topics, or Case Construction Patterns only when the behavior model itself changed.
3. Return to the **Case Pool**. Source, upload, draft, or synthesize candidate Cases for the missing or changed region.
4. Inspect the candidates for source context, realistic inputs, duplication, and the intended coverage labels. Keep uncertain Cases out of benchmark use.
5. Use **Coverage Management → Get Started** and the overview to update coverage guidance. Use **Case Review** and **Benchmark Datasets** to change selected Cases deliberately.
6. Create a new Dataset Snapshot and Benchmark Version for the revised evidence boundary.
7. Run a new evaluation when current candidate evidence is required. Compare it with older Runs using the named Benchmark Versions.
## Object and state changes
A refresh may change coverage-facet definitions, Case classifications, candidate Cases, selected benchmark Cases, and the next Snapshot. It does not rewrite an earlier Snapshot or make its Runs invalid. Older results remain evidence for their original version; the new version answers the current coverage question.
If only candidate behavior changed, keep the Benchmark Version fixed and run the new candidate against it. If the Case set, applicable standards, or coverage boundary changed, create a new Benchmark Version before interpreting a new Run as comparable.
## Success criteria
- The changed product reality maps to an explicit coverage facet or documented boundary.
- Candidate Cases have enough source context to be reviewed and are not mistaken for in-use benchmark evidence.
- The new selected set addresses the gap without silently removing still-important behavior.
- The new Snapshot names a reproducible evidence boundary.
- Comparisons distinguish candidate changes from Benchmark Version changes.
## Common failure modes
- Treating refresh as a single button and missing a changed facet, Case set, or Snapshot boundary.
- Rewriting a historical Snapshot instead of creating a new one.
- Adding generated or newly sourced Cases to a Benchmark before review.
- Comparing Runs without naming whether the candidate, Benchmark Version, or both changed.
{% example-demo title="A newly supported exception" %}
A support assistant gains an approved exception path for one account tier. The team adds or revises the account-tier ontology, sources Cases for eligible and ineligible requests, reviews them in Case Review, updates the coverage guidance, and changes the selected Benchmark Dataset. A new Snapshot freezes the revised membership. Previous Runs still describe the old rule; new Runs evaluate the approved exception boundary.
{% /example-demo %}
## Source confidence
Code-backed: Coverage Management, Coverage Facets, the Case Pool, Case Review, Benchmark Datasets, and Dataset Snapshots establish the current sequence and the objects that can change. The decision that a product change requires a refresh remains a team-owned interpretation of evidence.
## Related reference pages
{% related-card-grid title="Continue the workflow" %}
- [Coverage gaps](/docs/coverage-engineering/coverage-gaps)
- [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
- [Case Pool](/docs/coverage-engineering/case-pool)
- [Plan benchmark coverage](/docs/coverage-engineering/plan-benchmark-coverage)
- [Benchmark Snapshots](/docs/coverage-engineering/benchmark-snapshots)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Diagnose refresh problems" %}
- [Stale Dimensions](/docs/troubleshooting/stale-dimensions)
- [Unbalanced coverage](/docs/troubleshooting/unbalanced-coverage)
- [Synthetic Cases That Feel Unrealistic](/docs/troubleshooting/unrealistic-synthetic-cases)
{% /related-card-grid %}
---
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: governance.staleness-detection
title: Detect and route stale correctness evidence
summary: Identify which current claims need review after Cases, standards, coverage, sources, or target behavior change.
kind: task
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/staleness-detection
---
# Detect and route stale correctness evidence
## What staleness means
Staleness means a downstream claim may no longer be supported by the current upstream state. It is a review signal, not automatic deletion and not a claim that historical evidence was invalid when produced.
Teammately objects change independently. A revised Policy may affect linked Rubrics and current benchmark interpretation without changing the exact evidence captured in an earlier Snapshot. A changed Harness may require a new Run while leaving the Benchmark Version unchanged.
## Common triggers
- A Case input, context, source attachment, or supported reference output changes.
- A Policy rule, scope, approval, or applicable boundary changes.
- A Rubric criterion or link changes.
- Coverage facets or selected Case membership change.
- A source becomes superseded or the target product changes.
- A saved Harness version changes before candidate comparison.
## Prerequisites
- The changed object and its earlier and current versions can be identified.
- The team can trace current downstream artifacts that rely on the changed fact.
- An owner can decide whether current evidence needs qualification, replacement, or no action.
### Task steps: Assess and route staleness
1. Name the changed object, its earlier and current versions, and the reason for change.
2. Identify downstream artifacts that rely on the changed fact: linked standards, selected Cases, Snapshots, Runs, comparisons, or customer-owned human review context.
3. Classify each artifact as historically valid, current and unaffected, current but requiring qualification, or requiring replacement.
4. Route the correction to the owning workflow: edit a Case, govern a new Policy or Rubric version, refresh coverage, create a Snapshot, or run a saved Harness again.
5. Preserve the old version and its evidence. Add a note that states which boundary the evidence still supports.
6. Confirm that current navigation and handoff material point to the new canonical version.
## Object and state changes
A changed object does not make every connected artifact unusable. If a Policy wording change does not affect a particular Case or Rubric, document that determination. If a candidate configuration changes, create a new Run rather than a new Benchmark Version. If selected membership changes, create a new Snapshot rather than editing an old one.
Comparison Directions have a narrower advisory state. **Potentially stale** applies to untouched AI-suggested directions considered inconsistent with newer project context. It does not automatically apply to user-created or user-edited directions, and dismissing the label does not delete the direction or govern any downstream artifact.
## Success criteria
- The trigger and affected version boundaries are named.
- Historical evidence remains interpretable under its original boundary.
- Current artifacts are explicitly unaffected, qualified, or routed to the owning workflow.
- New Snapshots or Runs are created only when their respective evidence boundary changed.
## Common failure modes
- Treating every connected artifact as invalid after one upstream change.
- Editing a historical Snapshot or Run to resemble current state.
- Creating a new Benchmark Version when only the Harness changed.
- Confusing the advisory Comparison Direction label with governed-object staleness.
{% example-demo title="Source document superseded" %}
A new service policy supersedes the source used by twelve refund Cases. The operator preserves the old Snapshot and its Runs, updates affected current Cases, checks the linked Policy and Rubrics, and creates a new Snapshot. Two Cases describe historical behavior and remain unchanged with an explicit time boundary; ten move to the current version.
{% /example-demo %}
## Source confidence
Code-backed: Policy and Rubric types, Benchmark Version and Snapshot surfaces, and Run detail preserve the version boundaries needed for this assessment. Comparison Directions explicitly expose their narrower advisory stale label. Cross-object dependency assessment and the decision to rerun or revise remain owner-reviewed work.
## Related reference pages
{% related-card-grid title="Related workflows" %}
- [Versioning and Staleness](/docs/governance/versioning-and-staleness)
- [Coverage Refresh](/docs/coverage-engineering/coverage-refresh)
- [Benchmark Versioning](/docs/governance/benchmark-versioning)
- [Comparison Directions](/docs/assets/comparison-directions)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Diagnose stale evidence" %}
- [Stale Dimensions](/docs/troubleshooting/stale-dimensions)
- [Benchmark results changed unexpectedly](/docs/troubleshooting/benchmark-results-changed-unexpectedly)
- [Weak applicability logic](/docs/troubleshooting/weak-applicability-logic)
{% /related-card-grid %}