Evidence review and corrections

What we review

Send the report URL, the specific statement or input you dispute, and evidence or a reproducible check to support@firepan.com. Include the chain, contract address, and relevant observation date. A GitHub source link with a commit and file reference can help us verify a code claim.

We review the challenged statement and its dependent outputs. We prioritize requests by materiality, reproducibility, and the number of reports a shared defect may affect. This review does not automatically include a new code audit, an unrestricted manual investigation, or a rescan with a newer model.

When a score changes

Published scores remain unchanged unless verified evidence changes a scored input under the applicable methodology. When it does, we recalculate and explain the result. Wording and provenance corrections can leave the score unchanged. We do not retain a known erroneous penalty or add an offsetting adjustment to preserve a number.

Missing evidence is shown as unavailable or unresolved. It is not measured zero, proven absence, or proof of EOA control. A provider heuristic is identified as such; it does not establish the specific power or code path that triggered it.

Dates and consistent treatment

We preserve historical snapshots and record the date, evidence, scope, and score effect of a correction. A correction date is distinct from a rescan date. Shared defects are reviewed across affected reports, regardless of whether each project requests a correction.

Correction eligibility does not depend on payment, project prominence, or purchasing an audit. Submitted audits may be considered after their scope and provenance are verified under the normal methodology. Purchasing or submitting an audit does not guarantee a score increase. Commercial follow-up is separate from the factual review.

Worked examples: Flying Tulip and crvUSD

These examples show why the same correction policy can produce different numerical outcomes.