---
id: orientation.key-objects
title: Key objects and relationships
summary: Understand how project foundations, contributions, datasets, evaluations, and improvement artifacts connect.
kind: concept
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/getting-oriented/key-objects-and-relationships
---

# Key objects and relationships

Teammately's evidence is trustworthy when a reader can move from project understanding and specialist authority to the exact Case, Benchmark version, Harness version, Run, and Improvement Session involved. This page gives the shared object graph.

> Artifact state matters
>
> An object name is not enough. Preserve project or benchmark scope, version or snapshot identity, provenance, and lifecycle state whenever the object supports evaluation or improvement.

## Definition

A **Project Agent Brief** and published **Reference block** give agents project understanding. **Project Input Schema** governs canonical **Case** input and materials. **Dimensions**, **Project Topics**, and Case Construction Patterns define reusable coverage structure. A saved **Harness version** identifies an executable candidate.

A benchmark selects Cases into a **Dataset snapshot** and combines them with governed **Policies** and **Rubrics** through a **Benchmark version**. An **Expert Contribution** requests specialist judgment through one or more Tasks and Checkpoints. Its **Contributed artifact** can become a policy, rubric, case, or coverage observation while retaining provenance.

A **Run** evaluates a saved Harness Version against a Benchmark Version. Its response, Rubric outcomes, settings, mapping, and metadata form evaluation evidence. An **Improvement Session** pins target evidence through a Goal Contract, creates or receives candidates, records evaluation receipts and safe session narration, and maintains a **Current frontier**.

## Decision checkpoint

| Object | Scope | Relationship that must remain visible |
| --- | --- | --- |
| Project Agent Brief / Reference block | Project | What agents understood and which source generation was available |
| Case / Harness version | Project | Which reusable asset and exact candidate state was selected |
| Contribution / Checkpoint | Benchmark | Which expert supplied or confirmed the judgment |
| Policy / Rubric | Project governance | Which authority, applicability, cases, and provenance support it |
| Dataset snapshot / Benchmark version | Benchmark | Which cases and correctness boundary define evidence |
| Run | Benchmark version | Which Harness, settings, mapping, and metadata produced results |
| Improvement Session / Current frontier | Benchmark version | Which goal and evaluation receipts justify retained candidates |

{% artifact-map title="How correctness artifacts connect" %}
{% /artifact-map %}

## Static materials and executable worlds

Canonical Case content separates `content.input` from optional `content.case_materials`. Static execution support uses case-material references. A `world_instance_ref` represents an executable or queryable environment and follows a separate capability and lifecycle boundary. The rendered case view helps people and adapters inspect canonical content; it does not create another authoring source.

## Provenance across scopes

Project assets can be reused across benchmarks, while dataset snapshots, Contributions, Runs, and Improvement Sessions remain benchmark-scoped. Materializing a contributed policy moves its governed owner to project scope without erasing the benchmark Contribution that supplied it. Evaluating a candidate records the saved Harness version rather than whichever Draft is currently open.

{% example-demo title="Contribution to frontier" %}
An Expert Contribution confirms a source-authority Policy and Rubric from selected Cases. The Cases enter a Dataset snapshot and the standard enters a Benchmark version. A Run evaluates Harness version 8 and exposes three failures. An Improvement Session pins those failures, evaluates versions 9 and 10, and retains version 10 in the Current frontier with canonical evaluation receipts.
{% /example-demo %}

## Related workflows

{% related-card-grid title="Related workflows" %}
- [First correctness loop](/docs/operating-manual/first-correctness-loop)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Start an Improvement Session](/docs/improve/start-improvement-session)
{% /related-card-grid %}

## Related reference pages

{% related-card-grid title="Related reference pages" %}
- [Object model](/docs/object-model)
- [Project Input Schema](/docs/project-settings/input-schema)
- [Product map](/docs/getting-oriented/product-map)
{% /related-card-grid %}

## Source confidence

Code-backed: active navigation, canonical case contracts, Contribution surfaces, versioned evaluation routes, and Improvement Session contracts support this object graph.