---
id: intro.product-boundaries
title: Product boundaries
summary: Understand what Teammately owns across correctness specification, benchmark development, evaluation, and improvement.
kind: concept
product_area: introduction
status: stable
updated: 2026-09-07
canonical: /docs/introduction/product-boundaries
---

# Product boundaries

Teammately owns the correctness system that connects specialist judgment to deliberate benchmark coverage, executable standards, constructed cases, evaluation evidence, and improvement history. This page distinguishes that system from adjacent inputs and downstream responsibilities.

> Adjacent systems are inputs
>
> Logs, traces, source repositories, model endpoints, coding environments, and external evaluation results can supply material or receive work. Their presence does not change the Teammately ownership boundary: Teammately governs the connected correctness artifacts and the evidence produced from them.

## Definition

The product boundary follows artifacts and authority. Teammately can index project knowledge, prepare an expert contribution, materialize an accepted policy or rubric, construct a case, execute an evaluation through a managed harness, and coordinate an Improvement Session. It preserves which inputs, versions, settings, and human decisions produced the resulting evidence.

Customer teams own the AI system outside that evidence graph and the action taken afterward. Teammately can prepare a scoped package for an external coding worker, but it does not claim private work performed outside the product. It can show benchmark evidence, but it does not turn that evidence into an automatic downstream decision.

## Decision checkpoint

| Area | Teammately owns | Boundary |
| --- | --- | --- |
| Project knowledge and agent context | Materials, Indexed Reference, Project Context, and Contribution-scoped agent behavior | Reference material is not automatically a governed policy or rubric |
| Expert work | Contribution scope, tasks, checkpoints, attributable responses, and contributed artifacts | Agent preparation does not substitute for the expert's judgment |
| Cases and worlds | Canonical case input, case materials, generated artifacts, and verified world references | Static materials and executable environments remain distinct |
| Evaluation | Benchmark Versions, saved Harness Versions, settings, Runs, responses, Rubric results, and comparisons | A score alone does not explain correctness; execution traces are not currently exposed |
| Improvement | Goal Contracts, candidates, evaluation receipts, frontiers, and chronology | External worker activity is represented only when returned through the defined contract |
| Downstream action | Inspectable correctness evidence and review context | The customer decides what operational action follows |

## Human and agent authority

AI agents scale preparation and exploration. They can organize source material, propose coverage structure, draft possible standards, generate cases, evaluate candidates, and suggest improvement directions. The owning surface determines when an artifact becomes durable or governed. An agent proposal does not silently acquire expert authority.

Expert Contributions make this boundary explicit. The product can prepare focused questions and relevant evidence, while the domain specialist supplies the judgment. Correctness Governance records policies and rubrics as governed project assets. Improvement Sessions can branch candidate hypotheses, but retained candidates require observable evaluation evidence.

## Data and execution boundary

Project Input Schema controls the accepted shape of case input and materials. Static context remains part of case content or case-material references. An executable or queryable environment uses a world reference and follows a separate runtime boundary. Public docs describe the behavior visible through stable product surfaces; they do not promote internal storage or service structures into customer-facing contracts.

Similarly, the presence of Harness Assets and managed Runs does not imply that Teammately owns a customer's model registry, production telemetry, or deployment system. A harness is the executable candidate boundary used by a benchmark evaluation.

{% example-demo title="External coding worker" %}
An Improvement Session starts from failed grounding Cases and a confirmed Goal Contract. Teammately prepares a scoped package for a coding worker with the pinned target and evidence. The worker's private activity is outside the product boundary. A returned Harness Version and canonical evaluation request become observable candidates; their Rubric results enter the session record, while Improve may add a safe narrated trajectory of observable session activity.
{% /example-demo %}

## Related workflows

{% related-card-grid title="Related workflows" %}
- [The correctness lifecycle](/docs/introduction/correctness-lifecycle)
- [Start an Improvement Session](/docs/improve/start-improvement-session)
- [Use Reference Materials](/docs/agent-setup/reference-materials)
{% /related-card-grid %}

## Related reference pages

{% related-card-grid title="Related reference pages" %}
- [Human Approval Boundaries](/docs/governance/human-approval-boundaries)
- [What AI Features Can and Cannot Do](/docs/governance/what-ai-features-can-and-cannot-do)
- [Project Input Schema](/docs/project-settings/input-schema)
{% /related-card-grid %}

## Source confidence

Doctrine-backed: this page states product ownership and authority boundaries. Exact UI and execution behavior is delegated to linked code-backed pages.