Yields and Primitives

Yields: what a playbook produces

Requirements describe what a playbook needs. A yield declares what it produces. When a playbook is marked successful, its yields are granted to the asset as capabilities that did not exist there before.

A yield can be:

• A library concept — an existing reusable component like Stored XSS or SSRF, earned rather than observed.
• A chain token — a self-contained capability that only exists because a playbook granted it, like arbitrary-file-write or an internal foothold. These never pollute the component library: they have no library page, only purpose as a link in a chain.

Not every capability a playbook demonstrates should be a yield. Declare a yield when another playbook could one day start from it — that is the test.

Primitives: earned, not observed

Granted yields land on the asset as primitives. The distinction between a primitive and a library component is the whole point:

• A component is something you observed: you found Node.js, you saw a file upload.
• A primitive is something you achieved: you turned the upload into arbitrary file write, you turned the reflection into execution.

Primitives can't be "reconned" — you can't nmap for them or find them in a JS bundle. The asset's primitives panel is read-only: the only way in is a successful playbook, and the only way out is retracting that outcome. That immutability is a feature. A primitive means someone demonstrated something, not that someone ticked a box.

Granting yields

When you mark a playbook successful:

• Grant all — its declared yields are all attached to the asset silently.
• Pick — for playbooks with more than one yield, you choose which actually materialized. Real runs are messy: you got the shell but never found credentials. The vault records what happened, not what could have.

If a yield's discovery happened on a specific endpoint, the vault asks for it at grant time and stores it on the earned link — the same endpoint discipline that powers co-location, now applied to capabilities you earned rather than observed.

Yield-gating: the chain mechanic

A playbook requirement can demand an earned primitive instead of a library component. This is yield-gating, and it changes what the requirement means: the engine will not accept a manually assigned gadget, no matter how similar. The capability must have been earned by a successful playbook.

That is how chains form. A playbook that requires "stored XSS on this asset" can be satisfied in exactly one way — by earning stored-xss somewhere upstream — and the moment it is earned, every playbook gated on it becomes eligible.

Meta-playbooks

Because yield-gating consumes the capability rather than the route to it, some playbooks are deliberately written without an upstream: an escalation playbook that takes any stored XSS and raises it, regardless of where the XSS came from. Write the escalation knowledge once, and every path that lands on that primitive gets it for free.

A worked chain

Archive extraction on File Upload
  └─ earns: arbitrary file write
       └─ enables: overwrite a served file
            └─ earns: stored XSS
                 └─ enables: an escalation meta-playbook
                      └─ earns: privileged action on the target
                           └─ account takeover

Each stage was a separate playbook with its own requirements. None of them could fire until the previous one succeeded — and none of them needed to know how the previous one was achieved. The suggestion list only grows as you work through a chain, because earned primitives stay earned.

Retraction and the cascade

Marking a success is a claim; claims can be corrected. If you retract a success:

• The yields it granted are revoked from the asset.
• Every playbook whose requirement depended on a revoked primitive is re-evaluated — downstream suggestions that were standing on that primitive are reverted with it.
• The history keeps the full trail; nothing about the correction is hidden.

This is also why outcomes are recorded honestly in the first place: the cascade only works when the data is true. See Outcomes and History.

What's next

• Outcomes and History — recording runs the engine can trust.
• Chains — how chains are recognized as a methodology.