Applicability
Every hypothesis is labelled APPLICABLE, NOT_APPLICABLE, UNKNOWN, or BLOCKED before testing. Missing evidence is never treated as absence.
Four labels
The catalog is not run mechanically. Every hypothesis is labelled from architecture evidence before any testing happens, and the label is retained with its reason code.
| Label | Condition |
|---|---|
| APPLICABLE | At least one required architecture capability is evidenced as present. |
| NOT_APPLICABLE | Every required capability is explicitly evidenced as absent. |
| UNKNOWN | Capability evidence is missing or unresolved. |
| BLOCKED | Authorization, environment, access, or a declared constraint prevents a legitimate decision. |
The deterministic engine
Applicability is computed, not narrated. Each catalog record declares capability_tags and a rule such as ANY_CAPABILITY_PRESENT; the engine resolves those against the architecture evidence gathered during mapping.
python scripts/applicability.py --helpschemas/applicability-input-v1.schema.json takes the scope, the architecture, and any explicitly blocked hypotheses. schemas/applicability-output-v1.schema.json returns the catalog version, the scope ID, the engine identity, an authorization flag, a summary, and the per-hypothesis decisions.
- The reason code is retained, so a NOT_APPLICABLE can be audited later.
- The capability states are retained, so the decision can be recomputed when the architecture changes.
- Evidence references are retained, so the decision points at what it was based on.
- Because the engine is deterministic, the same input produces the same coverage decision across models.
Priority order
Applicable hypotheses are then prioritised by potential impact and reachability, in this documented order.
- 1
- Authentication and session compromise
- 2
- Authorization, BOLA, BFLA, tenant isolation
- 3
- Money, payouts, refunds, inventory, provider side effects
- 4
- Injection, SSRF, file-processing boundaries
- 5
- Race conditions, idempotency, retry, restart
- 6
- Secrets, cryptography, supply chain
- 7
- Browser and client boundaries
- 8
- AI, agent, MCP, tool boundaries
- 9
- Cloud, CI, release configuration
- 10
- Privacy, logging, operational exposure
The coercion rule
The single rule that gives the coverage model its value: never coerce UNKNOWN or BLOCKED into NOT_APPLICABLE. It appears in the skill, in the command recipes, in the CI policy, and in the gate implementation, because it is the cheapest way to make a report look clean.
The parallel rule on the verification side is: never turn LIKELY_BUT_UNPROVEN into VERIFIED to satisfy a release gate.
Coverage in the report
The canonical report carries a coverage object keyed by the four applicability states plus a total and an integrity_critical_unknown flag. That flag is what lets a policy turn an unresolved integrity-critical area into INCOMPLETE or BLOCKED rather than a silent pass.