How Shark Incidents Are Investigated and Verified

Original visual: verification-state flow diagram.

How Shark Incidents Are Investigated and Verified

The first public description of a shark incident is rarely the final one.

Breaking reports may contain the wrong beach, a guessed shark species, an uncertain injury description or conflicting accounts of what happened before the bite. A responsible database must be able to publish useful current information without pretending that uncertainty does not exist.

Shark Incidents uses a staged verification model.

Step 1: discovery

Automated monitoring finds a possible incident through public news and information sources. At this point the record is a private candidate, not a published fact.

The system checks whether the story appears to describe a shark-human incident rather than a sighting, fishing catch, old anniversary story, fictional event or unrelated use of the word “shark.”

Step 2: duplicate detection

A major incident can produce dozens of nearly identical stories.

The system compares date, location, named entities, activity and source URLs to determine whether a candidate belongs to an existing record. Multiple news reports should strengthen one incident record, not create multiple map pins.

Step 3: source evaluation

Sources are not treated equally.

An official beach authority, coast guard or police statement is stronger for basic event facts than an anonymous social-media post. A reputable local report quoting named officials may be valuable. A copied article that merely repeats another outlet adds little independent corroboration.

The database records which source supports which fact.

Step 4: location and date normalization

Incident locations are often imprecise. A report might say “near a beach,” “off the coast” or name only a region.

The database preserves that uncertainty. A region-level report should not be converted into a precise pin on a random section of beach.

Dates are handled similarly. Historical records may be known only to a month or year.

Step 5: species confidence

Species identification is one of the easiest details to overstate.

Witnesses may describe color, size or shape without enough information for a reliable identification. Early media reports may call a shark a great white, tiger or bull shark and later correct the story.

Shark Incidents separates the text originally reported from the normalized species field and assigns a confidence level: confirmed, probable, reported or unknown.

Step 6: public status

A credible single-source report can be published as Reported when the event is useful to show promptly and the page clearly communicates uncertainty.

A record becomes Corroborated when independent credible reporting or a primary authority supports the core event.

A record becomes Verified only when the evidence is strong enough under the site's methodology.

Records can also become Disputed or Retracted when later evidence undermines the original claim.

Step 7: continuing review

Publication is not the end of the process.

Developing incidents should be checked again as authorities, medical services, investigators or specialist organizations publish more information. A page's species, classification, outcome or location can change.

Every incident page therefore includes a last-reviewed timestamp and a source list.

Why this matters

A fast map that is wrong is not useful. A perfect database that updates months late is not useful either.

The staged model allows Shark Incidents to be timely while making uncertainty visible. Readers can distinguish a fresh report from a well-investigated record instead of seeing every marker presented with false confidence.

---