# Project Topics
Generated: 2026-09-13T04:36:00.737Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: coverage.project-topics
title: Project Topics
summary: Maintain source-grounded subject areas, editable groups, and Atlas relationships used to organize project and benchmark coverage.
kind: reference
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/project-topics
---
# Project Topics
## Definition
Project Topics are reusable subject areas derived from project knowledge, entered by an administrator, or contributed by an expert. They organize cases by what they are about. Unlike a Dimension, a Project Topic is not one value on a fixed behavior axis: a case can belong to several Topics.
The Project Topics workspace contains **Topics**, **Groups**, and **Atlas**.
## Fields, states, or lifecycle rules
### Topics
Each Topic has a name, description, active state, author type, case usage, benchmark usage, and source mentions where available. Source mentions retain evidence such as the originating Reference Material, Project Agent Brief, manual entry, or expert suggestion.
The Topic detail shows its definition and source grounding, linked and example cases, coverage confidence, nearby-topic signals, coverage by Dimensions and ontology values, and editable membership in Topic Groups.
An AI-created or source-extracted Topic remains an editable project artifact. Review its definition and grounding before using it to steer a benchmark.
### Groups
A Project Topic Group is an editable bundle of Topics. It does not merge or replace its members. Groups let benchmark setup express intent at a useful scale while retaining Topic-level traceability.
In **Get Started**, a Group can be handled as:
- **Cover every topic:** the benchmark should represent each member Topic.
- **Cover the group:** the group should be represented without requiring every member.
- **Use as guidance:** it can guide story construction without becoming a coverage obligation.
- **Do not use:** exclude the Group from this benchmark's setup.
- **Unset:** no explicit instruction.
Groups can start from manual work, AI suggestions, source material, or Atlas exploration. Manual edits remain significant; regenerating a suggestion should not be treated as authority to overwrite the reviewed group.
### Atlas
Atlas visualizes Topics, relationships, and Groups. Use it to inspect neighborhoods, redundancy, missing nearby Topics, and possible groupings. Relationships are analytical evidence, not a taxonomy merge. A close position or strong relation score does not mean two Topics are interchangeable.
The Topic coverage view can distinguish direct case grounding from breadth, Dimension spread, and binding confidence. When a Topic looks thin, inspect the linked cases before generating more. The problem may be missing cases, weak classification, an overly broad definition, or a duplicate Topic.
### Refresh and review
Project Topics can be refreshed from current project context and indexed sources. Refreshing can create or update Topics, source mentions, evidence, and relationship analysis. Review the resulting changes and recommendation runs before incorporating them into Groups or benchmark setup.
{% example-demo title="Example: group without flattening" %}
The project has Topics for Contract renewal, Price adjustment, and Termination notice. An administrator groups them as Agreement lifecycle. One benchmark chooses Cover every topic because each action has distinct risk. Another chooses Use as guidance because it only needs broad agreement-related examples. The individual Topics remain traceable in both benchmarks.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Work with Dimensions and Ontology](/docs/coverage-engineering/dimensions-ontology)
- [Define Case Construction Patterns](/docs/coverage-engineering/case-construction-patterns)
- [Configure benchmark Get Started](/docs/coverage-management/get-started)
- [Analyze dataset representation](/docs/benchmark-datasets/representation)
{% /related-card-grid %}
## Source confidence
Code-backed: the current Topic, Group, source-mention, statistics, relationship, Atlas, suggestion, and benchmark-handling contracts establish this model.
---
id: coverage.overview
title: Coverage Engineering
summary: Design the behavior space a benchmark must represent and connect reusable project facets to benchmark coverage work.
kind: concept
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering
---
# Coverage Engineering
Coverage Engineering is the capability for designing what a specialist AI benchmark must represent. It turns requirements, project knowledge, existing cases, and observed failures into a structured coverage map that guides dataset selection, case construction, expert contributions, and evaluation interpretation.
## Definition
Coverage work has two scopes. At project scope, **Coverage Facets** manages reusable Dimensions, Project Topics, and Case Construction Patterns. At benchmark scope, **Coverage Management** applies those facets to setup, representation, Coverage Stories, Case Review, Case Foundry, and contribution requests. **Benchmark Datasets** owns the selected Cases and snapshots that embody the resulting coverage.
Coverage Engineering is therefore broader than adding cases. It explains why a behavior slice matters, how it is represented, which combinations are thin, and what work should close the gap.
## Decision checkpoint
| Question | Product surface | Durable result |
| --- | --- | --- |
| Which axes distinguish important behavior? | Coverage Facets → Dimensions | Reusable coverage axes |
| Which domain subjects must be represented? | Coverage Facets → Project Topics | Project topic structure |
| How should cases be constructed repeatedly? | Coverage Facets → Case Construction Patterns | Reusable construction guidance |
| What should this benchmark cover? | Coverage Management → Get Started | Benchmark-specific coverage guidance |
| Where is the selected dataset thin? | Representation and Coverage Stories | Named gaps and sourcing work |
| Which exact cases define evidence? | Benchmark Datasets | Selection and snapshot boundary |
## Coverage map and benchmark evidence
A coverage map should identify meaningful combinations rather than isolated tags. A source-freshness Dimension may be well populated overall while the combination of superseded source, high customer impact, and exception request remains absent. Coverage Stories make those combinations operational; Case Foundry and expert contribution requests can then target them.
Representation is evidence about the dataset, not proof that the benchmark is complete. A large or balanced count can still omit a critical boundary. Product teams should use specialist judgment to decide which gaps materially affect trust.
## Relationship to correctness and construction
Correctness Elicitation answers what should count as correct in a represented situation. Weave constructs or imports the cases and materials needed to exercise the situation. If the team cannot judge a coverage slice, request an Expert Contribution. If the judgment is clear but no case exists, use Case Foundry or other case-construction work. If cases exist but are not selected, update Benchmark Datasets.
Comparison Directions are not Coverage Facets. They guide comparative response variation and belong to **Assets → Comparison Directions**. Keep benchmark representation in Dimensions, Topics, Patterns, Stories, and dataset snapshots.
{% example-demo title="Authority-conflict coverage" %}
A project creates source authority and customer impact Dimensions, a Project Topic for eligibility exceptions, and a pattern for pairing current and superseded documents. Coverage Management shows that the high-impact conflict tuple has no selected cases. A Coverage Story justifies the gap, Case Foundry prepares cases, and the accepted cases enter a new dataset snapshot.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Plan benchmark coverage](/docs/coverage-engineering/plan-benchmark-coverage)
- [Manage Coverage](/docs/coverage-management)
- [Work with Benchmark Datasets](/docs/benchmark-datasets)
{% /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)
- [Cases](/docs/assets/cases)
{% /related-card-grid %}
## Source confidence
Code-backed: current navigation and benchmark coverage routes establish project Coverage Facets, benchmark Coverage Management, setup, representation, Stories, Case Review, and Case Foundry responsibilities.
---
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.case-construction-patterns
title: Case Construction Patterns
summary: Define reusable mechanisms for constructing cases and steer how benchmarks use or avoid them.
kind: reference
product_area: coverage_engineering
status: stable
updated: 2026-09-07
canonical: /docs/coverage-engineering/case-construction-patterns
---
# Case Construction Patterns
## Definition
A Case Construction Pattern describes a reusable mechanism for building cases. It answers “how should this situation be constructed?” while Dimensions describe differentiating values and Project Topics describe subject matter.
Examples include conflicting authorities, missing prerequisite evidence, ambiguous user intent, multi-step state change, or a plausible but superseded source. A good Pattern is portable across Topics rather than tied to one case's wording.
## Fields, states, or lifecycle rules
Each Pattern has a name, description, origin, usage counts, examples, and benchmark statistics. Origins currently distinguish manual, AI-generated, expert-input, and imported Patterns. Usage can show Case Pool cases, benchmark cases, requirements, and benchmark steering.
Pattern suggestions can be grounded in Project Topics, source material, existing cases and Patterns, the Project Agent Brief, Dimensions and ontology, or expert input. Generated candidates include the proposed definition, why they were suggested, and source references. Accept or reject each candidate explicitly.
## Benchmark steering
Get Started can use one of three modes:
- **System choose:** allow construction to select appropriate Patterns from the project library.
- **Prefer:** encourage named Patterns when building Coverage Stories and cases.
- **Avoid:** prevent named Patterns from shaping this benchmark's intended case supply.
Coverage Story tuples can also reference specific Patterns. The tuple reference is the concrete construction instruction for that part of the story; the project Pattern remains reusable and independently editable.
## Design rules
- Name the mechanism, not the domain example. “Conflicting authorities” travels better than “Conflicting HR policies.”
- Explain what makes a case instantiate the Pattern.
- Keep Topics out of the Pattern definition unless they are only examples.
- Do not encode an expected answer or rubric verdict as a construction pattern.
- Inspect examples and usage before deleting or materially changing a Pattern.
- Treat AI and expert suggestions as reviewable proposals. Origin is provenance, not approval.
> Pattern versus requirement
>
> A Pattern describes a reusable structure. Benchmark requirements describe constraints for one benchmark, and a Coverage Tuple combines the relevant Dimensions, Topic Groups, Patterns, proof statement, and target case count.
{% example-demo title="Example: portable construction pattern" %}
The project defines **Plausible superseded authority**: construct a case where an older source appears credible but a newer source controls. Coverage Stories reuse the Pattern for procurement, support, and compliance Topics while applying different source-condition and impact ontology values.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Work with Project Topics](/docs/coverage-engineering/project-topics)
- [Configure benchmark Get Started](/docs/coverage-management/get-started)
- [Edit Coverage Stories](/docs/coverage-management/coverage-stories)
- [Review prepared cases](/docs/coverage-management/case-review)
{% /related-card-grid %}
## Source confidence
Code-backed: the current Pattern list, detail, generation, recommendation, usage, examples, classification, and benchmark-steering contracts establish this behavior.
---
id: coverage-management.get-started
title: Set Up Benchmark Coverage
summary: Define benchmark intent, facet handling, artifact preferences, and evidence requirements before generating coverage work.
kind: task
product_area: coverage_management
status: stable
updated: 2026-08-22
canonical: /docs/coverage-management/get-started
---
# Set Up Benchmark Coverage
## Prerequisites
- Project Coverage Facets and Input Schema are available.
- The benchmark intent and evidence risk can be stated concretely.
**Get Started** records the coverage contract that drives Coverage Stories and Case Foundry. Complete it before treating generated coverage work as aligned to the benchmark.
## Define the intent and facet treatment
Describe the benchmark intent and concrete requirements. For each Dimension ontology value, choose the benchmark role required by the setup. Configure Topic Group handling and Case Construction Pattern behavior rather than assuming every active project facet must be represented equally.
Dimension roles, Topic Group handling, and Pattern modes are different controls. A required Dimension value constrains represented behavior. A Topic Group can require every Topic, require group-level coverage, provide guidance, or be excluded. A Pattern can be left to the system, preferred, or avoided. Preserve those distinctions when explaining the resulting coverage plan.
## Define artifact and evidence expectations
For image, document, tabular, presentation, source-text, and audio artifacts, choose **mandatory**, **optional**, or **never**. Set portfolio limits and accepted formats so construction does not create unsupported or gratuitous material.
The evidence profile can specify actor, workflow, grounding, evidence carriers, difficulty, transformation, and data-handling expectations. These fields make a behavior testable. They are not decorative prose: Case Review uses them to judge whether a prepared candidate proves the intended situation.
## Save and check readiness
Setup moves through `draft`, `ready`, `generated`, `changed_since_generation`, and `archived` states. Resolve the readiness guidance before generation. If the setup changes after stories or cases were generated, treat the previous work as based on an older input rather than silently presenting it as current.
A coverage guideline can apply to `foundry_only` or `overall_coverage`. Overall coverage can require provenance backfill for existing Cases. The coverage compiler can preview reconciled revisions, but an operator confirms the durable update.
> Generation boundary
>
> Saving setup does not create trusted Cases or a Dataset Snapshot. It defines the instructions and evidence profile for downstream story and case work.
## Object and state changes
Saving creates or revises benchmark-scoped coverage setup and its readiness status. Generation records which setup revision it used. Archiving stops the setup from acting as the current contract without erasing history.
## Success criteria
- Intent, requirements, facet treatment, artifacts, and evidence profile agree.
- Readiness is explicit and downstream generation can identify the exact setup.
- Overall-coverage provenance needs are handled deliberately.
## Common failure modes
- Requiring every active facet without regard to benchmark intent.
- Marking unsupported artifacts mandatory.
- Editing setup after generation and ignoring the stale result.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Coverage Management](/docs/coverage-management)
- [Project Input Schema](/docs/project-settings/input-schema)
- [Coverage Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Unbalanced coverage](/docs/troubleshooting/unbalanced-coverage)
- [Unrealistic synthetic Cases](/docs/troubleshooting/unrealistic-synthetic-cases)
{% /related-card-grid %}
## Source confidence
Code-backed: the active setup page, types, readiness rules, and save states define the benchmark-scoped coverage contract and its lifecycle.