How cases are sourced, reviewed and labeled.
Everything here is already on the public record: real social engineering incidents, plus research and advisories. We draw on court records, regulatory filings, company disclosures, research papers, and news reporting. Each citation is marked primary or secondary. That label tells you how close the source is to the event. It doesn’t vouch for every claim in a case.
Incidents and research or advisory records are kept apart. A lab experiment, a vendor’s observation, or a fraud report covering thousands of victims isn’t the same as a confirmed attack on one organization, so please don’t read it that way. Tags describe a record. They don’t tell you how common something is.
AI tools helped with research, drafting, and review. When we went back over that earlier work, we found factual mistakes, leaps the sources didn’t support, privacy problems, and verification labels that claimed too much. So we don’t take an old automated verdict, a link that still works, or a quote that matches as proof that something’s right.
Here’s how pages get made now. AI helps draft or rewrite each one, following written editorial rules. A separate review then checks it against the primary sources it cites. A person on the SEE team approves it before it’s published or opened to search engines. If a page can’t add anything useful beyond what’s already out there, it gets merged or held back.
Fixing a record starts with the saved source evidence and the specific problem to solve. A separate review checks any proposed change against that evidence. The coordinator then decides which corrections hold up, checks the updated record, and logs anything still unresolved. A focused review only covers the claims it was given. It doesn’t mean every other claim got rechecked. And reusing an old source snapshot doesn’t mean someone reconfirmed the current legal status.
Each source snapshot logs what happened when it was fetched, with a timestamp and a hash. A failed request, a blocked page, a missing quote, and a dead link aren’t the same thing. A page that won’t load doesn’t disprove a claim on its own. And if we can’t confirm an updated court outcome or another key fact, we mark it unresolved instead of guessing from silence.
People oversee the process and decide what gets published. That doesn’t mean a person read every citation from scratch, or that a second AI review catches every error. If you’re using a claim in your own research, go to the cited primary record and check the review date.
An allegation isn’t a charge, and a charge isn’t a conviction, so we keep allegations, charges, convictions, dismissals, and court orders distinct. Each one reflects the dated record we cite. It isn’t a promise about what happened in court later. When accounts conflict, we say who said what.
We don’t name victims, people who were impersonated, or employees who were tricked into acting on a request. That holds even if they appeared in court or spoke publicly later. Other people can be named, but only with their correct legal status. Source titles and bylines stay as published, because they’re part of the citation.
Money stolen, money recovered, an approved insurance claim, insurance actually paid out, restitution, forfeiture, and wider estimates are all different numbers. Always read a figure alongside its basis and note. A court ordering someone to pay doesn’t mean they paid. An approved claim isn’t necessarily money back. And a missing loss figure doesn’t mean nothing was lost.
We use the currencies and conversions the sources print. We don’t invent our own exchange-rate conversions to fill gaps. Totals and modeled estimates are labeled as such. Don’t add them to individual incident losses without first checking what each one covers and where they overlap.
The case write-up tells the story in order. A single sortable year can’t hold every incident date, disclosure, and court date. Tags can overlap, so totals by category aren’t separate, non-overlapping groups.
Spotted an error, a misleading attribution, or a broken citation? Email hello@diopter.ai, and include the case and a supporting source if you can. Significant changes are tracked in the release record. If you plan to use the library for aggregate analysis, read the limitations page first.
Social Engineering Examples