---
id: playbooks.policy-heavy-ai-systems
title: Using Teammately for Policy-Heavy AI Systems
summary: Govern AI behavior where correctness depends on many explicit rules and boundary cases.
kind: recipe
product_area: playbooks
status: stable
updated: 2026-08-23
canonical: /docs/playbooks/policy-heavy-ai-systems
---

# Using Teammately for Policy-Heavy AI Systems

Use this playbook when an AI system can appear fluent while still violating explicit rules, exceptions, ownership boundaries, or customer-impacting policy.

## Establish the policy inventory

Use this when correctness depends on several controlled rules, exceptions, or source hierarchies and each rule has an accountable owner. If the team cannot identify controlling sources and owners, begin with Reference Materials and Expert Contributions rather than drafting a large generic Policy set.

## Govern policy-heavy behavior

1. Connect the controlling sources in **Reference Materials** and identify the owner and effective boundary for each rule family.
2. Use Expert Contributions to resolve exceptions, cross-policy conflicts, missing facts, and operational interpretation.
3. In **Correctness Governance**, create narrow Policies with explicit applicability and one-obligation binary Rubrics.
4. Link representative passing, failing, and boundary Cases to the governed standards.
5. Configure Coverage Facets for policy family, exception type, authority, required context, and consequence.
6. Use Coverage Management to find Policy families or exception combinations with thin representation.
7. Create a Snapshot and Benchmark Version only after the selected Dataset and governing standards are ready.
8. Evaluate saved Harness Versions and inspect failures by Policy, Rubric, and Coverage Facet before changing the candidate.

## Maintenance triggers

Refresh the governed boundary when a controlling source changes, an exception is added, applicability changes, a Rubric no longer tests one observable requirement, or new Cases expose a conflict. Historical Runs remain evidence under their original Benchmark Version.

{% example-demo title="Subscription entitlement assistant" %}
An assistant answers whether an account can use an enterprise integration after a plan change. Specialists separate three governing boundaries: plan entitlement, contract exception, and administrator permission. Each gets distinct applicability and a binary Rubric. Evaluation shows that the candidate reads the plan correctly but assumes administrator permission and ignores contract overrides, so the team can fix two precise behaviors instead of tuning a generic entitlement score.
{% /example-demo %}

## Evidence to collect

- Policy sources, accountable owners, and effective boundaries.
- Applicability triggers for each policy family and risk tier.
- Must-level binary rubrics and any lower-priority preference criteria.
- Coverage dimensions for exceptions, conflicts, stale policy, and missing context.
- Benchmark evidence grouped by Policy, Rubric, and Coverage Facet, with unresolved authority questions kept explicit.

## Related docs

{% related-card-grid title="Related docs" %}
- [Handling Boundary Cases](/docs/coverage-engineering/boundary-cases)
- [Work with Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics)
- [Inspect Dataset representation](/docs/benchmark-datasets/representation)
- [Compare Harness Versions](/docs/benchmark-evaluations/compare)
- [Read run results](/docs/benchmark-evaluations/inspect-results)
- [Run a benchmark](/docs/benchmark-evaluations/run-evaluation)
- [Importing cases](/docs/operating-manual/import-and-prepare-cases)
{% /related-card-grid %}

## Source confidence

Doctrine-backed: the approved product model separates source context, expert interpretation, governed standards, coverage, and evaluation. Linked code-backed pages define the active controls for each layer.