IO Playbooks™ encode the intervention, prerequisites, expected outcome and verification rule described below.
Status: product reference · current structure
A playbook is encoded method, not a document attached to a task. It defines when an intervention applies, what must already be true, how the work is performed and how the result will be judged. The execution record is created later, when a named person accepts the prescribed action.
The six authored fields
1. Trigger
The correlated condition that makes the playbook relevant. A trigger names the signal or state; it is not a broad concern such as “improve culture.”
2. Prerequisites
The conditions that must already exist for the intervention to have a reasonable chance of working. If a prerequisite is absent, the playbook is withheld and the missing prerequisite becomes the next action.
3. Maturity gate
The minimum practice maturity required to run the method. This references the canonical IO maturity model version. A domain performance score or performance band cannot be substituted for the maturity result.
4. Ordered steps
The work in sequence, with the responsible role, expected effort and dependency for each step. The action receives a named accountable owner at acceptance; a playbook template should not hard-code a person.
5. Expected outcome
What should be observably different after the work. The expected outcome is written before execution so it cannot be rewritten to match what happened.
6. Verification criterion
The complete rule used to judge the work:
| Field | Requirement |
|---|---|
| Measure | One value computed the same way twice |
| Unit | The unit in which the value is expressed |
| Population | The people, assets, suppliers or events included |
| Direction | Higher or lower is better |
| Noise threshold | Minimum movement that counts as material |
| Source | System and query or method version |
| Re-measurement | Due date or interval, observation window and minimum sample |
| Risk dimension | Likelihood, impact or not declared |
A playbook missing any required criterion field can still prescribe work, but it is marked not verifiable and cannot move observed residual.
What is created at acceptance
The following do not belong to the reusable playbook definition. They belong to the accepted action and its execution record:
- the named accountable owner
- accepted-by and accepted-at
- due date
- baseline value and source record or extract ID
- the population resolved for this execution
- step completion and blocking evidence
- re-measured value, date and result
This distinction matters. A playbook contains the rule for taking a baseline; it cannot contain the baseline itself before a particular action exists.
Gating behaviour
Withholding is explicit. The record names the failed prerequisite or maturity gate and the action prescribed instead. Nothing is silently dropped.
Observed effectiveness affects playbook ranking inside the tenant. Automatic suppression requires a versioned rule for minimum sample, maturity context and failure threshold. Until that rule is published, a weak playbook may rank lower but must not be described as automatically retired.
What a playbook does not prove
Completion proves that the recorded steps ran. Verification shows that the declared measure moved, did not move, moved the wrong way or could not be relied on. Neither alone establishes causation.
Effectiveness attaches to the method, not the person who executed it. The record must not be used as an employee-performance score.