Outcomes and History
Recording what actually happened — the feedback loop between a run and the engine.
Three outcomes
Every playbook run ends in one of three states:
| Outcome | Meaning | Effect on the vault |
|---|---|---|
| Success | The playbook's capability was achieved | Grants its yields as primitives; unlocks gated playbooks |
| Failed | It was applicable, but did not work here | The suggestion is retired — the engine stops surfacing it |
| Not applicable | It is genuinely irrelevant to this asset | Retired as noise, without recording a failed test |
Success earns. Failed and not-applicable prune. Both directions make the vault better: a failed run is still knowledge, and a not-applicable answer removes a suggestion that would otherwise keep asking for attention.
What recording a run does
Recording an outcome moves the playbook out of the active suggestion list and into the asset's history. From then on:
- Success stands as evidence — and every playbook gated on its yields now sees them.
- Failed stays on record: you tested it, it did not apply, the engine reasons with that truth.
- Retracting a success revokes the yields it granted and cascades through anything that depended on them (see Yields and Primitives).
Nothing is deleted. The reasoning trail — what fired, when, and what happened — lives in the playbook's and the asset's history long after you forget the details.
History per asset
Each asset keeps a history with three sections:
- Playbooks — every run outcome, with its yield trail.
- Proactive Checklist — prompts you resolved by hand rather than by assignment.
- Reactive Checklist — component objectives you checked or dismissed.
Items stay in history permanently unless you remove them. Removing an entry makes it eligible again — a prompt can ask once more, a dismissed objective can resurface. That is the escape hatch for mistakes, not the default: the record is meant to be trustworthy, so corrections are deliberate.
The discipline
- Record outcomes only for playbooks you actually ran.
- Record them with the yield endpoint when you have it.
- Prefer "not applicable" for noise and "failed" for tested-and-didn't-work; the difference matters in the trail.
- Correct mistakes by retracting — never by leaving a false success in place.
What's next
The loop closes here and reopens at the top: map what you learned, and the engine reasons from better data.