guide Updated 2026-10-06
Run a Playbook
Execute a suggestion and record the outcome — so the vault learns from every attempt.
Before you start
Run playbooks from the suggestions panel, not from a wish list. A suggestion means the engine has verified the requirements are present on this asset — the ground truth you said you observed.
Only work suggestions the engine actually produced. Executing unrelated playbooks burns time and poisons the outcome history with noise.
Open the suggestion
Read it first: which components matched, how specific the match is, and what the playbook yields if it succeeds. The reasoning is the point — if a match looks wrong, fix the data before you test.
Execute against the target
Do the actual work outside Nimbus Vault, within program rules. The vault is where knowledge lives, not where exploitation happens.
Record the outcome
Record the run as **success**, **failed**, or **not applicable**:
- **Success** grants the playbook's yields — possibly asking you to pick which ones materialized, and on which endpoint.
- **Failed** prunes this suggestion from the queue.
- **Not applicable** marks the playbook as irrelevant to this asset without treating it as a failed attack.
Check the earned capabilities
Yields land on the asset as primitives. New playbooks that require those primitives may now appear — that cascade is the vault working as intended.
Retracting
If a success turns out to be wrong, retract it. The yields it granted are revoked, cascading through whatever depended on them. Nothing is lost from history — the outcome trail stays intact, which is exactly why recording honestly is safe.