Playbooks
Requirements in, capabilities out — the recipes of your threat library.
A playbook is a recipe
A playbook describes how a situation is exploited: if a target has these things, this capability becomes available. Two halves:
- Requirements — the components that must be present for the playbook to apply. These are hard gates: miss one and the playbook is excluded.
- Yields — the capabilities the playbook grants when it succeeds.
Requirements can be loose or strict: a plain component, a component scoped inside another, a category match, or a co-located requirement — two capabilities that must meet at the same endpoint. Strictness changes how specific a match is, which changes its rank, but never bypasses a gate.
Yields become primitives
When you run a playbook and record it as successful, its yields are granted to the asset as primitives — earned capabilities that are not part of the component library. Primitives exist only because something granted them, and they feed back into matching: a playbook that requires "SSRF available on this endpoint" can be satisfied by a primitive that an earlier playbook earned.
This chaining is how a vault grows from observations into an attack graph.
Outcomes and honesty
Every run gets an outcome: success, failed, or not applicable. Outcomes are evidence, not vibes:
- Success earns yields — and may ask which endpoint the capability was demonstrated on.
- A failed run is still knowledge: it prunes what the engine keeps suggesting.
- Retracting a success revokes the yields it granted, cascading through anything that depended on them.
The history stays in the playbook's notespace, so the reasoning trail survives long after you forget the details.
What's next
See the machinery that decides which playbook applies: the Nexus Engine.