---
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 %}