# Reference library Generated: 2026-09-13T04:32:34.137Z Source build: local Canonical docs: https://teammately.ai/docs --- id: reference.index title: Reference library summary: Look up Teammately objects, states, permissions, metadata, schemas, and source-confidence boundaries. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference --- # Reference library ## Definition The reference library is the lookup layer for object semantics, IDs, permissions, metadata, glossary terms, and source-confidence boundaries. Use it when a workflow depends on exact object meaning rather than the broader operating path. This page is an index, not a schema contract. Use the stable references below for object meaning; draft schemas and internal implementation details do not become public contracts through this index. ## Fields, states, or lifecycle rules - Object references explain identity, state, lifecycle, and relationship boundaries. - Permission references explain user-facing access boundaries only where source-backed. - Metadata and context references explain how records and cases remain reviewable. - Source-confidence labels tell readers whether a claim is code-backed, doctrine-backed, docs-backed, or inferred. - Draft schema pages are not public API or export contracts. ## Related objects Use [Object model](/docs/object-model) for the main artifact graph, [Permissions](/docs/reference/permissions) for access boundaries, [IDs and keys](/docs/reference/ids) for identity references, and [Glossary](/docs/reference/glossary) for vocabulary. {% example-demo title="Reference library boundary" %} Question: A reader asks whether a benchmark run result can be treated as a public export schema. Reference answer: The object references can explain benchmark, run, and result semantics. They do not create a public export contract unless a source-backed public schema page says so. Next page: Use [Benchmarks](/docs/object-model/benchmarks), [Run metadata](/docs/benchmark-evaluations/run-metadata), or [Product boundaries](/docs/introduction/product-boundaries), depending on the claim. {% /example-demo %} ## Source confidence Docs-backed: the documentation manifest and taxonomy define the published reference groups and canonical page relationships. Each linked reference carries its own product-evidence boundary; this index does not raise a draft or internal schema to stable contract status. ## Related task pages {% related-card-grid title="Related task pages" %} - [Object model](/docs/object-model) - [Permissions](/docs/reference/permissions) - [Glossary](/docs/reference/glossary) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: reference.glossary title: Glossary summary: Definitions for current Teammately capabilities, product surfaces, artifacts, and lifecycle states. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/glossary --- # Glossary Use these definitions when choosing a product surface, writing an operating instruction, or interpreting evaluation evidence. Capitalization identifies current product capabilities, surfaces, and named artifacts where it matters. ## Definition The glossary fixes the meaning of current capability, surface, artifact, and lifecycle terms. Capability names describe what Teammately enables; product-surface names describe where people operate; artifact names identify the state that must remain traceable. ### Capabilities - **Correctness Elicitation:** Turns specialist judgment into attributable standards and cases through structured dialogue, tasks, and checkpoints. - **Coverage Engineering:** Represents the behavior space that a benchmark must cover through facets, stories, patterns, and concrete Cases. - **Weave:** Builds case-grounded agent behavior from project knowledge, policies, Rubrics, tools, materials, and worlds. - **Trialground:** Evaluates saved Harness versions against versioned benchmark boundaries and exposes inspectable evidence. - **Coevolve:** Improves agents and benchmark understanding together by feeding contribution, coverage, and evaluation evidence into governed iteration. ## Fields, states, or lifecycle rules ### Project foundations - **Project Agent Brief:** The published project-understanding document in Project Context. - **Reference Materials:** The Agent Setup surface for connecting and indexing source-backed project knowledge. - **Reference block:** An indexed unit of project knowledge with source and generation identity. - **Comparison Direction:** Project Asset that guides meaningful candidate-output differences in comparative expert work; it is not a coverage facet or approved standard. - **Review Screen:** Project Asset that configures the context and inputs presented to an expert. - **Policy:** A governed statement of required or prohibited behavior, with applicability and provenance. - **Rubric:** An executable judgment criterion, commonly binary, that tests applicable behavior against a Policy. - **Coverage Facet:** Reusable project structure for representing behavior space, including Dimensions, Project Topics, and Case Construction Patterns. - **Case:** A reusable behavior situation with canonical input, optional case materials, metadata, and an optional executable world reference. - **Harness:** The agent configuration being built and evaluated. A mutable Draft can be saved as an immutable Harness version. - **Project Input Schema:** The project-level architecture governing canonical Case input and material fields. - **Benchmark Run Metadata:** Benchmark-level descriptive context requested when an Evaluation Run is created; it is not a project-level template or version identity. ### Benchmark workspace - **Benchmark:** A named workspace for a particular correctness boundary and its datasets, coverage, contributions, evaluations, and improvement work. - **Dataset snapshot:** A reproducible selection and representation of benchmark Cases. - **Coverage Story:** Benchmark-scoped intent connecting a behavior risk or need to concrete coverage work. - **Expert Contribution:** A benchmark-scoped request for specialist judgment, containing one or more Tasks and optional Checkpoints. - **Task:** A bounded unit of work inside a Contribution, such as form input, chat, interview, or Case Review. - **Checkpoint:** An explicit confirmation boundary inside a Contribution. - **Contributed artifact:** A policy, Rubric, Case, or coverage observation produced by an expert while retaining Contribution provenance. - **Benchmark version:** The fixed dataset and correctness boundary used for reproducible evaluation. - **Evaluation Run:** One execution of a saved Harness Version against a Benchmark Version, with response, Rubric outcomes, settings, mapping, and metadata. Execution trajectories are not currently exposed. - **Compare:** A symmetric Benchmark Evaluations matrix whose columns are saved Harness Versions and whose rows group governed evidence within one Benchmark Version. - **Arena:** A comparative evaluation surface inside Benchmark Evaluations. - **Improvement Session:** A benchmark-scoped process that explores candidate Harness changes against an explicit goal and pinned evidence. - **Goal Contract:** The Improvement Session definition of target evidence, success criteria, and constraints. - **Evaluation receipt:** Canonical evidence that a particular candidate was evaluated under a particular boundary. - **Current frontier:** The set of retained candidates that currently represent the session's best supported tradeoffs. ## Decision checkpoint | If you mean... | Use... | Do not substitute... | | --- | --- | --- | | Reusable source-backed project knowledge | Reference Materials / Reference block | An untracked attachment or the latest file without generation identity | | Human specialist work for a benchmark | Expert Contribution | A generic approval queue | | The agent state actually evaluated | Saved Harness version | The mutable Harness Draft | | A fixed evaluation boundary | Benchmark version | A Run or a score | | One execution and its evidence | Evaluation Run | The Benchmark itself | | Goal-directed candidate exploration | Improvement Session | An unversioned list of suggestions | {% example-demo title="Distinguish benchmark and run" %} Benchmark Version 4 fixes the selected Cases and governed standards. Harness Version 9 is the candidate. The Evaluation Run is the one execution of Harness Version 9 against Benchmark Version 4. Compare can place Harness Version 9 beside other saved Harness Versions in a symmetric evidence matrix, while an Improvement Session can use failed Case evidence as a pinned target for new candidates. {% /example-demo %} ## Source confidence Docs-backed and code-aligned: the product doctrine defines the five capabilities, and current navigation establishes the product-surface names. Use the linked code-backed pages when an exact field, state transition, or route behavior matters. ## Related task pages {% related-card-grid title="Related task pages" %} - [Product map](/docs/getting-oriented/product-map) - [Product loop](/docs/product-loop) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Object model](/docs/object-model) - [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships) - [IDs and identity](/docs/reference/ids) {% /related-card-grid %} --- id: reference.ids title: IDs and keys summary: Understand the identifiers used across Teammately projects, records, benchmarks, runs, policies, and rubrics. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/ids --- # IDs and keys ## Definition IDs and keys identify Teammately objects across projects, records, cases, benchmarks, runs, policies, rubrics, and administration surfaces. They matter because review context and benchmark evidence are only reproducible when the referenced objects are unambiguous. Use this reference when a note, run, comparison, or troubleshooting path depends on matching the same project, case, standard, benchmark version, or candidate boundary. ## Fields, states, or lifecycle rules - IDs should preserve which object a page, result, or review note is talking about. - Keys and identifiers may appear in URLs, metadata, manifests, admin surfaces, or internal source refs. - A stable ID does not imply that a public API, export format, or integration contract exists. - Review notes should name object boundaries, not only human-readable titles, when reproducibility matters. - Do not expose secrets or infer API-key behavior beyond source-backed admin pages. ## Related objects IDs and keys should be read with [Workspaces and projects](/docs/concepts/workspaces-projects), [Assets](/docs/assets), [Run Metadata](/docs/benchmark-evaluations/run-metadata), and [Permissions](/docs/reference/permissions). {% example-demo title="IDs and keys boundary" %} Scenario: A comparison note says the candidate improved but does not identify the benchmark version or candidate run. ID boundary: The note should identify the benchmark version, run, candidate metadata, and changed artifact if those references are available. Interpretation: Without those identities, the comparison is weak evidence even if the score is visible. {% /example-demo %} ## Source confidence Code-backed: current Project, user, workspace, Benchmark, Policy, and Rubric types show distinct opaque identifiers for those product objects. The reference does not assert that every internal identifier is accepted by a customer-facing API or safe to construct. ## Related task pages {% related-card-grid title="Related task pages" %} - [Workspaces and projects](/docs/concepts/workspaces-projects) - [Permissions](/docs/reference/permissions) - [Assets](/docs/assets) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: reference.metadata-context title: Metadata and context summary: Use record context and metadata fields to make Teammately cases easier to filter, review, and analyze. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/metadata-and-context --- # Metadata and context ## Definition Metadata and context are the supporting fields that make records and cases understandable after they move through import, review, coverage, and benchmark workflows. Context explains the situation; metadata helps filter, segment, trace, and compare it. Use this page when a case is technically present but not useful because reviewers cannot see why it belongs in a behavior slice or what source information should be considered. ## Fields, states, or lifecycle rules - Context should preserve the information a reviewer needs to judge the case. - Metadata should support filtering, coverage planning, benchmark segmentation, and run interpretation. - Metadata is not a substitute for output identity or source context. - Dropped or inconsistent metadata can make coverage look balanced while hiding a missing behavior segment. - This page does not define a public metadata schema or export format. ## Related objects Metadata and context should be read with [Cases](/docs/assets/cases), [Importing cases](/docs/operating-manual/import-and-prepare-cases), [Case versions](/docs/governance/case-versioning), and [Coverage Engineering](/docs/coverage-engineering). {% example-demo title="Metadata and context boundary" %} Raw record: A support transcript includes a customer request, account tier, candidate answer, and later human correction. Context: The account tier and correction explain why the answer was unsafe. Metadata: The case can be segmented as exception request, enterprise tier, and human-corrected source. Interpretation: If that context or metadata is dropped, review and coverage work can still run but the evidence becomes harder to trust. {% /example-demo %} ## Source confidence Code-backed: Cases and record presentation expose contextual fields to reviewers, while Case Pool column mapping and upload-queue types show how imported columns become usable record context. Field availability depends on Project configuration; this is not a universal metadata schema. ## Related task pages {% related-card-grid title="Related task pages" %} - [Cases](/docs/assets/cases) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Connect model outputs](/docs/integrations/connect-model-outputs) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: reference.permissions title: Permissions summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/permissions --- # Permissions ## Definition Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow. This reference does not turn role labels into a complete public permission matrix. Exact permission behavior should stay tied to source-backed pages and the admin or project surfaces that expose it. ## Fields, states, or lifecycle rules - Project access affects cases, standards, coverage, benchmark work, and project settings. - Reviewer access affects assigned expert work and reviewer-facing surfaces. - Organization administration affects members, groups, roles, security controls, API keys, and integrations. - Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts. - Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference. ## Related objects Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and project access](/docs/governance/reviewer-and-project-access). {% example-demo title="Permissions boundary" %} Symptom: A reviewer can sign in but cannot complete assigned case review. Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context. Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark evidence. {% /example-demo %} ## Source confidence Code-backed: Project, user, and workspace types plus Project Permissions and Members surfaces support the user-facing boundaries described here. They do not form an exhaustive authorization matrix; assignment, organization administration, and object approval remain separate product states. ## Related task pages {% related-card-grid title="Related task pages" %} - [Admin Console](/docs/admin-console) - [Workspaces and projects](/docs/concepts/workspaces-projects) - [Permissions troubleshooting](/docs/troubleshooting/permissions) - [Expert UI](/docs/integrations/reviewer-workspace) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} --- id: object-model.overview title: Object model summary: Understand how project foundations, benchmark artifacts, contributions, evaluations, and improvement sessions connect. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/object-model --- # Object model Use this reference when a workflow depends on artifact ownership, identity, version history, or provenance. Teammately keeps reusable project foundations separate from benchmark-scoped evidence so a later reader can reconstruct what the agent knew, what was evaluated, who supplied judgment, and why a candidate was retained. > Preserve scope and version > > An artifact name alone is not sufficient evidence. Preserve its project or benchmark scope, version or snapshot identity, lifecycle state, and provenance whenever it affects evaluation or improvement. ## Definition A **Project** owns reusable foundations: the Project Agent Brief, Reference blocks, policies, rubrics, coverage facets, Cases, Harnesses, Review Screen configuration, Comparison Directions, and Project Input Schema. These objects can support more than one benchmark. A **Benchmark** owns a particular correctness boundary. Its workspace selects Cases into Dataset snapshots, organizes benchmark-scoped coverage work, requests Expert Contributions, and creates Benchmark versions. A Benchmark version is the fixed boundary against which a saved Harness version is evaluated. An **Evaluation Run** records the response, Rubric outcomes, mapping, settings, and metadata produced by one saved Harness Version against one Benchmark Version. It does not currently expose execution trajectories. An **Improvement Session** pins target evidence through a Goal Contract, evaluates candidates, retains canonical receipts and safe narrated session activity, and updates a Current frontier. The frontier is evidence-backed session state, not an unnamed replacement for the saved Harness. ## Decision checkpoint | Question | Object boundary to preserve | Common mistake | | --- | --- | --- | | What did the agent understand? | Project Agent Brief and Reference block generation | Treating the latest source file as the knowledge used by an earlier run | | What behavior was evaluated? | Case, Dataset snapshot, Benchmark version, and saved Harness version | Describing only a prompt and score | | What standard applied? | Policy, applicability, Rubric, and provenance | Letting a Rubric stand in for the Policy it checks | | Who supplied judgment? | Contribution, Task, Checkpoint, expert, and Contributed artifact | Treating an unattributed comment as governed truth | | Why was a candidate retained? | Improvement Session, Goal Contract, evaluation receipt, and Current frontier | Treating an unsaved draft as the evaluated candidate | ## Fields, states, or lifecycle rules ### Project foundations - **Project Agent Brief:** Published project understanding used to orient agents. - **Reference block:** Indexed knowledge with source and generation identity. - **Policy and Rubric:** Governed meaning and executable judgment criteria, with applicability and provenance. - **Coverage Facet:** Reusable Dimensions, Project Topics, and Case Construction Patterns that describe important behavior space. - **Case:** Canonical `content.input`, optional `content.case_materials`, metadata, and optional executable world reference. - **Harness:** An agent configuration with mutable Draft state and immutable saved versions used for evaluation. - **Project Input Schema:** The project-level architecture that governs canonical Case input and materials. ### Benchmark artifacts - **Dataset snapshot:** A reproducible selection and representation of benchmark Cases. - **Coverage Story:** Benchmark-scoped intent that connects coverage structure to concrete case work. - **Expert Contribution:** A benchmark-scoped request containing Tasks, context, statuses, and optional Checkpoints. - **Contributed artifact:** A policy, Rubric, Case, or coverage observation supplied through a Contribution with attributable provenance. - **Benchmark version:** The fixed evaluation boundary used by Runs and Improvement Sessions. - **Evaluation Run:** One execution with candidate, benchmark, response, Rubric outcomes, settings, mapping, and metadata identity. - **Improvement Session:** A goal-directed candidate exploration process with pinned evidence, receipts, trajectories, and frontier state. {% artifact-map title="How correctness artifacts connect" %} {% /artifact-map %} ## Static materials and executable worlds Case materials and executable worlds are intentionally different. `content.case_materials` holds canonical material data or references that can accompany the input. A `world_instance_ref` identifies an executable or queryable environment with a separate capability and lifecycle boundary. Rendering either for inspection does not create another authoring source. {% example-demo title="From contribution to frontier" %} A benchmark Contribution asks a procurement specialist to resolve three ambiguous Cases. The expert confirms a Policy and binary Rubric at a Checkpoint. The artifacts are reconciled into Correctness Governance while retaining their Contribution provenance. The Cases enter a Dataset snapshot and the standard enters Benchmark version 6. An Evaluation Run tests Harness version 11 and exposes two failures. An Improvement Session pins those failures, evaluates versions 12 and 13, and retains version 13 in the Current frontier with canonical evaluation receipts. {% /example-demo %} ## Source confidence Code-backed: current navigation establishes project and benchmark scopes; canonical case-content code establishes the input and materials boundary; the active Improve session contract establishes Goal Contract, candidate, receipt, and frontier concepts. This page describes public object semantics, not a public API or export schema. ## Related task pages {% related-card-grid title="Related task pages" %} - [First correctness loop](/docs/operating-manual/first-correctness-loop) - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation) - [Start an Improvement Session](/docs/improve/start-improvement-session) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships) - [Cases](/docs/assets/cases) - [Harnesses](/docs/assets/harnesses) - [Glossary](/docs/reference/glossary) {% /related-card-grid %}