Corrections policy

A correction is warranted when a fact on the site does not match the underlying disclosure or price record. That includes:

• Data mis-extraction: a ticker, dollar amount, funder, or promotion date parsed incorrectly from a disclosure.
• Wrong entity attribution: a deal attributed to the wrong operator, promoter, or issuer.
• Missed dedupe: the same underlying deal counted more than once, or two genuinely distinct deals collapsed into one.
• Stale or broken disclosure link: a source link that no longer points to the disclosure it cites.

Some things are disagreements, not errors, and we will not change the data for them:

• Disagreement with a grade. Grades are our opinion, derived from the disclosed-deal outcomes shown beside them (see the grade inputs). A grade you dislike is not a factual error. But if the underlying deals feeding it are wrong, that is, and we will fix those.
• Disagreement with the methodology. How we define a deal, a peak, or a fade is documented on the methodology page. Preferring a different definition is not a correction.
• The outcome itself. We report what the price did; a promotion performing poorly (or well) is a fact we recite, not a claim we can amend.

Anyone named in the data (operator, funder, or issuer) has a right of reply. Email [email protected] with:

• the promotion, ticker, or page in question;
• the specific field you believe is wrong;
• what it should say, and, if you have one, a link to the disclosure or record that supports the correction.

We check every dispute against the underlying document before changing anything.

We review disputes promptly and in good faith. If a dispute identifies a genuine error, we correct the data and note the change (see below). If we conclude the data is accurate as published, we will say so and point to the disclosure it rests on. Either way, the exchange is about the record, not the opinion we draw from it.

When we correct a material data point, the affected page carries a brief editor’s-note line recording that it was corrected and when, so the change is visible in context, not silently overwritten.

Every correction is also recorded, in reverse-chronological order, alongside product updates on the changelog. One stream, so the full history of what we changed and why is public in a single place.