# Policies Generated: 2026-09-13T04:39:07.347Z Source build: local Canonical docs: https://teammately.ai/docs --- 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: 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. ![Correctness Governance rows showing Policy titles, lifecycle state, required behavior force, linked-count columns, and accountable owners.](/docs-assets/assets/screenshots/policies-rubrics-neutral-rows.png) 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 %} --- id: object-model.applicability-logic title: Applicability logic summary: Explain when a policy or rubric should be used for a case, output, or coverage segment. kind: reference product_area: object_model status: stable updated: 2026-08-23 canonical: /docs/object-model/applicability-logic --- # Applicability logic ## Definition Applicability logic is the boundary that decides whether a policy or rubric should be considered for a specific case, output, or coverage segment. It prevents a good standard from being applied to the wrong behavior. Use this reference when a benchmark result is hard to explain because a standard seems relevant in some cases but not others. The question is not only whether the policy is correct; it is whether the policy was eligible to judge that output. ## Fields, states, or lifecycle rules - Applicability sits between the case/output and the policy/rubric that may judge it. - Weak applicability makes benchmark failures noisy: a candidate can fail a good rubric on a case where the rule should not have applied. - Strong applicability names the behavior condition, source context, or case segment that brings the standard into scope. - Applicability changes can make old benchmark evidence stale because the same output may be judged by a different standard boundary. - This page explains the public object relationship, not a public rule language, API schema, or export contract. ## Related objects Applicability logic should be read with [Policies](/docs/object-model/policies), [Rubrics](/docs/object-model/rubrics), [Cases](/docs/object-model/cases), and [Coverage Dimensions](/docs/object-model/coverage-dimensions). Use the Correctness Governance workflow to write the boundary and troubleshooting when the observed Case set is wrong. {% example-demo title="Applicability logic boundary" %} Raw case: A user asks whether a product works with equipment they already own. Policy: Compatibility claims require explicit source support. Applicability logic: The policy applies only when the answer recommends, validates, or compares a product for a concrete use context. Benchmark interpretation: If the case only asks for a product description, the compatibility rubric should not judge it. If the answer claims the product will work with the user's equipment, the rule is in scope. {% /example-demo %} ## Source confidence Code-backed: Policy and Rubric types and their detail routes expose applicability fields and the links among governed standards, Cases, and evaluation checks. This page describes those product relationships; it does not define a portable rule language. ## Related task pages {% related-card-grid title="Related task pages" %} - [Work with Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics) - [Fix weak applicability logic](/docs/troubleshooting/weak-applicability-logic) - [Resolve conflicting correctness evidence](/docs/governance/conflict-resolution) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- 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 %}