# Policy Versioning
Generated: 2026-09-13T04:39:12.547Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: governance.policy-versioning
title: Policy Versioning
summary: Preserve policy changes so decisions can be interpreted against the standard used at the time.
kind: reference
product_area: governance
status: stable
updated: 2026-08-23
canonical: /docs/governance/policy-versioning
---
# Policy Versioning
## Definition
A Policy version preserves one governed statement of intended behavior together with its applicability and approval context. The durable Policy identity connects revisions; the version identity tells readers which wording and boundary informed linked Rubrics, Cases, Benchmark Versions, and evaluation results.
## Fields, states, or lifecycle rules
- Editing meaning, scope, precedence, exception handling, or applicability requires a distinguishable version.
- Draft or suggested wording is not an approved Policy version.
- Rubrics linked to a Policy must be reviewed when the Policy meaning changes; versioning the Policy does not silently repair every Rubric.
- Existing Benchmark Versions and Runs retain the Policy version admitted at their evidence boundary.
- A later current Policy does not make an older result false; it makes the result historical under the old standard.
- Activity and approval context explain why a version changed, but do not replace the version identity.
- Policy versions do not authorize downstream deployment or governance decisions.
## Related objects
Use Correctness Governance to inspect the current Policy, related Rubrics, linked Cases, approval context, and activity. Use Versioning and Staleness to route follow-up when changed Policy meaning affects current dataset readiness or future benchmark interpretation.
{% example-demo title="Adding an exception" %}
The current Policy says opened items cannot be returned. Experts confirm an exception for documented safety recalls. The revised Policy creates a new version, and its applicability and linked Rubrics are reviewed. Runs under the earlier Benchmark Version remain evidence of behavior against the old rule. A new Snapshot and Benchmark Version admit the changed standard for later evaluation.
{% /example-demo %}
## Source confidence
Code-backed: Policy types and detail routes expose durable identity, current version context, approval, activity, related Rubrics, and linked Cases. Benchmark pages define how an exact Policy version enters immutable evaluation evidence.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Policies](/docs/object-model/policies)
- [Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics)
- [Versioning and Staleness](/docs/governance/versioning-and-staleness)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
---
id: object-model.policies
title: Policies
summary: Define policies as reusable statements of what correct AI behavior requires.
kind: reference
product_area: object_model
status: stable
updated: 2026-08-23
canonical: /docs/object-model/policies
---
# Policies
## Definition
Policies are reusable statements of what correct behavior requires. They preserve expert judgment as a governed standard that can later be tested by applicability logic and rubrics.
Use this reference when a team needs to know whether a rule is a draft suggestion, an approved correctness standard, or a standard whose version may affect benchmark evidence.
## Fields, states, or lifecycle rules
- A policy names the rule; a rubric tests the rule.
- A policy needs applicability logic before the team can know which cases it should judge.
- Policy approval state matters before benchmark use.
- Policy revisions can make older benchmark evidence stale or require comparison notes.
- This page does not define legal, compliance, retention, or external policy-management guarantees.
## Related objects
Policies should be read with [Applicability logic](/docs/object-model/applicability-logic), [Rubrics](/docs/object-model/rubrics), [Policy versions](/docs/governance/policy-versioning), and [Human Approval Boundaries](/docs/governance/human-approval-boundaries). Use [Create a policy](/docs/correctness-governance/policies-and-rubrics) for the operating workflow.
{% example-demo title="Policies boundary" %}
Expert judgment: Answers should not claim compatibility unless source data explicitly supports the claim.
Policy: Compatibility claims require explicit source support.
Interpretation: The policy explains the standard; linked applicability and rubrics decide when and how a specific output is judged.
{% /example-demo %}
## Source confidence
Code-backed: Policy types and list/detail routes expose identity, description, applicability, linked Cases and Rubrics, version facts, and approval state. The product object is a governed correctness standard, not an external legal-policy system.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics)
- [Applicability logic](/docs/object-model/applicability-logic)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
---
id: governance.versioning-staleness
title: Versioning and Staleness
summary: Know when correctness objects changed and when old evidence may need review.
kind: concept
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/versioning-and-staleness
---
# Versioning and Staleness
## Definition
Versioning preserves the exact artifact state used by an earlier decision or evaluation. Staleness is the signal that current evidence, configuration, or interpretation may no longer support the same claim after a related object changes. A stale signal routes review; it does not automatically delete an artifact, invalidate every historical result, or approve a replacement.
## Why it matters
Cases, Policies, Rubrics, Benchmark Versions, Harness Versions, and Improvement Session goals can change independently. Named versions keep old evidence interpretable. Staleness helps teams decide which current Datasets, evaluator links, Runs, or customer-owned human review context need attention before being treated as current.
## Where it appears in the product
Use the owning object page to inspect its current version and activity. Use Dataset Snapshots and Benchmark Versioning for immutable evaluation boundaries. Use Staleness Detection to identify downstream artifacts affected by a change. Use Conflict Resolution when expert or source evidence disagrees about what the new governed state should be.
## Artifacts it affects
Common triggers include changed Case input or materials, revised Policy scope, revised Rubric criteria, changed dataset membership, changed Harness configuration, and superseded source material. The responsible next action depends on the owner: correct a Case, approve a new standard version, refresh coverage, create a new Snapshot, run a new evaluation, or preserve an old result as historical context.
Comparison Directions use a narrower stale signal. **Potentially stale** is an advisory label for untouched AI-suggested directions, not a versioned approval state and not automatic removal. User-created and user-edited directions remain user-owned even when Teammately considers them while avoiding duplicate suggestions.
## Operational check
Name the changed artifact and version, identify which downstream claim depended on it, and decide whether the old evidence remains historically valid, requires qualification, or needs replacement through a new canonical workflow. Never “resolve” staleness by editing a label while leaving the evidence boundary ambiguous.
When the object is a Comparison Direction, also check whether a **Potentially stale** label is only advisory. Dismiss the label if the team decides the direction still represents a useful boundary.
{% example-demo title="Revised applicability after evaluation" %}
Experts revise a Policy so it applies only when the customer explicitly requests a recommendation. Runs against the old Benchmark Version remain valid evidence under the former applicability rule. The current Dataset and linked Rubrics are reviewed, a new Snapshot and Benchmark Version establish the revised boundary, and new Runs use it. Any customer-owned human review context names both boundaries instead of marking every old result simply “wrong.”
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Versions, staleness, and resolution](/docs/object-model/versions-staleness-and-resolution)
- [Staleness Detection](/docs/governance/staleness-detection)
- [Compare Harness Versions](/docs/benchmark-evaluations/compare)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
## Source confidence
Code-backed: current Policy and Rubric types preserve versioned governance facts, Snapshot routes preserve immutable benchmark evidence, and Comparison Directions expose a deliberately narrower advisory stale label. Cross-object staleness remains a review and routing decision, not an automatic global state transition.
---
id: correctness.policies-rubrics
title: Policies and Rubrics
summary: Understand the governed relationship between behavior policies, applicability, binary rubrics, linked cases, and expert provenance.
kind: reference
product_area: correctness_governance
status: stable
updated: 2026-08-23
canonical: /docs/correctness-governance/policies-and-rubrics
---
# Policies and Rubrics
## Definition
A **Policy** is a reusable statement of expected specialist AI behavior. Its applicability explains the situations in which the rule controls. A **Rubric** is an evaluation criterion that turns the policy into observable evidence for a case and candidate response.
Correctness Governance owns both artifact types. Expert Contributions can supply proposed or accepted policy and rubric material, while the governance surfaces preserve the artifact's current state, links, activity, and provenance.
## Fields, states, or lifecycle rules
- Policies have identity, descriptive rule content, scope or applicability, linked cases, linked rubrics, activity, and approval context.
- Rubrics have identity, criterion wording, policy or case relationships, evaluation relevance, and lifecycle context.
- A policy can connect to several rubrics when its behavior requirements need separate checks.
- A rubric should express one inspectable criterion wherever independent diagnosis matters.
- Linked cases demonstrate applicability or behavior; benchmark dataset membership remains a separate benchmark-scoped decision.
- Proposed applications and agent suggestions remain proposals until the owning workflow records acceptance.
- Expert contribution provenance should remain visible when contributed material becomes a governed artifact.
- Editing a project-level standard does not retroactively change the standard boundary used by an already recorded Run.
Read the rule, state, links, and owner together; a plausible title alone does not establish governed authority.
## Reading the pair
Begin with the policy when deciding what should happen and why. Inspect applicability before assuming the policy governs a case. Then read the linked rubric as the testable question applied to candidate behavior. If the rubric cannot be answered from the response and visible case evidence, revise the criterion or the case rather than relying on reviewer intuition.
When standards overlap, distinguish complementary criteria from contradictory authority. Preserve unresolved conflict until an accountable expert contribution or governance action settles the intended rule.
{% example-demo title="Example: escalation policy and rubrics" %}
A policy states that unresolved eligibility exceptions must be escalated. One rubric checks that the response does not promise the exception; another checks that it gives the correct escalation path. Separating the checks lets an evaluation show whether a candidate avoided the unsupported promise but still failed to guide the user correctly.
{% /example-demo %}
## Source confidence
Code-backed: active policy and rubric detail routes expose linked cases, linked rubrics, approval and activity context, and evaluation relationships. Exact editable fields can vary by artifact state.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics)
- [Write binary rubrics](/docs/correctness-governance/binary-rubrics)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}