insurouter

How this site works

How we fact check

Facts are researched before they are written, not written and then cited.

Status of the systems described here

4 of 4 switched on

Running now

Re-verification of stored facts against their sources, run on demand rather than on a schedule
Change history recorded for every field change
Automated editorial runs, QA checks and publication blockers
A human review queue where held items land, which a person opens, reviews against the evidence and settles

Research comes first

We do not draft a factual statement and then look for a citation to attach to it. Research happens first, and the resulting evidence is what the writing is built from. This ordering matters: a citation added afterwards can make an unverified statement look verified.

What we store for every fact

The specific attribute and its value.
The source URL, title, publisher and type.
A verbatim excerpt from that source supporting the value.
The date we retrieved it, and where available the date the source published it.
An effective date and expiration date where the fact is time-bound.
A confidence level and a verification status.

Re-verification

Every fact is stored with a freshness class and a date it is next due to be checked: fast-moving facts monthly, medium ones roughly every four months, slow-moving facts such as a founding year annually. Those dates are recorded on each claim today, and you can see the date a fact was last verified wherever it is displayed. No job re-runs those checks yet, so treat a due date as when a fact is scheduled to be re-checked, not as evidence that it has been. When the job is running, a re-check that finds a change is designed to update the record, write the change to a history log with its source, and update only the affected parts of affected pages.

How our re-checks reach your site

If you publish a page we cite, the re-check will appear in your access logs as InsuranceCompassFactCheck/0.1 (+https://insurouter.com/fact-checking/). Most re-checks are an ordinary request for the page. When that request comes back with nothing readable in it, which is what happens on a page whose text is drawn by JavaScript, we load the same URL once in a real browser and read what the page itself rendered. We check your robots.txt first and do not load a path it disallows for that name.

That second attempt is a browser and nothing more. We do not disguise it as a person, we do not solve challenges, we do not retry from another address, and we do not work around bot protection of any kind. A site that declines the request has answered it: the fact stays as it was, nothing is marked stale on the strength of a page we could not read, and the source goes to a person to look at. If you would rather we did not re-read your pages at all, a disallow rule for that name is enough.

When we will not publish

These are the rules automated publication is built to enforce. They block a page when any of the following is true.

A material claim lacks adequate evidence.
Authoritative sources materially conflict.
A state-law interpretation is uncertain.
The page would substantially duplicate an existing page.
A monetization relationship would be misrepresented.
An unsupported savings or rate claim is present.
Critical technical checks fail.

Blocked items are designed to go to a human review queue rather than be published on a timer. No automated run has published anything here yet, and no such queue is being worked yet, so nothing on this site has passed through either.

Numbers and statistics

Any material statistic carries its source, its date, and the population or geography it describes. A number without those three things is not useful, and we do not publish one.