Program Rubric Lookup

Map a finding to the target program's accepted vulnerability classes, severity language, payout rubric, and submission requirements.

Inputs

• The exact program policy or ruleset, with retrieval date and provenance.
• A concise finding statement, affected asset, impact, and prerequisites.
• Any explicit exclusions, safe-harbor conditions, or severity overrides.

Method

1. Confirm the asset and vulnerability class are in scope before scoring.
2. Extract the program's controlling severity rubric and any class-specific caps.
3. Map each claimed impact to one quoted or precisely cited rubric clause.
4. Record exclusions, prerequisites, and ambiguity separately from the score.
5. Produce a conservative classification and identify what evidence would raise or lower it.

Acceptance

• Every classification cites the governing policy text and retrieval date.
• Scope, severity, payout eligibility, and submission requirements are distinct fields.
• Unsupported impact is marked unproven rather than inferred.
• Conflicts between generic scoring and program-specific rules resolve in favor of the program rules.
• The evidence contract is an output, not an assumption. Record, as separate fields: the program type and payout model; the authoritative target and what makes it authoritative (repo@commit, deployed address, host or build, binary hash); the PoC forms the program's own text accepts; and the forms it explicitly forbids, each tied to the clause that says so.
• Where the program is silent, write "not stated" — never infer a restriction. A generic or internal grading heuristic is not a program rule. Do not conclude from one that a live-chain transaction, a particular tool, or a production crash is required when the program's published text asks only for a working proof of concept. Inferring such a requirement has already sent a campaign chasing evidence nobody asked for.

Payout topology (AUD-11)

There is no universal severity-to-dollar table — rewards are program-specific. Record, alongside the rubric:

payout_model: fixed_per_severity | range_per_severity | critical_only | contest_pool | unknown
payout_source: exact program clause + retrieval date
marginal_reward_notes: duplicate handling, pool dilution/uniqueness rules, PoC eligibility conditions

Payout topology is an operator SELECTION fact, never a pre-hunt kill list. It informs which program to enter; it never prunes what may be hunted, chained, or banked inside one.

critical_only programs — the disqualifier checklist (AUD-12)

On a critical_only program the grader closes a genuine sub-Critical finding as Informative, not out-of-scope, when “the trigger is not attacker-controlled, impact is off-chain/liveness/MEV, PoC exercises out-of-scope contracts, or the finding requires developer error as proximate cause.” Produce this checklist at Phase 1, so the hunt aims at the step function rather than discovering it at submission time. The finding must survive all four:

• Attacker-controlled trigger — not a privileged, accidental, or operator-only one.
• Direct user fund loss or permanent lock — not liveness, not MEV, not off-chain, and not a protocol-insolvency abstraction.
• In-scope-only PoC surface — the PoC exercises no out-of-scope contract.
• No dependence on an assumed developer or configuration error as proximate cause.

This is impact-validator's G1 applied with the program's own words. It sets what a hunt aims at; it is not a fifth exclusion ground and it never removes a banked primitive.