Suggestions and Ranking

The moment a match happens

Every time an asset changes — a component is linked, an endpoint recorded, a prompt resolved — the engine re-evaluates the playbook library against it. A playbook appears as a suggestion only when every required component is satisfied. No partial credit, no "close enough."

The result is deterministic: the same library and the same asset always produce the same suggestions in the same order. Nothing is guessed, and nothing changes until the data changes.

Ranked and explainable

Suggestions are sorted best-first, and every suggestion can explain itself. Open one and you see the components that matched, how specific each match was, and what the playbook produces if it succeeds. The reasoning is the point — if a match looks wrong, the fix is in your data, and the suggestion list will follow.

What ranks a suggestion higher

Ranking reflects specificity and completeness, not just "how many things matched":

• Structure beats volume. A quirk scoped inside the exact technology that owns it is a stronger claim than the same quirk floating somewhere on the asset. Scoped matches outrank flat ones.
• Category precision. A category + tag requirement is satisfied by fewer things than a bare category — and fires only when the exact subset exists.
• Endpoint support. A requirement that asks for capabilities to meet on the same endpoint only ranks well when the endpoints actually line up.
• Quirk pressure. Enabling quirks raise confidence; mitigating quirks lower it. Mitigations weigh heavier in the other direction — one confirmed mitigation can block an exploit, so its absence is treated as more meaningful than a single enabler's presence.
• Version confidence. With lax version matching an unverified version slightly lowers confidence; with strict matching it removes the candidate entirely.

The engine never inflates relevance. If a suggestion is at the top, it is because the evidence you recorded supports it.

Partially satisfied playbooks

A playbook whose requirements are partially satisfied does not appear as a weak suggestion — it becomes work. Its missing required components turn into proactive prompts on the asset, ordered by how close they are to unlocking something.

That split is deliberate. Suggestions are for playbooks you can act on now; prompts are for the gap between where you are and the next suggestion.

Reading a suggestion

• The match — which of the playbook's requirements were satisfied, and at what level.
• The confidence — how specific and complete the evidence is.
• The yield — the capability the playbook grants if it succeeds, which may unlock gated playbooks (see Yields and Primitives).

From here, the loop is run it and record what happened.

What's next

• Checklist and Probes — the other half: what the engine asks you to look for.
• Requirements — the mechanics behind every match.