Requirements
Every assignment level and property a playbook requirement can carry.
What a requirement is
A playbook requirement tells the engine what must be observed before the playbook becomes relevant. Requirements come in different levels (what they point at) and properties (how they behave when matched). This page is the full mechanics reference — for the how to think about them, read the Authoring Guide.
Assignment levels
A requirement can point at a single component, at a scoped child of a component, or at a category:
| Level | Resolves against | Example |
|---|---|---|
| Individual component | One specific entry in the library | Technology: Node.js |
| Scoped vector (CLV) | A vector observed inside a specific parent | SVG upload inside File Upload |
| Scoped quirk (CLQ) | A quirk observed inside a specific parent | Prototype pollution inside Node.js |
| Quirk on a vector (CLVQ) | A quirk on a scoped vector | Stored XSS on SVG upload |
| Nested vector (CLVv) | A vector inside another vector | Vector chaining |
| Scoped gadget (CLG) | A gadget nested inside a parent component | GraphQL endpoint inside a technology |
| Category | Any component in a category | Any Functionality in Authentication |
| Category + tag | Components in a category carrying a tag | Authentication + #oauth |
Scoped matching requires the exact parent. A vector scoped inside one functionality does not satisfy a requirement for the same vector type scoped inside a different functionality — SVG upload on File Upload is not SVG upload on Login Form. This is what makes scoping worth doing: it encodes where a capability lives, not just that it exists.
Category mode: any or all. An "any" category requirement is satisfied by at least one member. An "all" requirement needs every member of the category — and it grows as the category does, so a new component added to a category becomes a new required condition for every playbook that requires the whole category.
The type is locked by the slot. A category assignment resolves only against the component type it sits in — a category on a Technology slot never resolves against functionalities that share the label.
Properties
Required — the hard gate
All required components together form an AND gate. The playbook is excluded entirely until every required component is satisfied — later scoring never runs. A partially satisfied playbook does not sit silently; its missing required components become proactive prompts.
Optional — the confidence signal
Optional components never gate. Once the required set is satisfied, the playbook fires whether or not they are present; their absence lowers confidence, their presence raises it. Optional components are how you encode meaningful-but-unconfirmable context (an affected framework, a risky ecosystem) without creating silence.
Enabling and mitigating quirks
A quirk requirement can act as an enabler (its presence makes the outcome more likely) or a mitigator (its presence blocks or dampens the outcome). The same quirk can be an enabler in one playbook and a mitigator in another — the role is set per assignment. Mitigating factors carry more weight when absent, because a single mitigation can block an exploit while a single enabler rarely guarantees one.
Present and absent — quirk polarity
Some quirks are stateful: what matters is whether the target currently exhibits the behavior or explicitly does not. These carry a polarity — present or absent — and the reactive checklist only offers objectives whose polarity matches what was actually observed on the asset. A required quirk written as "does not exhibit X" is satisfied only by a confirmed absence, not by silence.
Version constraints
Technology requirements can carry a version constraint — exact versions, comparisons (>=14, <19), and ranges. How the engine treats constraints is a workspace setting:
- Lax — unknown versions are still included, with a confidence penalty.
- Strict — a technology whose version cannot be verified never satisfies a versioned requirement, and unknown versions are excluded.
Lax favors coverage during black-box hunting; strict favors precision when version data is reliable.
Co-location
A playbook-only flag on an individual component link: "the same endpoint as the required primitive." The flagged component only counts where its recorded endpoints intersect the endpoints of the playbook's required primitives — the union of all of them.
- It is available only when the playbook has at least one required primitive.
- It is strict both ways: no endpoints recorded on the component, or no endpoints on the primitives, means no match.
- A failed required co-located link excludes the playbook entirely; a failed optional one just lowers the score.
This is how a playbook avoids the classic false positive where every ingredient exists on a target but never in the same place.
Primitive requirements
A requirement can demand an earned primitive rather than a library component — a capability granted by an earlier playbook's success. Assigned components never satisfy it; it must be earned. See Yields and Primitives.
How the engine treats requirements
- Required and missing → playbook excluded; the gap becomes a prompt on the asset.
- Scoped and matched at the right level → a more specific match, ranked higher than a flat one.
- Optional → tuned into the score.
- Satisfied entirely → the playbook appears in the asset's suggestions, ranked against everything else that matched.