How to use this playbook
Use the playbook as a set of decision gates and working artefacts. The chapters explain the activity; the templates capture the result; the evidence register shows that the result operates in practice.
Recommended reading paths
| Reader | Start here | Focus on |
|---|---|---|
| Product or delivery lead | Understand your system | scope, outcomes, owners, delivery plan |
| AI or application engineer | Reference architecture | event model, instrumentation, category guides |
| Platform engineer or SRE | Integrate with your stack | collection, correlation, storage, dashboards, alerts |
| Security or privacy specialist | Determine risk and scope | content handling, access, incident evidence, integrity |
| Risk or governance reviewer | Select requirements | applicability, waivers, verification, review cadence |
| Service operator | Dashboards and alerts | triage, runbooks, investigation, escalation |
Two ways to navigate implementation
By delivery phase
Use the tier chapters when sequencing work:
- Tier 1 foundations establish core interaction, tool, error, misuse, and system records.
- Tier 2 investigation adds end-to-end traces, access, human oversight, security, and operational metrics.
- Tiers 3 and 4 analytics add deeper evaluation, drift, fairness, governance, and change-comparison measures.
By operational category
Use the six category guides when assigning work to specialist owners:
- Agent-level observability (
AGT) - Agent performance (
PERF) - User interaction and behaviour (
UX) - System performance, health, and reliability (
SYS) - Safety and security compliance (
SEC) - Product lifecycle and governance (
GOV)
Conventions in each chapter
| Label | Meaning |
|---|---|
| Decision | A choice the accountable owner must record |
| Deliverable | An artefact the team produces and maintains |
| Evidence | Records that support assessment of whether the implementation exists and operates as intended |
| Done when | Minimum exit criteria for the activity |
Tailoring rules
- Not applicable is a playbook record status, not an ORF matrix action. Use it only when the subject of the requirement does not exist anywhere within the approved system scope. Record the testable system fact, reviewer, and reassessment trigger. It must not be used to avoid an applicable Mandatory item.
- A waiver changes the obligation to implement an item; it does not erase the underlying risk.
- Prefer references, hashes, classifications, and stable IDs over duplicated sensitive content.
- Add technology-specific implementation details without changing an ORF metric's meaning.
- Reassess scope after material changes to models, prompts, tools, data, users, autonomy, or deployment context.
A practical cadence
For a new service, run planning before detailed instrumentation work, verify before production release, and move unresolved gaps into an owned backlog. For an existing service, start with a trace-coverage assessment and incident reconstruction exercise; these quickly reveal the most important gaps.