# Define learning targets from policies and rubrics
Generated: 2026-11-13T08:01:25.856Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: workflow.weights-training.learning-targets
title: Define learning targets from policies and rubrics
summary: Turn an observed behavioral distinction into a specific teaching purpose.
kind: task
product_area: weights_training
status: stable
updated: 2026-11-11
canonical: /docs/weights-training/learning-targets
---
# Define learning targets from policies and rubrics
Turn an observed behavioral distinction into a specific teaching purpose.
## Prerequisites
Reviewed criteria, their applicability, and representative failures or missing behavior.
## Steps
1. Identify the requirement the learner should satisfy and the condition that makes it applicable.
2. Inspect failures and successful neighboring Cases so the objective includes exceptions and protected behavior.
3. Select the intended benchmark criteria and scope in the training preparation.
4. Inspect whether generated examples teach the distinction through their actual targets. Keep protected assessment Cases separate from learner material.
## Object and state changes
Selecting criteria guides the preparation. It does not alter the governed standard or establish that a trained model learned it.
## Success criteria
The team can explain what each example teaches and which independent assessment can test the resulting behavior.
## Common failure modes
Using a broad score as the learning target; copying protected benchmark Cases into the learner dataset.
## Related reference pages
{% related-card-grid title="Continue this workflow" %}
- [Prepare data for weights training](/docs/weights-training)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Resolve a problem" %}
- [Synthetic Cases That Feel Unrealistic](/docs/troubleshooting/unrealistic-synthetic-cases)
- [Unbalanced Coverage](/docs/troubleshooting/unbalanced-coverage)
{% /related-card-grid %}
---
id: assets.weights
title: Prepare data for weights training
summary: Prepare benchmark-guided training data, inspect coverage and splits, download exact packages, and follow training and evaluation results.
kind: reference
product_area: weights_training
status: stable
updated: 2026-11-11
canonical: /docs/weights-training
---
# Prepare data for weights training
A recurring failure can reveal a distinction your model needs to learn: when to ask for clarification, which source controls, or why a plausible alternative is inappropriate. Weights training uses selected Benchmark criteria and coverage to develop material around that learning objective.
Open **Weights training** from the Benchmark workspace to inspect examples, prepare an exact dataset, and connect the work to training and assessment.
## Definition
A preparation records the Benchmark Version, training method, selected scope and generation settings. The workspace has **Overview**, **Dataset**, **Coverage** and **Results**.
Overview summarizes the preparation and prepares the exact dataset download. Dataset exposes examples and splits. Coverage shows representation. Results configures and follows connected training and separately authorized evaluation.
## Fields, states, or lifecycle rules
- Demonstration and preference datasets have different learner targets.
- Examples retain their governing criteria and source context.
- Training, validation and test splits remain distinguishable.
- A download package captures an exact dataset state and export profile.
- A training run records the connection, base model, configuration, provider job and resulting model identity.
- Training completion does not establish benchmark improvement.
## Use the workspace
1. Create a preparation for the intended Benchmark Version and method.
2. Inspect generated examples in Dataset.
3. Check splits and meaningful representation in Coverage.
4. Use **Prepare download** in Overview and inspect the package settings.
5. Download the exact ready package or use Results to configure a connected training service.
6. Launch training deliberately and follow the recorded job.
7. Authorize evaluation separately and inspect the actual resulting responses and judgments.
Download a canonical dataset for use in your training environment, or choose a connected service and a compatible method, model family, and material profile.
## Keep training and evaluation separate
Generation checks describe prepared material. Coverage describes its representation. A provider completion identifies a training output. Held-out evaluation measures that output through its supported inference path. None substitutes for the others.
Keep test records out of training and provider validation uploads. Preserve exact package and model identities when comparing results with an ordinary Harness evaluation.
## Choose your next task
| Guide | What you can accomplish |
| --- | --- |
| [Choose between SFT and DPO](/docs/weights-training/choose-method) | Choose the learner target that fits the distinction you want the model to learn. |
| [Define learning targets from policies and rubrics](/docs/weights-training/learning-targets) | Turn an observed behavioral distinction into a specific teaching purpose. |
| [Synthesize training examples with Lemon Weave](/docs/weights-training/synthesize-examples) | Expand reviewed expert standards into examples with a concrete teaching purpose. |
| [Inspect dataset quality and coverage](/docs/weights-training/datasets) | Inspect generated training examples, preserve related families across splits, and assess representation from captured project facets. |
| [Separate training, validation, and test data](/docs/weights-training/splits) | Keep related examples and protected assessment material from crossing the learner’s evaluation boundary. |
| [Export training packages](/docs/weights-training/exports-and-training) | Prepare an exact training package, launch an authorized provider job, and inspect a separately authorized held-out evaluation. |
| [Assess trained candidates against an independent benchmark](/docs/weights-training/independent-assessment) | Measure actual trained-model behavior separately from generation checks and provider job status. |
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Training Datasets and Coverage](/docs/weights-training/datasets)
- [Export, Train, and Evaluate](/docs/weights-training/exports-and-training)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Evaluation Results](/docs/benchmark-evaluations/results)
{% /related-card-grid %}
---
id: troubleshooting.unrealistic-synthetic-cases
title: Synthetic Cases That Feel Unrealistic
summary: Improve generated candidates whose surface details or behavior assumptions do not represent plausible target-system use.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-11-06
canonical: /docs/troubleshooting/unrealistic-synthetic-cases
---
# Synthetic Cases That Feel Unrealistic
## Symptoms
- Generated language sounds artificial or describes a user who would not exist in the product.
- Required context appears conveniently in the prompt even though the real system would retrieve it elsewhere.
- The Case combines incompatible ontology values or violates product constraints.
- Reviewers can identify the intended coverage tuple but would never admit the Case to a Benchmark.
- Many generated candidates repeat the same template with superficial wording changes.
## Likely causes
- The synthesis request lacks representative source Cases or product constraints.
- A coverage tuple combines values that cannot coexist in the target system.
- A Scenario or tuple is too broad, stale, or inconsistent with the target system.
- Generated candidates are being treated as reviewed Benchmark Cases before admission.
## Diagnose the generation boundary
1. Open the intended Benchmark's **Coverage Design → Canvas** and identify the coverage slice used for Case preparation. Use **Assets → Cases** to import real examples or create a reusable Case manually.
2. Compare the generated Case with real in-use Cases from the same behavior region.
3. Separate a bad surface realization from a bad coverage target. Awkward wording may need editing; an impossible product state requires revised Scenario or tuple context.
4. Check whether the generator lacked constraints that operators hold only in private memory.
5. Inspect the synthesis lifecycle and candidate state. A completed generation is still candidate material, not a selected Benchmark Case.
## Fix
- Add representative source Cases or explicit product constraints to the synthesis context.
- Refine the Scenario or tuple when its construction guidance combines incompatible conditions. Keep response-alternative guidance in Comparison Directions.
- Generate from a specific missing coverage tuple rather than asking for generic diversity.
- Edit a promising candidate when its behavioral boundary is sound and only presentation is weak.
- Reject candidates whose premise is impossible or whose source context cannot be justified.
- Review duplicates before adding any generated Case to a Benchmark.
Validate revised candidates with an expert who knows the target workflow. Ask whether the situation could occur, whether the system would receive the shown context, and whether the requested judgment matters. Only then classify and curate the Case for possible benchmark use.
## Prevention
Ground synthesis in reviewed source Cases, explicit product constraints, and a named coverage gap. Review the Scenario and tuple, inspect duplicates, and require Case review before adding generated candidates to a Benchmark or Snapshot.
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Synthesize Cases](/docs/coverage-engineering/synthesize-cases)
- [Scenarios](/docs/coverage-engineering/scenarios)
- [Boundary Cases](/docs/coverage-engineering/boundary-cases)
- [Case Pool](/docs/coverage-engineering/case-pool)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference" %}
- [Case Pool surface](/docs/object-model/case-pool)
- [Cases](/docs/object-model/cases)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
{% /related-card-grid %}
---
id: troubleshooting.unbalanced-coverage
title: Unbalanced Coverage
summary: Fix benchmarks that overrepresent easy or common cases while missing important behavior.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-11-06
canonical: /docs/troubleshooting/unbalanced-coverage
---
# Unbalanced Coverage
Use this when the Benchmark Dataset overrepresents some behavior and misses other behavior that matters before human review.
## Symptom
A benchmark looks strong in aggregate but reviewers or product owners identify important behavior areas with too few cases. Results may be dominated by common easy cases while rare or boundary cases are absent.
## Likely causes
- Case import mirrored production volume instead of product risk.
- Dimensions or metadata do not represent the behavior areas that matter.
- Synthetic cases were added in one area but not reviewed across the full risk boundary.
- Coverage was not refreshed after new signals, policy changes, or failures.
## Diagnostic checks
- Inspect **Benchmark Datasets → Representation** and the Coverage Design overview by the configured Coverage Facets.
- Look for policies or rubrics with very few applicable cases.
- Compare production or expert signals with benchmark case distribution.
- Inspect whether new cases are candidate-only or actually in use.
## Fix
- Add representative, boundary, or adversarial cases for undercovered areas.
- Refresh dimensions or metadata before judging balance.
- Review and promote candidate cases into the benchmark only after context is complete.
- Record remaining gaps as Coverage Stories or explicit benchmark coverage guidance.
## Prevention
- Define coverage targets before benchmark runs.
- Track candidate and in-use cases separately.
- Review coverage after policy, rubric, or product behavior changes.
- Do not use aggregate scores without a coverage note.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Dataset Representation](/docs/benchmark-datasets/representation)
- [Coverage Design Settings](/docs/coverage-design/settings)
- [Coverage Stories](/docs/coverage-design/coverage-stories)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Case Pool surface](/docs/object-model/case-pool)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Benchmarks](/docs/object-model/benchmarks)
{% /related-card-grid %}