Enterprise Playbooks
Playbooks are scenario recipes for applying Teammately's correctness lifecycle to product-specific AI risks. They do not introduce separate product surfaces; they connect existing artifacts such as Cases, Expert Contributions, Policies, Rubrics, coverage, Benchmark Evaluations, and improvement evidence.
Definition
Enterprise Playbooks names the scenario layer of the docs. Use it when a team knows the kind of AI system or operating problem it has, but needs a concrete path through Teammately's existing correctness artifacts.
Why it matters
Enterprise AI teams often begin with examples, external logs, reviewer comments, or model outputs before they have explicit correctness standards. Playbooks route that material into current Teammately surfaces and state the decision gates that must be satisfied before evidence is trusted.
Choose a playbook
| Starting problem | Playbook |
|---|---|
| Retrieved sources, citation, abstention, or answer grounding | RAG correctness benchmark |
| Search intent, source authority, document conflicts, or freshness | Enterprise search |
| Refunds, commitments, account context, or escalation | Customer support AI |
| Many rules, exceptions, or controlled source hierarchies | Policy-heavy AI systems |
| A bounded question requires accountable specialist judgment | Run Expert Contributions |
| Contribution evidence needs to become reusable standards | Turn judgment into Policies and Rubrics |
| Qualified experts disagree | Handle conflicting opinions |
| Important behavior may be absent from the selected Dataset | Find coverage gaps |
| New evidence or a changed rule makes the current boundary stale | Refresh a Benchmark |
| CI or another evaluation system already owns execution facts | Use existing evaluation infrastructure |
Where it appears in the product
Look for playbooks in this section of the docs. Product screens use operational labels for Cases, Expert Contributions, Policies, Rubrics, coverage, Benchmark Evaluations, and Improve; playbooks organize those existing surfaces around common scenarios.
Artifacts it affects
Depending on the scenario, a playbook can affect imported Cases, supported reference responses, Contribution records, Policies, applicability, Rubrics, Coverage Facets, Dataset Snapshots, Benchmark Versions, Evaluation Runs, comparisons, Improvement Sessions, or customer-owned human review context.
Worked example
Choosing a scenario path
Start
Behavior input
- The common thread is the same
- turn human judgment and source context into explicit standards, cover the risky behavior slices, and use Benchmark Evaluations to produce benchmark interpretation grounded in real results.
A support team with refund-policy failures should start with the customer support or policy-heavy system playbook. A search team with stale-source issues should start with the RAG or enterprise search playbook. A team that already has CI metrics should start with the existing-evaluation-infrastructure playbook.
Related workflows
Related reference pages
Source confidence
Doctrine-backed: the approved product doctrine defines the common correctness lifecycle and current capability boundaries. Each playbook links to code-backed operational pages for exact UI labels, object states, and evaluation limits.