# Personas
Generated: 2026-11-02T05:43:46.711Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: assets.personas
title: Personas
summary: Find the Personas entry for reusable simulated participants and keep it distinct from Scenarios, Worlds, and expert identities.
kind: reference
product_area: assets
status: stable
updated: 2026-10-30
canonical: /docs/assets/personas
---
# Personas
## Definition
Personas is under **Assets → Personas** and displays **Early reviewers only**. Its intended role is reusable simulated participants in Trialground.
## Fields, states, or lifecycle rules
The current entry does not define a Persona profile schema, authoring workflow, Case relationship or execution contract. Do not use a guessed fixed-field profile as an accepted product schema.
## Keep identities distinct
A Persona is not a Scenario. Scenarios describe reusable situations for constructing Cases. A Persona is also different from a World source snapshot, an execution instance or a real expert assigned to a Contribution.
Use existing Cases and Harnesses for their supported workflows. Do not invent Persona IDs or treat a simulated participant as an authenticated reviewer.
Representation, authoring, Case relationships and runtime behavior are defined together when Persona functionality is implemented.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Assets](/docs/assets)
- [Worlds](/docs/assets/worlds)
- [Scenarios](/docs/coverage-engineering/scenarios)
- [Trialground](/docs/concepts/trialground)
{% /related-card-grid %}
---
id: assets.overview
title: Assets
summary: Reuse project Cases, Worlds, Personas, Harnesses, Comparison Directions, and Review Screens across benchmark work.
kind: concept
product_area: assets
status: stable
updated: 2026-10-30
canonical: /docs/assets
---
# Assets
Assets holds reusable project objects selected by benchmark and expert workflows. Current categories are **Cases**, **Worlds**, **Personas**, **Harnesses**, **Comparison Directions** and **Review Screens**.
## Definition
Cases describe the situations to judge. Harnesses contain executable candidate logic and declared dependencies. Comparison Directions guide useful response alternatives, and Review Screens control expert presentation.
Worlds describes immutable source snapshots and their separate execution context. Worlds and Personas display **Early reviewers only**. Personas is intended for reusable simulated participants in Trialground; its representation and execution contract are defined separately when implemented.
**Weights training** belongs to the Benchmark workspace. It connects selected criteria to training datasets, packages, provider jobs and evaluation, rather than adding another empty Assets tab.
## Decision checkpoint
| Need | Open | Boundary |
| --- | --- | --- |
| Inspect or prepare a reusable situation | Cases | Canonical input and declared materials |
| Edit candidate execution logic | Harnesses | Draft, saved Version and explicit use |
| Guide meaningful alternatives | Comparison Directions | Guidance, not a correctness judgment |
| Design expert presentation | Review Screens | Selectable presentation asset |
| Understand environment context | Worlds | Immutable source and isolated execution copy |
| Prepare a trainable model candidate | Benchmark → Weights training | Dataset, package, job and evaluation |
## Reuse and selection
A project asset can support more than one Benchmark. That reuse does not automatically add every Case to every dataset or activate every Harness Version.
Benchmark Datasets owns current Case membership and Snapshots. A saved Harness Version remains the exact candidate used by a recorded Run, even when its Draft changes later.
Use Cases and Project Input Schema for static supporting material. A document does not require a World simply because an agent reads it. Harnesses retain their tool implementations and declared dependencies; the retired standalone Project Tools category does not become a new authority over those capabilities.
## Preserve attribution
Inspect the selected asset identity when preparing a Contribution, evaluation or improvement task. A human-readable title helps navigation but cannot replace the exact saved content and scope used by accepted work.
A screen, direction or generated Case is not automatically an approved standard. Policies and Rubrics retain their own governance lifecycle.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Cases](/docs/assets/cases)
- [Harnesses](/docs/assets/harnesses)
- [Worlds](/docs/assets/worlds)
- [Personas](/docs/assets/personas)
- [Comparison Directions](/docs/assets/comparison-directions)
- [Review Screens](/docs/assets/review-screens)
- [Weights Training](/docs/weights-training)
{% /related-card-grid %}
---
id: assets.worlds
title: Worlds
summary: Understand immutable World source snapshots, separate runtime instances, and static Case materials.
kind: reference
product_area: assets
status: stable
updated: 2026-10-30
canonical: /docs/assets/worlds
---
# Worlds
## Definition
A World is a reusable project-scoped snapshot of environment state. Its source stays immutable; an execution operates on an isolated copy.
**Assets → Worlds** displays **Early reviewers only**.
## Fields, states, or lifecycle rules
- Source snapshots and execution instances have different identities.
- Static Case associations use `content.world_refs`.
- Executable context uses an optional `world_instance_ref`.
- Static files and supporting values remain Case materials.
- Running, completed or failed describes an execution copy rather than a mutation of the source snapshot.
## Source and execution context
Files, records, messages or service-state snapshots can describe environment state. A Harness uses the capabilities supplied by its runtime instance; it does not mutate the accepted source World.
Source references do not themselves provision an instance. Keep the Case association separate from the executable reference, and preserve exact issued identities rather than substituting a source template ID for an instance.
## Choose the right context
Use Project Input Schema and Case materials for static supporting content. Use Harness source for candidate logic and declared dependencies.
World authoring, durable provisioning and management controls are separate contracts. The current surface provides the Early reviewers only entry, without a catalog editor, attachment workflow or instance-management controls.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Assets](/docs/assets)
- [Harnesses](/docs/assets/harnesses)
- [Project Input Schema](/docs/project-settings/input-schema)
{% /related-card-grid %}
---
id: coverage.scenarios
title: Scenarios
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-10-30
canonical: /docs/coverage-engineering/scenarios
---
# Scenarios
## Definition
A Scenario describes a reusable mechanism for building cases. It answers “how should this situation be constructed?” while Dimensions describe differentiating values and Topics describe subject matter.
Examples include conflicting authorities, missing prerequisite supporting information, ambiguous user intent, multi-step state change, or a plausible but superseded source. A good Scenario is portable across Topics rather than tied to one case's wording.
## Fields, states, or lifecycle rules
Each Scenario has a name, description, origin, usage counts, examples, and benchmark statistics. Origins currently distinguish manual, AI-generated, expert-input, and imported Scenarios. Usage can show Case Pool cases, benchmark cases, requirements, and benchmark steering.
Scenario suggestions can be grounded in Topics, source material, existing cases and Scenarios, 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
Canvas settings can use one of three modes:
- **System choose:** allow construction to select appropriate Scenarios from the project library.
- **Prefer:** encourage named Scenarios when building Coverage Stories and cases.
- **Avoid:** prevent named Scenarios from shaping this benchmark's intended case supply.
Coverage Story tuples can also reference specific Scenarios. The tuple reference is the concrete construction instruction for that part of the story; the project Scenario 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 Scenario.
- Keep Topics out of the Scenario definition unless they are only examples.
- Do not encode an expected answer or rubric verdict as a scenario.
- Inspect examples and usage before deleting or materially changing a Scenario.
- Treat AI and expert suggestions as reviewable proposals. Origin is provenance, not approval.
> Scenario versus requirement
>
> A Scenario describes a reusable structure. Benchmark requirements describe constraints for one benchmark, and a Coverage Tuple combines the relevant Dimensions, Topic Groups, Scenarios, proof statement, and target case count.
{% example-demo title="Example: portable scenario" %}
The project defines **Plausible superseded authority**: construct a case where an older source appears credible but a newer source controls. Coverage Stories reuse the Scenario 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" %}
- [Topics](/docs/coverage-engineering/project-topics)
- [Coverage Design Settings](/docs/coverage-design/settings)
- [Coverage Stories](/docs/coverage-design/coverage-stories)
- [Review Prepared Cases](/docs/coverage-design/case-review)
{% /related-card-grid %}
---
id: concepts.trialground
title: Trialground
summary: Evaluate saved candidates and externally produced responses against fixed Cases and governed rubric criteria.
kind: concept
product_area: trialground
status: stable
updated: 2026-10-30
canonical: /docs/concepts/trialground
---
# Trialground
Trialground is the evaluation capability that connects candidate behavior to the Cases and correctness criteria in an immutable Benchmark Version.
## Definition
Managed execution evaluates an exact saved Harness Version. External import evaluates actual responses produced by another system. Both paths preserve the candidate context, Case identity and applicable criteria needed to interpret the result.
The current workspace is **Benchmark Evaluations**, with **Runs**, **Results** and **Dashboard**. A Run contains its planned Trials. Each Trial executes the selected candidate across the recorded Case population.
## Decision checkpoint
| Question | Inspect | Boundary |
| --- | --- | --- |
| What will execute? | Saved Harness and launch settings | Version, machine and planned Trials |
| What behavior was observed? | Case response and captured trajectory | Actual submitted or generated content |
| Why did it receive that score? | Results | Applicable Rubrics, gates and points |
| Are candidates comparable? | Results and Run details | Benchmark Version and complete population |
| What changed across executions? | Run history and Dashboard | Independent Runs and stable reference selection |
## Execute deliberately
Run evaluation opens matching existing work when immutable conditions agree. Run again deliberately creates an independent repeat. The reference Run used for score is selected before outcomes are known; later executions do not silently contribute only their best Trials.
A mutable Draft is not an execution identity. Publish the intended candidate and select its saved Version. Credentials use approved grants rather than source files or metadata.
## Interpret results
Binary rubric judgments feed the configured Regime. Positive points are earned, penalty points are deducted and mandatory gates have separate eligibility effects. Negative scores can be valid. Missing judgments remain incomplete rather than shrinking the population.
Results can inspect a single Run or compare managed and imported Runs. Imported responses are not executable Harnesses. Recorded trajectories describe captured steps, not private model reasoning.
## Reuse the conclusion
Preserve actual cost, tokens and latency where recorded. Missing capture stays unknown. Use a measured candidate issue to start improvement, an unclear criterion to request expert judgment, and a missing input situation to improve coverage.
Trialground supplies interpretable measurements; the customer's downstream use of those results remains a separate responsibility.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Benchmark Evaluations](/docs/benchmark-evaluations)
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Import External Evaluation Outputs](/docs/benchmark-evaluations/output-mapping)
- [Rubric Points and Benchmark Scores](/docs/correctness-governance/scoring)
{% /related-card-grid %}