Fact API architecture for evidence-first applications

One name, several different tasks

A Fact API can mean an interface to structured records, a search over published fact checks, or a system that evaluates claims against evidence. Start by naming the task your application actually performs. Extraction identifies a statement. Retrieval finds material. Assessment compares the two. The response should preserve those boundaries so a consumer cannot mistake a search result for a completed verification.

For a developer, that means a documented data contract. For an editor, it means a result with an inspectable source and a limited conclusion. For a researcher, it means knowing exactly which document version and passage were used. This site provides independent architecture guides and illustrative examples; it does not expose a hosted fact-checking endpoint.

A proposed evidence-first architecture

Give each claim a stable local identifier and preserve its original wording. Connect it to source records and to the exact passages considered during an assessment. Keep the assessment separate from the source so a later check can reach a different conclusion without overwriting the material used earlier.

Use separate processing and assessment fields. An inaccessible document is an operational issue, not evidence that a claim is false. An ambiguous entity may need clarification before retrieval. A claim with no adequate evidence should remain unresolved rather than receive a decisive label for the sake of a cleaner interface.

In our example contract, the assessment vocabulary is supported, contradicted, and insufficient_evidence. These are local design choices describing a relationship to an evidence set. They are not a guarantee that every possible relevant source has been inspected.

Search for reviews without inventing a verdict

Google’s Fact Check Tools documentation describes a claim-search API for retrieving existing fact-check results. Use that distinction when planning integrations: finding a published review is a different operation from performing a new check. Keep the publisher’s claim and original rating attached to the retrieved review.

For broader verification, define the permitted sources, the scope of each claim, and the reviewer’s role. Avoid a product promise that extends beyond the evidence collection or evaluation you have actually tested. A narrow, auditable first release is a better engineering target than an undefined promise to resolve any claim on the internet.

What a caller should be able to inspect

Return the statement, source identifier, passage locator, assessment, rationale, and time of the check. Add explicit limitations when the evidence is incomplete or access fails. Make version information available when a later change could affect the conclusion. Prefer a specific explanation of what the passage establishes to an unexplained percentage.

The caller should be able to display a result without concealing uncertainty. Keep the evidence near the claim and make correction pathways easy to find. A useful API makes human judgment more informed, not harder to exercise.

Start with a bounded evidence pack

Choose one document collection and a small set of reviewed examples. Include easy support, direct contradictions, missing information, date mismatches, and nearly identical entities. Compare each pipeline stage separately before integrating the result into a publishing workflow.

Read the Fact API fundamentals article for the full walkthrough. Then inspect the illustrative JSON contract and the structured-data guide. The durable product is the evidence trail: what was checked, what was found, and what the evidence did not resolve.