FactAPI.com — The Evidence Journal

Online Fact Checks & Snopes: Keep the Context

Sun, 09 Aug 2026 12:00:00 +0000

An online fact check is most useful when you understand the exact claim it examined. A headline, rating badge, or search snippet may omit the qualification that explains the result. Before reusing a review in an article or an automated workflow, compare the wording, date, and context of the original claim with the statement you are checking now.

This guide uses Snopes as a reference point for reading published fact checks carefully. FactAPI.com is independent of Snopes and does not claim a partnership, access to a private Snopes feed, or an official Snopes API. The workflow below is an editorial and engineering checklist for finding relevant reviews without stripping away the context that makes them meaningful.

Begin with the specific wording under review

Snopes’ explanation of its fact-check ratings emphasizes that ratings evaluate the particular claim statement on a fact check. That is the key principle to preserve when you reuse a result. A rating should travel with its claim, not become a free-floating label attached to any similar sentence.

Write down the statement you are checking before searching. Include the named people or organizations, the relevant date, and any condition that changes its meaning. A claim that something happened once differs from a claim that it happens routinely. A statement about an old policy differs from a statement about a current policy. Similar keywords do not establish that two claims have the same scope.

Search for the claim, not just the topic

Use the distinctive parts of the statement to find candidate reviews. Search a quoted phrase when wording matters, then try variants for names, dates, and central relationships. If the claim concerns an image or a quotation, keep its accompanying caption or attribution in the search record. The same media item can circulate with different claims attached.

Treat search results as discovery aids. Open the full review before adopting a conclusion. A snippet can omit a correction, a condition, or the part of the analysis that distinguishes a genuine quotation from a misleading interpretation. Keep the candidate review’s URL and title, but do not mark the new claim assessed merely because a search result looks relevant. The review still needs to be compared with the specific statement at hand.

Read the evidence and explanation behind the rating

Identify what material the reviewer used and which part of the claim the evidence addresses. Look for original records, direct statements, images in their original context, and explanations of what could not be established. The value of a review lies in its reasoning and evidence, not only its endpoint label.

Separate the claim being quoted from the conclusion being reached. A fact-check article may reproduce a false assertion in order to analyze it. A retrieval system that selects that quotation without the surrounding evaluation could mistakenly treat the rumor as support. Store a passage’s role in your review notes: original claim, quoted source, analysis, limitation, or conclusion. This makes later summaries less likely to reverse the article’s meaning.

Check time and context before carrying a result forward

Record when the claim circulated, when the review was published, and whether the review identifies a later update. A factual conclusion can be tightly tied to a particular period. A review of whether an organization had announced a project at one time does not automatically resolve whether it announced the project later.

Consider a fictional example: a review establishes that a widely shared photograph shows a 2018 exhibition, not a newly opened event. That review may help identify the image, but it does not by itself answer every later question about the exhibition or the venue. Carry forward the narrow conclusion the evidence supports. Recheck the underlying sources when the new statement concerns a different date or makes a broader assertion.

Preserve a publisher’s rating vocabulary

Do not assume that every publisher’s labels can be mapped safely onto a single true-or-false switch. Keep the original textual rating and the original claim wording in separate fields. When a product needs a normalized status, document the mapping and retain the source label so that reviewers can inspect what was changed.

Use a distinct field for your own assessment of relevance. “Published review found” does not mean “this claim is supported,” and “review only partly matches” does not mean the publisher was uncertain about its original claim. These are different relationships. A good interface shows the source’s conclusion about its claim and your application’s assessment of whether that review applies to the present question. Avoid presenting your normalization as the publisher’s own words.

Compare independent evidence when the stakes warrant it

For a consequential claim, follow the review’s reasoning back to the underlying material where possible. Ask whether the original record supports the interpretation and whether another relevant source changes the context. Multiple pages repeating the same report should not automatically be counted as independent corroboration.

Record disagreements precisely. Two reviews may use different wording, examine different dates, or answer different questions. Compare those boundaries before declaring a contradiction. When sources genuinely conflict, preserve the conflict and explain what remains unresolved. Do not settle it by counting websites or asking an LLM to choose whichever explanation sounds more persuasive. A careful comparison is about evidence and scope, not the volume of repeated assertions.

Design automated discovery with a narrow promise

An automated system can help organize candidate reviews, extract metadata, and flag possible matches. Describe it as discovery unless it also performs and evaluates the assessment step. Keep a human-review path for ambiguous matches, changing claims, and excerpts whose context is difficult to preserve automatically.

Do not invent an endpoint or assume a public integration exists for a named publisher. Check current documentation and permitted access before building an integration. Respect the source’s access conditions and retain only the content your use permits. A link to a published review is not permission to reproduce an entire article. The safest technical contract is explicit about what it retrieves, what it stores, and what it asks the user to inspect directly.

Keep a compact review record

A useful record includes the incoming claim, the candidate review, the claim actually reviewed, the original rating, the publication or update information, and a note about the match. Add the source passages that matter and a conclusion limited to the new question. This structure gives another reviewer enough information to understand why the review was used.

Record an unresolved result when no sufficiently relevant review is found. Lack of a published fact check is not proof that a claim is true or false. It may simply mean the claim has not been reviewed, is hard to find, or falls outside the searched collection. Distinguish that outcome from a technical search failure. The difference determines whether the next step is broader research, a retry, or a request for more context.

When summarizing a review, keep the claim, date, and key limitation close to the conclusion. Avoid turning a nuanced analysis into a slogan that says more than the evidence establishes. Where the new statement differs materially from the reviewed one, describe the earlier review as relevant background rather than as a direct verdict on the new claim.

Use the online fact-checking guide for the review checklist and the structured fact-data guide for preserving source labels and assessment relationships. A responsible truth check does not borrow authority from a recognizable publisher’s name. It carries forward the actual reasoning, the exact claim, and the limits that make the original review intelligible.

Fact Citation AI: Evidence-Grounded Answers

Tue, 04 Aug 2026 12:00:00 +0000

An evidence-grounded answer should be built from inspected source material, not written first and decorated with plausible references afterward. That principle is easy to state and easy to violate. A system may retrieve relevant documents, produce a fluent response, and attach citations that discuss the topic without supporting the specific sentences beside them.

This article outlines a proposed workflow for fact citation AI and LLM citation checking. The emphasis is on the relationship between claims and passages: selecting evidence, drafting within its limits, and checking the final answer again. It is an architecture guide rather than a claim that retrieval alone eliminates unsupported output or that a citation marker turns an answer into a verified fact.

Evaluate citations separately from fluency

The ALCE research paper on text generation with citations introduces a benchmark and evaluation dimensions covering fluency, correctness, and citation quality. The separation is useful: a readable answer and a well-supported answer are not the same evaluation target. Citation quality needs its own inspection rather than being inferred from polished writing.

For your workflow, define whether you are checking the correctness of each attached citation, the coverage of claims that need citations, or both. A response can cite one sentence accurately while leaving its most important assertion unsupported. Conversely, every sentence can contain a citation marker while none of the cited passages justifies the actual wording. Keep those failure types separate in the review interface.

Establish a source collection with visible boundaries

Before generation, define which material the system is allowed to use and what the collection is intended to cover. Record source identifiers, titles, version information, and access conditions. A private knowledge collection and an open-web search have different coverage and privacy implications. Do not let the answer imply that it searched sources it never accessed.

Set rules for conflicting, outdated, and low-relevance material. A retrieval system should not silently treat every retrieved passage as equally authoritative. A useful design can retain candidate passages while showing which ones were selected and why. The selection rationale should reflect the task: an original methods section may matter more than a promotional summary when the question asks how a study was conducted.

Retrieve passages that can answer the actual claim

Form retrieval queries around entities, relationships, dates, and qualifiers, not only the broad topic. If the question concerns a project’s launch year, a document about its current features may be relevant to the project but irrelevant to the date. Keep the user’s scope intact when refining the query.

Check the retrieved material before drafting. Does it address the requested comparison, population, or period? Is a key table missing from the text extraction? Are two passages discussing different versions of the same system? Return a narrower answer or an explicit gap when the available material does not cover the question. The goal is not to maximize the number of retrieved passages; it is to assemble evidence that can support a useful response.

Draft from an evidence map

Create an intermediate map connecting proposed claims with source passages. Each claim should have at least one candidate support relationship or an explicit unresolved status. This map gives the generator a more precise task than “answer the question and add citations.” It also provides an object that a reviewer or a second checking stage can inspect.

In a fictional archive example, the map might connect a launch-date claim to a release note and an export-format claim to a technical specification. It should not let the release note support both claims merely because the same project appears in each document. Keep a short support explanation with each mapping. If the explanation requires assumptions not present in the evidence, narrow the claim or mark the relationship for review.

Keep citation markers close to the assertions

Place citations where readers can tell which statement they support. A paragraph containing several independent claims should not end with an ambiguous cluster of references unless the relationship is genuinely clear. When one passage supports only part of a sentence, split or qualify the sentence rather than implying broader support.

Provide a readable reference entry and a precise locator. A link to a large document may identify the work but still leave the reader unable to find the relevant passage. Avoid exposing internal retrieval identifiers as the only citation label. The public reference should be meaningful to a person, while the internal record preserves the stable identifiers needed for updates, evaluation, and debugging across versions of the answer.

Check the finished answer, not only the draft plan

Generation can introduce wording that was not present in the evidence map. A final checking pass should extract the answer’s actual assertions and compare them with the attached passages. Watch for added dates, stronger causal language, broadened scope, and compressed summaries that drop important qualifications. The initial plan is not enough when the final prose changes the meaning.

Return specific repair suggestions. A citation might be correct but incomplete, a sentence might need narrower wording, or a passage might contradict the response. Preserve unresolved issues instead of forcing the checker to produce a binary label for every statement. If the answer is revised, check the revised version too. Otherwise, a repair can introduce a new unsupported claim while appearing to close the original warning.

Protect the boundary between sources and instructions

Treat retrieved documents as material to examine, not as instructions controlling the assistant. A source can contain arbitrary text, including content that asks the system to ignore its task or reveal private information. Keep that material separate from trusted application instructions and limit the actions available to a component that processes it.

For a production design, test source passages that contain irrelevant directives and verify that the system continues to follow the intended evidence task. Do not place secrets in the retrieval context. Log the source selection and the final assessment in a way that supports investigation without unnecessarily retaining private content. These are proposed engineering safeguards; their adequacy must be tested against the actual application and its permitted actions.

Measure answer usefulness and evidence discipline together

A system that never makes a claim may avoid unsupported assertions while failing to help the user. Evaluate whether the answer addresses the question, whether consequential claims are covered, whether citations support the wording, and whether uncertainty is communicated honestly. Keep these dimensions separate long enough to understand their tradeoffs.

Build a reviewed test collection containing answerable questions, partially answerable questions, and questions outside the source collection’s coverage. Compare retrieval versions and generation configurations against the same collection. Include reviewer effort in the operational scorecard. An answer that requires extensive manual repair may not be a practical improvement even when its initial automated score looks attractive. Inspect changed examples rather than deciding solely from an average.

Make citations a navigable evidence trail

The finished experience should let a reader move from answer to claim to passage to source. It should also show what the system did not resolve. That is a more useful outcome than a decorative bibliography or a confidence percentage whose basis is hidden. The evidence map becomes both a review tool and a maintenance tool when a source later changes.

Explore the LLM fact-checking workflow and the citation-checker layers to connect generation with review. For the underlying response structure, use the illustrative JSON contract. The central design rule is simple: write within the evidence you have, check the words you actually publish, and leave visible space for what the evidence does not establish.

Structured Fact Data: JSON & Provenance

Sun, 12 Jul 2026 12:00:00 +0000

Structured fact data is most useful when it preserves the difference between a statement, a source, and an assessment. A single object that mixes all three may look convenient at first, but it becomes difficult to update when a source changes or a reviewer reaches a different conclusion. A more durable design treats the evidence relationship as a first-class part of the record.

This article develops a proposed JSON design for evidence-oriented applications. The field names are illustrative rather than an industry standard or a live FactAPI.com endpoint. The goal is a record that can be read by a developer, reviewed by an editor, and revisited after an update without requiring everyone to reconstruct the original decision from a chat transcript.

Start with provenance rather than a truth score

The W3C PROV overview describes provenance in terms of information about entities, activities, and people involved in producing something. That framework is a useful reference for deciding what an evidence record needs to explain: what material was used, what process acted on it, and who or what was responsible for the resulting assessment.

You do not need to implement the full PROV family to adopt that habit. Begin with a source entity, an assessment activity, and an accountable reviewer or system version. Make the relationships explicit. A number such as confidence: 0.94 explains none of those relationships by itself, and should not substitute for the evidence needed to understand a result.

Give claims and sources different identifiers

A claim identifier should remain stable across repeated checks of the same precisely defined assertion. A source identifier should refer to a document or source record. An evidence identifier can refer to a particular passage within a particular version of that document. An assessment identifier then connects a claim with the evidence considered in one check.

This separation helps when a single source supports multiple claims or a single claim requires several sources. It also prevents accidental overwrites. For example, a new assessment of the fictional Meridian catalog’s opening date should not silently replace the source record used in an earlier assessment. Document whether identifiers are assigned locally, derived from content, or supplied by an external registry. Do not imply that a local identifier is globally resolvable.

Preserve both original and normalized wording

Use a claim_text field for the statement under review and a separate original_span field for the passage from which it was extracted. Add normalized wording only when your application needs it for search or matching. Keep the original entity names, qualifiers, and attribution recoverable even when the normalized representation uses canonical identifiers.

Time and scope deserve their own treatment. A claim about a project’s size at launch is different from a claim about its present size. A claim about a sample is different from a claim about an entire population. Represent those distinctions in readable text even when you also add structured fields. Consumers should not have to inspect an undocumented numeric code to discover that the assessment applies only to a narrow context.

Represent evidence as a relationship

Each evidence item should say which claim it addresses and what relationship it has to that claim. Useful local labels include supports, contradicts, and provides_context. Define these labels in the schema documentation. Do not make a citation’s mere presence equivalent to support; a document may discuss the topic while failing to justify the specific assertion.

Include the source title, locator, version information where available, and a retrieval time. Store a passage when permitted and useful, or a reproducible pointer when you cannot retain the content. Distinguish an unavailable passage from an empty passage. An application that failed to retrieve the text should not report that the source contains no relevant evidence. Access status belongs beside, not inside, the factual assessment.

Keep assessment labels and processing states apart

Use assessment.status for the evidence-based conclusion and a separate processing field for completion, failure, or partial work. In the accompanying illustrative schema, assessment labels are supported, contradicted, and insufficient_evidence. They are local contract choices, not claims about a universal taxonomy. A human-review flag can coexist with any of them.

Reserve null values for genuinely unknown or unavailable information and document their meaning. Zero, an empty string, and null should not be interchangeable. A missing date is not a date of zero, and an uncalculated score is not a score of zero percent. This distinction becomes important when downstream software sorts records, computes totals, or decides which items need attention. Make invalid states difficult to express.

Separate the dates that answer different questions

A robust record may need a source publication date, a source revision date, a retrieval timestamp, an assessment timestamp, and the period addressed by the claim. These values answer different questions. Retrieving an old document today does not make its findings current, and checking an assessment today does not prove the underlying source has been revised.

Use explicit timezone-aware timestamps for events where the time matters. Preserve date-only values as dates rather than inventing a midnight timestamp that suggests greater precision. A date’s provenance should be visible when it was inferred from text instead of supplied by the publisher. For changing claims, define when an assessment becomes stale and who decides whether a new source check is needed.

Version the schema and the assessment process

Place a schema_version in the response and publish a compatibility policy. Adding an optional field is different from changing the meaning of an existing status. Decide how clients should handle unknown fields and labels before introducing them. Validate representative examples against the schema as part of a release check, including incomplete and failed responses.

Record the versions of the extraction, retrieval, and assessment components when those components influence the result. Avoid placing private prompts or credentials in public records. A concise configuration identifier can point to controlled internal documentation. The audit goal is to make a decision reproducible within the authorized environment, not to expose every operational detail to every consumer. Keep public explanation and internal debugging metadata appropriately separated.

Design updates without erasing history

Treat a correction as a new assessment linked to the previous one, with an explanation of what changed. A source revision, a reviewer correction, and a newly discovered contradictory document are different reasons for an update. Preserve that reason so downstream applications can determine whether to refresh a badge, notify an editor, or reopen a dependent article.

Use explicit supersession relationships instead of relying on whichever record happened to arrive last. A delayed message should not overwrite a newer assessment. Decide whether a client requests the current view, the full history, or a view as of a particular date. For small static examples, the distinction can be documented without implementing a database. For a production service, it belongs in both the data contract and the tests.

Test whether someone else can reconstruct the check

Take a completed record and give it to a reviewer who did not create it. Can they identify the exact claim, locate the evidence, understand the scope of the conclusion, and see why the status was assigned? Ask the same questions after replacing the source with a revised version. Missing context usually becomes obvious during this exercise.

The local JSON examples and schema provide a small starting point. Pair them with the source-watch guide to plan how records change over time. Good structure does not make unsupported statements true. It makes the basis, boundaries, and history of an assessment visible enough for people and software to work with responsibly.

Academic Source Watch: Updates & Retractions

Sat, 20 Jun 2026 12:00:00 +0000

A source watch is a maintenance process for evidence that an organization already uses. It asks what has changed in a source, whether the change affects a claim, and which downstream material needs review. That is different from checking whether a URL still works and different from repeating a search without keeping a record of earlier results.

This guide proposes an AI-assisted journal-article source-watch workflow. FactAPI.com provides the design guidance and local examples, not a live monitoring subscription or automated alert service. The objective is an accountable queue of relevant changes, with enough evidence for a reviewer to decide whether an article, answer, or research note needs correction.

Define what deserves monitoring

Begin with the claims that matter most to your published material or internal decisions. Link each claim to the specific work and version used to support it. Prioritize sources that support consequential conclusions, quantitative statements, or frequently reused explanations. Monitoring an undifferentiated list of every link on a site can create noise without protecting its most important evidence.

A source inventory should include identifiers, titles, access routes, dependent claims, and a review owner. Record whether you monitor the publisher page, a metadata record, a correction feed, or some combination. Those channels provide different signals. A changed page title may be less important than a correction notice, while an unchanged URL can still host a revised document. Make the monitored signal explicit.

Use update metadata as a discovery signal

Crossref’s announcement about Retraction Watch data in its API explains that Retraction Watch retractions and corrections became available through the Crossref REST API. This provides a useful discovery channel for scholarly update workflows. It should be treated as one input to review, not as proof that every possible notice or relevant change is present.

When designing an integration, inspect current documentation and representative records rather than assuming every work has the same fields. Preserve the provenance of each update signal and distinguish a metadata discovery from the publisher’s actual notice. A record that points to a correction is a reason to inspect the correction, not enough information by itself to decide how every dependent claim should change.

Keep a baseline that can be compared

For each source, record the version and metadata available at the time it was used. Where permitted, retain a content snapshot or a hash alongside a readable locator. A hash can indicate that content changed, but it cannot explain what changed. Keep enough structured context for a reviewer to identify the affected passage.

Store retrieval time separately from publication and revision dates. A newly retrieved record may describe an old correction that your inventory has not seen before. Conversely, a document can change without a conveniently labeled revision date. Mark the limits of your baseline. Do not invent a historical state when you only began observing the source recently. An honest monitoring record distinguishes a newly observed change from a newly published change.

Classify events before escalating them

Use a small event vocabulary such as metadata_change, content_revision, correction_notice, retraction_notice, access_failure, and unresolved_signal. Document how those local labels are assigned. A temporary access error should not appear in the same queue as a substantive correction unless the interface makes the difference obvious.

Retain the original notice type and wording beside any normalized category. A correction can range from a minor bibliographic adjustment to a change that affects a central result. A retraction notice also needs to be read for its stated scope and explanation. Do not infer misconduct, invalidity of unrelated work, or the fate of every cited claim from the event label alone. The update is evidence to inspect, not a license to speculate.

Deduplicate without concealing independent signals

The same notice can appear through a publisher page, a metadata service, and a secondary index. Group matching signals under one review event while preserving where each was observed. This reduces duplicate alerts and helps a reviewer understand whether two records describe the same event or different revisions.

Use stable identifiers and explicit matching rules. Similar titles can refer to different works, and the same work can have multiple related notices. Keep unresolved matches in a separate review state. If an event is merged incorrectly, provide a way to separate it again without losing its history. Deduplication should reduce repetitive work, not erase the evidence trail needed to understand an alert later.

Connect each event to affected claims

A source watch becomes useful when it identifies what depends on the changed material. Maintain links from source passages to claims, articles, summaries, and example responses. A correction to one table may affect a numerical statement while leaving a background description unchanged. The review should be specific enough to avoid unnecessary blanket edits.

Consider a fictional archive study that corrects a sample count from 120 to 102. A page repeating the count needs review. A separate page citing only the study’s publication title may not need the same substantive change. An AI component can propose affected claims, but a reviewer should inspect the actual dependencies. Similar wording is a clue, not a complete impact analysis of the argument.

Design alerts for decisions, not alarm volume

Each alert should explain the source, the observed event, the time it was found, the affected claims, and the action requested. Assign a review owner and a priority based on the possible impact. Avoid messages that say only “source changed,” which force every recipient to rediscover the same context.

Set a policy for repeated failures and low-priority metadata changes. For example, a proposed workflow might group minor metadata changes into a periodic review while escalating a relevant retraction notice immediately after confirmation. The appropriate cadence depends on the organization’s risk and resources. Do not promise continuous coverage unless the actual system delivers it. Monitoring frequency and observed delays should be part of the service description.

Record review outcomes and corrections

Possible outcomes include no impact, metadata correction, claim qualification, citation replacement, content withdrawal, or expert review required. Keep the reviewer’s rationale and the source notice with the decision. A closed alert should mean someone resolved its significance, not merely that a notification was dismissed.

When published text changes, connect the correction to the event that triggered it. Preserve an appropriate history and ensure the current page no longer presents a superseded assessment as current. If the alert turns out to be a mismatched work or a false signal, record that reason too. These outcomes form a useful evaluation set for improving matching and prioritization without hiding mistakes in the monitoring process.

For unresolved events, set a next action and a review date rather than leaving an unowned warning in the queue. A reviewer may need the publisher’s notice, an authorized copy of the revised work, or a subject specialist’s interpretation. Keep those dependencies visible. Closing the notification is not the same as resolving the evidence question, and an access problem should not silently erase the obligation to revisit an important claim.

Evaluate the monitoring process itself

Test whether the workflow can find known updates in a controlled collection, match them to the correct works, and identify the relevant downstream claims. Measure unresolved matching cases and reviewer workload as well as discovered events. A noisy system can train users to ignore the very alerts that deserve attention.

The source-watch topic guide supplies a compact operating model, while the structured-data article explains versioned assessments and source relationships. A useful AI source watch does not replace editorial responsibility. It makes change visible, gives that change an owner, and preserves the evidence needed to decide what should happen next.

How to Choose an LLM Fact-Checking Service

Tue, 27 Jan 2026 12:00:00 +0000

Choosing an AI LLM fact-checking service begins with defining the job you need done. A tool that locates existing reviews, a tool that checks an answer against uploaded documents, and a tool that validates bibliography metadata may all be marketed around factuality. They solve different problems and should not be compared as though they offer the same evidence boundary.

This guide proposes a vendor-neutral evaluation process. It does not rank commercial providers, quote current prices, or claim that FactAPI.com operates a hosted verification service. Use the framework to compare documented capabilities with your own reviewed examples, then decide whether the system improves the quality and cost of a real workflow rather than merely producing reassuring labels.

Translate the use case into an evidence contract

Write down the input, permitted sources, expected output, and person responsible for the final decision. An editorial team may need claim-by-claim evidence passages. A research group may need citation identity and study-context checks. A developer may need structured responses that distinguish an unresolved claim from an unavailable source. Those requirements should be visible before a demonstration begins.

Use a scenario specific enough to test. “Make answers more factual” is not an acceptance criterion. “For each checkable assertion in a supplied archive summary, return the supporting passage or an unresolved status” is closer to a reviewable contract. Include what the service must not do, such as use sources outside an approved collection or turn missing evidence into a false verdict.

Ask for an explicit capability boundary

Require a provider to distinguish extraction, retrieval, assessment, citation validation, and source monitoring. Ask which stages are included, which depend on another service, and which require human review. A clean user interface can hide substantial differences in the underlying task. Documentation should explain whether a result is a source match, a model proposal, or a reviewed assessment.

Ask how the service handles ambiguous claims, inaccessible papers, conflicting sources, and changing information. Look for an explicit insufficient-evidence state and operational error reporting. A tool that always produces a decisive label may be inappropriate for a workflow where the available evidence is often incomplete. Do not reward certainty without examining whether the cited passages justify it.

Use a risk framework without treating it as certification

NIST’s Generative AI Profile is a cross-sectoral companion to its AI Risk Management Framework, intended to support consideration of trustworthiness across AI design, use, and evaluation. It is a useful reference for organizing risk questions around the whole application, not only its model output.

For procurement, turn that perspective into concrete questions about intended use, evaluation, oversight, and response to failure. Referencing a framework in marketing does not prove that a product has passed your acceptance tests. Ask for evidence of the controls relevant to your use case and record which claims you have independently verified. A policy document and an operationally tested control are different forms of assurance.

Build a comparison set before seeing the scores

Prepare examples from your actual work, with permission to use the material in the evaluation. Include supported claims, subtle contradictions, absent evidence, difficult entity matches, numerical comparisons, and citations that exist but do not support the wording. Keep the expected evidence and reviewer rationale with each example.

Decide how results will be scored before comparing providers. This reduces the temptation to change the rubric to fit an attractive demonstration. Keep a subset unseen during configuration. If a vendor helps tune the system, distinguish that development set from the final comparison set. Evaluate all candidates against the same source boundary and processing conditions; otherwise, a richer retrieval collection may be mistaken for a better assessment component.

Inspect the evidence behind changed labels

Compare outputs at the claim level. Did the service find the relevant passage? Did it preserve the claim’s date and scope? Did the explanation introduce an unsupported inference? Were citations placed where a reviewer could tell what they supported? A high-level percentage can hide a small number of consequential confident errors.

Pay particular attention to cases that a service marks supported while your reviewers mark unresolved or contradicted. Read the source together rather than relying on the service’s explanation. Also inspect unnecessary abstentions, because a tool can avoid errors by declining useful work. Record disagreement types separately. The goal is to understand the tradeoff between useful completion, evidence quality, and review burden in your specific application.

Evaluate privacy and operational access

Ask what information leaves your environment, where it is processed, how long it is retained, and which parties can access it. Check the actual contract and documentation for your proposed deployment rather than assuming that a general product description applies to every plan or configuration. Do not send confidential material during a trial before those boundaries are approved.

Separate the information needed for assessment from unnecessary personal or sensitive data. Ask whether source content, prompts, outputs, and review logs have different retention rules. Review deletion, access control, and incident-handling arrangements with the people responsible for those decisions in your organization. These are due-diligence questions, not a substitute for professional legal or security review of a particular provider and agreement.

Measure the cost of a reviewed result

Compare the full workflow rather than only a per-request price. Your own cost model may include source retrieval, document conversion, model calls, retries, evidence storage, human review, and correction work. Use measured volumes from a pilot wherever possible. A cheap initial answer can become expensive if reviewers must reconstruct its citations or repair distorted claims.

Build at least a normal case and a difficult case. In an illustrative calculation, ten reviewed items that each require one minute of human work create a different operating burden from ten items that require ten minutes each, even when the API invoice is identical. Label assumptions clearly and update them from observed work. Do not present a hypothetical calculation as a provider’s actual performance or pricing.

Test integration, failure handling, and exit options

Inspect the response schema, versioning policy, documented limits, and behavior under partial failure. Check whether identifiers remain stable, whether evidence can be exported, and whether you can retain enough information to audit prior decisions. A result that exists only as an opaque badge can be difficult to migrate or investigate.

Ask how model and retrieval changes are communicated. A provider update may alter labels even when your application code stays the same. Plan regression checks and a fallback path. Review how you would remove the service or move to another provider without losing your claim-to-source relationships. Portability is not only a commercial concern; it protects the continuity of the evidence trail that your reviewers and readers rely on.

Make a bounded decision after the pilot

Summarize where the service worked well, where it failed, and which cases still require review. Define the approved scope rather than declaring the tool universally reliable. Assign responsibility for monitoring regressions, reviewing corrections, and renewing the evaluation when sources, models, or use cases change. A pilot result is a decision aid, not a permanent guarantee.

Start with the LLM fact-checking evaluation guide and the Fact API architecture overview to define your requirements. Use the illustrative response contract as a discussion aid for structured outputs. The best service for a particular team is the one that demonstrably supports its evidence workflow, exposes its limits, and leaves the final decision understandable after the demonstration is over.

Fact Extraction APIs: Atomic Claims & Context

Sat, 15 Nov 2025 12:00:00 +0000

Fact extraction is the task of turning a passage into statements that can be examined individually. It is a preparation step, not a verification result. An extraction API can identify what a document asserts while remaining completely agnostic about whether those assertions are supported. That distinction matters when the input comes from a generated answer, an advertisement, a journal article, or a copied social post.

The design goal is not to produce the largest possible list of fragments. It is to preserve the meaning of the original text while creating useful units for retrieval and review. This guide presents an implementation checklist for an illustrative extraction workflow, with particular attention to qualifiers, source spans, and the mistakes that can change a claim before anyone checks it.

Separate extraction from verification

The original FEVER research paper describes a fact-verification dataset whose claims are labeled Supported, Refuted, or NotEnoughInfo, with evidence recorded for the supported and refuted cases. Its separation between a claim and the evidence needed to assess it is a useful conceptual reference. Your extraction component should not treat the act of finding a statement as evidence that the statement is correct.

A clean response can therefore say “claim extracted” while leaving the assessment unassigned. Reserve verification fields for a later stage. This avoids an easy integration mistake: a downstream interface sees an object named fact and assumes it has already been checked. Naming the object claim is a simple way to make that boundary more visible.

Decide what counts as a checkable statement

Begin with a written annotation policy. Dates, quantities, reported events, attributed quotations, and descriptions of specific relationships are common candidates. Opinions and preferences may not be independently verifiable, although the fact that someone expressed an opinion can be. “This is the best archive” and “The director called this the best archive” require different treatment.

Define how your system handles recommendations, predictions, and conditional statements. A prediction can be extracted as a prediction without being labeled a present-day fact. A condition should remain attached to its consequence. “The service is free for students” must not become “The service is free.” These examples are not edge cases to hide in a footnote; they belong in the initial extraction specification and the test collection.

Split compound claims without destroying context

Imagine the fictional sentence, “In 2022, the Meridian catalog added four regional collections and introduced a public export.” A sensible extraction might produce one claim about the additions and another about the export, each preserving the year and the named catalog. Removing shared context to make each fragment shorter can make the resulting statements ambiguous.

Use an atomicity rule that favors independent assessment rather than grammatical minimalism. A statement may contain several words or clauses that must stay together to retain its meaning. Record parent-child relationships when a sentence produces multiple claims. That lets a reviewer reconstruct the original passage and lets the publishing interface show that only one part of a sentence remains unsupported. Avoid joining separate clauses simply because they mention the same entity.

Preserve attribution, negation, and uncertainty

Attribution tells you whose assertion you are extracting. “The report estimates ten thousand visits” is not equivalent to “There were ten thousand visits.” Preserve words such as estimates, alleges, projects, approximately, and according to. They change the strength or source of the assertion and may determine what evidence would actually support it.

Negation deserves explicit tests. “No change was observed” must not become “A change was observed,” and “the study did not establish an effect” is not automatically a claim that no effect exists. A useful review view places the original passage beside the normalized wording so that these shifts are visible. Flag uncertain normalizations for review rather than asking a verifier to repair a distorted claim later in the pipeline.

Give every claim a reliable location

Store the original document identifier and a reproducible locator. For plain text, character offsets can work when the text normalization process is fixed. For structured documents, use a section identifier and paragraph reference. If the input is transformed before extraction, preserve the version or hash of the text to which those locations refer.

A locator is useful only when another component can resolve it. Test what happens after whitespace normalization, document conversion, or a new parser version. Do not silently attach offsets from one version to another. Include a short original span in the extraction response when permitted, because it helps reviewers spot alignment errors immediately. The normalized claim and the original span should be separate fields, not alternative values of the same field.

Normalize entities conservatively

A short name may refer to several people, organizations, publications, or projects. Resolve it only when the surrounding text provides enough context or an approved entity reference confirms the match. A model’s familiarity with a popular entity is not a good reason to replace an ambiguous name in the source.

Keep an unresolved identifier when necessary. Record candidate matches separately from a confirmed resolution, and preserve aliases rather than overwriting the original form. Apply the same care to dates, currencies, units, and geographic references. A date written as 03/04 can be ambiguous, and a quantity without a unit may be unusable for comparison. The appropriate response is often to carry the ambiguity forward, not to invent the missing precision.

Control duplicate claims and document scale

Long documents repeat assertions in summaries, captions, introductions, and conclusions. Deduplication can reduce review work, but it should preserve every important source location. Two similar sentences may differ in period, population, or scope. Treat semantic similarity as a candidate for grouping, not automatic proof of equivalence.

For large inputs, process sections with enough surrounding context to retain references and qualifiers. Keep a document-level index so claims from separate sections can be reconciled without losing their origins. Set an explicit truncation status when a processing limit is reached. Returning only the first portion of a document without disclosing that limit can create a misleading impression that the entire document has been inspected. Coverage is part of the extraction result.

Evaluate extraction with a reviewable rubric

Measure whether the output includes the important checkable assertions, preserves their meaning, and links them to the correct text. Review omissions, invented claims, excessive splitting, and incorrect merging separately. A single aggregate score can hide a system that extracts many easy claims while missing the one consequential assertion in the conclusion.

Create a small set of adjudicated examples with original spans and acceptable claim formulations. Include quotations, nested attribution, tables described in prose, uncertain quantities, and references that cross paragraph boundaries. Ask reviewers to explain disagreements about atomicity rather than treating one wording as uniquely correct. An extraction can be semantically faithful in more than one form; the important requirement is that the downstream verification task remains the same.

Define the handoff to the evidence stage

The verification component should receive the original wording, normalized wording, context, location, and any unresolved ambiguity. Include processing metadata that identifies the extraction configuration. Keep extraction confidence, when used, separate from factual support: confidence that a sentence was parsed correctly is not confidence that its content is true.

Document the failure cases that should stop automatic assessment. An unreadable table, missing antecedent, or uncertain entity match may require a reviewer before retrieval begins. Review the fact-extraction topic guide for the field checklist and the structured-data article for a provenance-oriented response pattern. A strong extraction API leaves the next stage with a faithful question to answer, not a polished statement whose meaning has quietly changed.

Academic Fact Checking: Beyond the Abstract

Thu, 10 Jul 2025 12:00:00 +0000

Academic fact checking asks whether a research source supports the way it is being used. A paper can be correctly identified and accurately quoted while still being stretched beyond its methods, sample, or findings. The central task is to connect a precise statement with the relevant part of the scholarly record, then decide whether the statement needs qualification, correction, or stronger evidence.

This guide presents a reading and documentation workflow for journal-article fact checks. It is not a substitute for subject-matter review, statistical expertise, or a full systematic review. Use it to make the chain from claim to source visible, especially when an AI summary has compressed a complex study into a confident sentence.

Identify the exact work and version

Start with the title, authors, identifier, publication venue, and version you actually consulted. Distinguish a preprint from a later journal article, and a correction notice from the original work. Similar titles and overlapping author lists can make related versions easy to confuse. Save enough metadata to let another reviewer locate the same material.

Crossref’s Crossmark documentation describes a mechanism for displaying the current status of scholarly content and linking update information. Where available, that information is useful when checking whether a source has a correction or other update. It is not a guarantee of the paper’s quality, and the absence of an update notice should not be treated as a scientific endorsement of every claim in the work.

Write the claim in a form that can be tested

Copy the sentence under review and identify what it actually asserts. Does it describe an observation, a comparison, a causal effect, a mechanism, or a broad recommendation? Mark the population, setting, period, and outcome. These details determine what kind of evidence would be needed to support the wording.

For example, a fictional report that finds a relationship between catalog training and retrieval speed in one institution does not by itself establish that the training causes faster retrieval everywhere. The statement can often be improved by naming the study setting and using language that reflects the design. Do not begin by hunting for a citation that appears to defend the strongest wording. Begin by asking what the available evidence permits you to say.

Read the methods that define the result

Inspect how the study selected its material, measured its outcome, and constructed its comparison. Check the inclusion criteria and the unit of analysis. A result about documents, users, institutions, or repeated measurements may have different implications. The method is part of the claim’s context, not a detail that can be omitted after finding an attractive number.

Identify what the design can and cannot establish. Record key assumptions and any limitations the authors explain. If the claim depends on a method you cannot evaluate, route that issue to a qualified reviewer instead of assigning a confident support label. A citation review can establish that a paper reports a result while leaving the strength of the underlying methodology open for specialized assessment.

Trace numerical claims to the relevant result

Locate the table, figure, or passage containing the number. Preserve the unit, denominator, subgroup, and comparison period. Check whether the figure is an observed result, an adjusted estimate, a model output, or a hypothetical scenario. An abstract may compress these distinctions in ways that are unsuitable for a precise secondary claim.

When your text derives a number from the study, keep the inputs and calculation. In a fictional example, a change from 20 to 25 items is an increase of five items and a relative increase of 25 percent. Those statements answer different questions from a five-percentage-point change in a rate. Write the relationship explicitly rather than relying on an unlabeled percentage that a reader could interpret several ways.

Distinguish the authors’ findings from their discussion

A paper’s introduction may summarize earlier work, its results report the present analysis, and its discussion propose explanations or future implications. A sentence located anywhere in the paper is not automatically one of the study’s established findings. Identify the role of the passage you are citing.

This is particularly important for AI-generated summaries. Ask the checker to show whether a proposed claim comes from the study’s own results, an attributed statement about another paper, or a speculative explanation. Keep those roles visible in the evidence record. If a passage points to another study as the real source, consult that work when it is necessary for your argument rather than using a chain of secondary references that obscures the original evidence.

Match the strength of the wording to the evidence

Review verbs and qualifiers as carefully as numbers. Words such as proves, guarantees, prevents, and establishes can imply more than a study supports. The appropriate wording may be narrower: reports, estimates, observes, or is consistent with. The right choice depends on the design and result, not on a universal substitution rule.

Check whether an absence of evidence has been presented as evidence of absence. A study that did not detect a difference may not establish that no meaningful difference exists. A result for one outcome may not resolve a broader question. Preserve uncertainty when it is material to interpretation. The purpose of qualification is not to weaken every sentence; it is to make the strength of the claim match the strength and scope of the available evidence.

Consider the surrounding research without pretending to finish it

For important claims, ask whether one paper is an adequate basis or whether the question requires a broader view of the literature. Look for relevant replications, critiques, syntheses, and conflicting findings. Record how you searched and what your review did not cover. A small targeted check should not be presented as a comprehensive systematic review.

Evaluate the relevance of disagreement. Different populations, methods, or outcomes can produce findings that are not directly comparable. Do not average conclusions informally or count papers as votes. A high-quality academic citation is one whose role in the argument is clear: direct evidence, methodological context, contrary evidence, or background. That clarity is more valuable than a long reference list whose individual connections to the claim are vague.

Document the decision and the unresolved questions

Use a review record with the claim, exact source version, passage locator, interpretation, and recommended action. Possible actions include accepting the wording within a stated scope, adding a qualification, correcting a number, replacing a citation, or seeking expert review. Name the unresolved issue instead of assigning a general confidence badge.

Keep the difference between source validity and claim support visible. A reputable venue does not automatically make every secondary interpretation correct, and a metadata match does not validate a result. Record which checks were actually completed. If the full text was unavailable, say that the review was limited to accessible material. If statistical validity was not evaluated, do not imply that the paper has received a comprehensive methodological endorsement.

Leave a trail that can survive a later update

Record when the review occurred and what version it used. A future correction may require only a number to change, while a retraction or substantive revision may affect the basis of a larger argument. Link the claim to its source so that the relevant downstream text can be found without rereading an entire site.

The academic fact-checking overview offers a compact review sequence. Pair it with the citation-checker guide for bibliographic identity and the source-watch workflow for changes after publication. Careful academic checking does not turn a paper into unquestionable authority. It makes clear what the paper says, what it supports, and where an interpretation still depends on judgment.

How to Check a Citation: Identity & Evidence

Wed, 30 Apr 2025 12:00:00 +0000

A citation checker has to answer more than “does this link open?” A functioning link may lead to the wrong paper, a paper may be real but misdescribed, and a correctly identified paper may not support the sentence that cites it. Treating all three situations as a single pass-or-fail test makes a bibliography look cleaner without necessarily making an argument more reliable.

This guide proposes a layered review: identify the cited work, check the bibliographic details, inspect the relevant passage, and evaluate how that passage relates to the claim. The workflow is useful for AI-generated references, academic drafts, research summaries, and editorial fact citation. It can be assisted by software, but its most important question is a question about meaning.

Separate identity from support

Start by distinguishing a citation record from an evidence relationship. The citation record describes a work: its title, authors, venue, date, and identifier. The evidence relationship connects that work, or a passage within it, to a particular assertion in your text. Either side can be wrong while the other is correct.

Crossref’s REST API documentation describes an interface for retrieving scholarly metadata. That makes it a useful reference for identity and bibliographic checks, not a substitute for reading a paper’s supporting passage. A metadata match does not establish that a cited claim is true. Your checker should make that boundary explicit in its labels and in the explanation shown to a reviewer.

Preserve the submitted reference before normalizing it

Keep the original reference string, including the way the identifier and title were supplied. Create a normalized version for matching, but do not overwrite the original. Differences between the two can reveal where a citation was mistyped, truncated, or generated incorrectly. A reviewer should be able to see what the author actually submitted.

Normalize carefully. Remove obvious surrounding whitespace and separate a DOI from a resolver prefix when appropriate, but avoid changing meaningful characters in a title or identifier without a documented rule. Preserve uncertain matches as candidates. If several records have similar titles, use authors, publication year, venue, and document type to distinguish them. Choosing the first search result is not an adequate identity-checking policy.

Verify bibliographic fields independently

Compare the proposed citation with the authoritative metadata available for the work. A title can match while the author list or publication year does not. Record field-level differences rather than returning only “citation found.” This allows a reviewer to correct a typo without assuming that the entire reference is invalid.

Pay particular attention to versions. A preprint, conference paper, accepted manuscript, and journal version may have related titles but different dates, pagination, or content. Cite the version actually used to support the statement. Where a document has no DOI, use an appropriate stable identifier or publisher record instead of concluding that it must be fabricated. Absence from one lookup service is a search limitation, not proof that a work does not exist.

Read the passage that is doing the evidentiary work

Locate the exact sentence, table, figure, or result that supposedly supports the claim. Record a useful locator and enough surrounding context to interpret it. A title match and a thematically relevant abstract are not sufficient when the claim depends on a specific method, subgroup, or numerical result.

Ask a reviewer to describe the support in one or two sentences. For example, in a fictional draft, a cited report may describe a pilot involving one archive while the article claims that every archive adopted the same process. The source may be relevant, but the generalization is not established by that passage. Mark this as a support problem, not a broken-reference problem. The remedy may be narrower wording rather than a different bibliography entry.

Check quantities and comparison language

Numbers require their labels. Preserve the unit, population, period, denominator, and comparison group. A percentage increase is not the same as a percentage-point increase, and a result for one subgroup is not automatically a result for the full sample. When a calculation is involved, retain the inputs and show how the reported value was obtained.

Review comparative language with equal care. “Higher,” “faster,” and “more accurate” need a reference point. A sentence may overstate a study even while repeating a number correctly. Build a review field for the author’s interpretation, separate from the cited result. This encourages an editor to check whether words such as proves, causes, eliminates, or guarantees are supported by the study design and the actual findings.

Inspect quotations and attribution

A quotation should match the source and remain faithful to its surrounding context. Track omissions, inserted clarifications, and translated wording. A paraphrase should be labeled and assessed as a paraphrase rather than quietly placed inside quotation marks. Keep the speaker or author attached to the quoted statement.

Check whether the work is making the claim itself or merely reporting someone else’s claim. A paper’s introduction may describe a hypothesis that its results do not confirm. A fact-check article may quote the rumor it later disputes. A citation checker that extracts an isolated sentence without its rhetorical role can reverse the meaning of the source. Give reviewers the context needed to identify that mistake before the text is published.

Handle inaccessible material honestly

A source behind access controls may still be a legitimate reference, but the checker cannot assess a passage it has not inspected. Return a status such as metadata_matched_content_unreviewed in your local workflow rather than marking the citation supported. Keep identity confidence separate from support confidence.

Use authorized access routes and retain only material your workflow is permitted to store. Ask the author to provide a lawful copy or a precise passage when that is appropriate. Do not let an LLM fill in the missing results from the title alone. If only the abstract is available, state that limitation and restrict the conclusion accordingly. The absence of access is an operational constraint, not evidence for or against the underlying finding.

Record updates and correction decisions

After checking the work’s identity and support, inspect any available correction, withdrawal, or version notice. Record what was checked and when. A later update may affect a particular number, a figure, or the interpretation of a result without changing every assertion in the paper. Read the notice before deciding what downstream text needs revision.

Keep a decision log that distinguishes a bibliographic correction from a substantive citation change. Replacing a mistyped year is different from removing a source that fails to support a central claim. Assign responsibility for unresolved items, and make the final reviewer decision visible. A large collection of machine-generated warnings is not a completed review unless someone can tell which issues were resolved and which limitations remain.

Make the final result useful to the writer

A useful output says what matched, what did not, what passage was inspected, and what action is recommended. Suggested actions might include correcting metadata, narrowing a sentence, adding a missing qualification, replacing an irrelevant citation, or leaving the claim unresolved until the source can be reviewed. Avoid a generic red badge that leaves the author guessing.

The citation-checker overview organizes these layers into a review checklist. Continue with academic fact checking for study-level interpretation and source watch for later changes. A real reference is only the beginning. The stronger standard is a reference whose identity, context, and relationship to the claim remain clear when another person follows it.

LLM Fact Checking: Evidence-Based Evaluation

Tue, 08 Apr 2025 12:00:00 +0000

An LLM answer can contain accurate details, unsupported additions, and misleading combinations in the same paragraph. Checking only whether the overall response sounds plausible hides those differences. A more useful workflow asks which statements require evidence, what the available material supports, and what remains unresolved after a deliberate search.

This guide proposes a claim-level evaluation process for AI-generated answers. It is intended for teams designing review workflows, not as a promise that one model can certify another model’s output. Keep the original answer intact, evaluate the consequential assertions separately, and make the final publishing decision depend on the evidence rather than on a fluent explanation of confidence.

Choose a unit smaller than the whole answer

The FActScore research paper introduces an evaluation that decomposes a generation into atomic facts and measures the percentage supported by a reliable knowledge source. The useful principle is that long-form factuality can be examined at the level of individual assertions rather than reduced immediately to one binary judgment.

For an operational workflow, define the claim unit before measuring performance. A sentence may contain several assertions, while a short phrase may depend on the previous sentence for meaning. Preserve context and qualifiers when splitting an answer. Do not report a historical benchmark result as the accuracy of a current product, and do not assume that performance on one research dataset transfers to your own documents, languages, or risk profile.

Define the evidence boundary before evaluation

Decide whether the task is to check an answer against supplied documents or against a broader collection of external sources. These are different questions. An answer can be faithful to an inaccurate document, and a generally correct statement can remain unsupported by the restricted evidence provided to the evaluator.

Write the boundary into the evaluation instructions and the output. For a document-grounded assistant, label the result as support relative to that document collection. For an open-source research workflow, record which collections were searched and when. Avoid describing a restricted search as comprehensive verification of the entire public record. The boundary is not a technical footnote; it determines what a supported or unsupported label actually means to the reader.

Build a test set from the work you expect

Sample the types of questions, source formats, and answer lengths that the application will encounter. Include straightforward factual requests, missing information, outdated passages, conflicting documents, and ambiguous entities. Preserve examples where the appropriate answer is a refusal to conclude. A test collection made only from easy questions will not reveal whether the system knows when evidence runs out.

Keep the expected claims, relevant passages, and reviewer rationales together. Create a held-out set that is not repeatedly used to tune prompts. Mark the origin and permissions of each document, and avoid putting private material into an evaluation environment without authorization. Treat the collection as a versioned asset. Otherwise, a score may change because the evidence changed rather than because the model became better or worse.

Separate retrieval failure from assessment failure

Suppose a fictional document clearly states that the Atlas catalog launched in 2021, but the retrieval stage supplies only a paragraph about a 2024 redesign. An assessor that returns insufficient evidence may be behaving correctly. Calling this an assessment-model error would lead the team toward the wrong fix.

Evaluate the pipeline in layers. First, ask whether the claim was extracted faithfully. Then check whether relevant evidence was available and retrieved. Next, judge whether the assessment follows from that evidence. Finally, inspect whether the interface presents the result accurately. A strong internal evaluator should be able to distinguish these cases. Otherwise, an apparent improvement in one component can hide a regression elsewhere in the workflow.

Use more than one operational measure

For a proposed internal scorecard, track supported-claim precision, evidence coverage, unresolved claims, and reviewer reversals separately. Define the denominator for every measure. If an answer omits difficult information, it may look precise while being unhelpful. If a system labels everything unresolved, it may avoid confident errors while failing to complete the task.

Report results by relevant slices rather than only as a global average. A system may behave differently on quantities, dates, quotations, and causal statements. Use paired examples when comparing versions so that each version faces the same claims and source material. Include review effort and time to resolution in operational comparisons. The goal is not to produce the most attractive single number; it is to understand which decisions the system can support.

Treat model judgments as reviewable proposals

An LLM evaluator can produce a proposed assessment and a concise evidence rationale. Require it to identify the exact passage that supports or conflicts with the claim, and allow it to state that the evidence is inadequate. Do not ask for a confident answer when the permitted source collection cannot resolve the question.

Use human review for consequential cases and for a sampled portion of apparently straightforward results. Reviewers should inspect the cited material, not merely agree with the evaluator’s explanation. Where feasible, compare judgments without revealing which model produced the answer under review. Record disagreements and their reasons. Repeated disagreements about the same label definition may indicate a flawed rubric rather than an unreliable individual reviewer or a weak model.

Probe meaning, not just matching words

Build adversarial examples that change a small but important detail: a year, a percentage denominator, a geographic scope, an attribution, or a negation. Pair a claim with a passage that shares many keywords but concerns a different entity. Include a statement that combines individually supported facts into an unsupported causal story.

These tests are proposed diagnostic tools, not claims that a particular benchmark covers every failure mode. Their value is in revealing whether the system distinguishes relevance from support. A passage can mention the same topic without proving the assertion. Ask reviewers to mark the exact point where an inference goes beyond the evidence. That annotation is more useful for improvement than a generic note that an answer “hallucinated.”

Plan the release and regression process

Before replacing a component, run the existing and proposed versions on the same evaluation collection. Inspect cases that changed from unresolved to supported especially carefully. A lower abstention rate can represent better retrieval, but it can also represent a willingness to decide without enough evidence. Compare explanations and passage selections, not only final labels.

Set a release rule that reflects the consequences of error in the intended application. Preserve the prior configuration so a problematic update can be reversed. After release, collect corrected assessments and newly encountered failure types for a separate review process. Do not silently rewrite the held-out collection every time an error appears; maintain a stable comparison set and a growing challenge set with clear version histories.

Communicate the result with its limits

A user-facing result should distinguish support, conflict, missing evidence, and processing failure. Show the claim and evidence together. Describe the scope of the check in ordinary language, including whether it examined supplied documents or searched additional sources. A percentage without a denominator, evidence boundary, and calibration explanation is not a useful substitute for that context.

Use the LLM fact-checking topic guide to define the workflow, then pair it with the citation-checker guide to evaluate the references attached to answers. The objective is not to make an AI answer look more authoritative. It is to make unsupported parts easier to find, supported parts easier to inspect, and uncertain parts harder to mistake for established facts.

Fact API Guide: Claims & Verifiable Evidence

Tue, 18 Feb 2025 12:00:00 +0000

A fact API should make a claim easier to inspect, not simply make an answer sound more certain. The useful unit is a checkable statement connected to evidence, a clear assessment, and enough context for another person to understand the decision. That makes a fact API different from a collection of interesting trivia and different from a chatbot that supplies an answer without showing its work.

This guide introduces an evidence-first approach for developers, editors, and research teams. The architecture described here is a proposed implementation pattern, not a description of a hosted FactAPI.com service. Start with a narrow question, keep the underlying material accessible, and treat uncertainty as information worth returning to the caller.

Decide which kind of fact API you need

The phrase “fact API” can describe several different jobs. A structured data API returns recorded attributes such as a publication date or measurement. A fact-check search API finds existing reviews of claims. A claim-verification system compares a statement with selected evidence. A fact-extraction API identifies assertions in a document. These tasks can work together, but their outputs should not be presented as interchangeable.

Google’s Fact Check Tools API documentation distinguishes searching published fact checks from managing ClaimReview markup. Its claim-search capability retrieves existing fact-check results; it should not be interpreted as an automatic verdict on every newly submitted assertion. This distinction is a useful starting point for defining your own product boundary. Specify whether you are returning records, finding reviews, or performing a new assessment before choosing an endpoint name.

Define the claim before choosing the model

Consider a fictional sentence: “The Atlas archive opened in 2021 and contains twelve collections.” It contains at least two independently checkable assertions. A source could support the opening year while providing no evidence about the collection count. Returning one green badge for the entire sentence would hide that difference.

Give each extracted claim an identifier and preserve its original wording. Add normalized wording only when it makes the claim easier to search without changing its meaning. Record the subject, the relevant period, and any important qualifiers. “Contains twelve collections” and “contained twelve collections at launch” are different claims. A model that silently rewrites one into the other can create an apparently successful verification of the wrong statement.

Return evidence, not just a verdict

A useful response contains the claim, the evidence selected, and the relationship between them. For each evidence item, include a stable source identifier, a title, a retrieval timestamp, and a locator such as a section heading or paragraph number. Where your permissions allow it, include a short passage so the user can inspect the exact support.

Keep the assessment separate from the source record. One document may support several claims, and a later correction may change only one of those relationships. A response also needs room for an explanation that names the relevant limitation. “The record supports the launch year but does not state the number of collections” is more actionable than an unexplained confidence percentage. The explanation should point to the evidence rather than introduce additional uncited assertions.

Use status labels that preserve uncertainty

A small, documented vocabulary is easier to integrate than a different phrase for every result. In our proposed examples, supported means the available passage supports the claim within its stated scope. contradicted means relevant evidence conflicts with it. insufficient_evidence means the current evidence set cannot resolve it. These labels describe an assessment against a specified evidence set, not a guarantee of universal truth.

Distinguish those assessment labels from operational states. A failed request, an unavailable document, an unsupported language, and an ambiguous claim should not all become “false.” Return a separate processing status or error field. This lets an application retry an unavailable source, request clarification for ambiguous wording, or route a difficult case to a reviewer without treating every failure as a factual conclusion.

Design the pipeline as separate stages

A practical pipeline has four boundaries: extract the claim, retrieve evidence, assess the relationship, and record the decision. Each stage should produce inspectable output. This is especially useful when a result is wrong. You can ask whether the system selected the wrong statement, missed the right document, misunderstood an available passage, or displayed the assessment incorrectly.

Do not let later stages erase earlier context. Preserve the original document span beside the normalized claim. Keep evidence candidates alongside the selected passage when storage and licensing permit. Record the extraction and assessment versions separately. A retrieval improvement should be testable without changing the claim set, and a new assessment model should be comparable against the same evidence. That separation makes debugging much more specific than repeatedly changing a single all-purpose prompt.

Build a small, demanding test collection

Before connecting the API to a publishing workflow, create a manually reviewed collection of examples from the intended domain. Include statements that are straightforward, partly supported, time-sensitive, ambiguous, and impossible to answer from the permitted sources. Add claims with near-matching names, mismatched units, and quantities attached to different reporting periods.

For a fictional archive application, one test might deliberately pair a launch-year claim with a document about a later renovation. Another could use a real-looking collection count that appears nowhere in the evidence pack. These examples test whether the system understands relationships rather than whether it can repeat familiar sentences. Keep expected evidence and expected assessments together, and document how reviewers resolved disagreements. A label without an evidence rationale is difficult to audit later.

Plan for the user who needs to challenge a result

The interface should make it possible to inspect, question, and correct an assessment. Show the source title, the relevant passage, and the date of the check near the result. Avoid hiding the only meaningful evidence behind a generic “verified” label. Users should be able to distinguish the publisher’s words from the system’s explanation at a glance.

Build a correction path that records what changed and why. A claim may have been extracted incorrectly, a source may have been revised, or an assessor may have overstated the support. Those are different events. Keep the earlier record for audit purposes when appropriate, but ensure downstream applications can identify the current assessment. A correction process is not an admission that evidence workflows failed; it is part of making them useful over time.

Set a practical first-release boundary

A first implementation should cover a source collection and claim type that your team can evaluate responsibly. For example, checking dates and titles within a controlled document archive is a narrower assignment than adjudicating arbitrary claims across the public web. A narrow scope gives you a clearer definition of adequate evidence and a better chance of noticing missing coverage.

Set a rule for when the API must decline to decide. Specify which sources are allowed, how old evidence may be, and which cases require human review. Give callers realistic response semantics before offering performance promises. For costs, measure actual retrieval, assessment, storage, and review work on your own sample; do not assume that the cheapest model produces the cheapest reviewed result. Rework can change that calculation substantially.

Make the evidence trail the product

The strongest starting point is a response that another person can reconstruct: this was the claim, these were the sources, this passage mattered, and this was the limited conclusion. That contract is useful whether the assessment comes from deterministic rules, an LLM, a human reviewer, or a combination of them.

Continue with the Fact API architecture guide to map the components, then inspect the illustrative JSON examples. Build around traceability first. More models, sources, and automation can be added later; a missing relationship between a claim and its evidence is much harder to repair after the result has already been published.

FactAPI.com | Fact APIs, AI Fact Checking & Citations

FactAPI.com: Less guesswork. More evidence.

Independent guides to fact APIs, LLM evaluation, citation quality, academic fact checking, and source monitoring.

Learn about Fact APIs, LLM fact checking, and citation quality. Explore all ten fieldnotes in The Evidence Journal.

Fact API Architecture & Evidence Workflows

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.

Fact Extraction API: Claims, Entities & Context

Extraction is a preparation step

Finding an assertion in a document does not establish that the assertion is correct. Use the word claim in your data contract when a statement has not been assessed. That small naming decision helps prevent downstream tools from presenting extracted material as verified information.

An extraction workflow should identify independently checkable statements while preserving the original passage. It should also distinguish observations, reported allegations, predictions, opinions, and recommendations. The fact that a speaker expressed a view is different from the truth of that view.

Keep the qualifiers that change the question

Consider the fictional sentence “The Meridian catalog estimates approximately four thousand records at launch.” Removing estimates, approximately, or at launch changes what needs to be verified. Preserve those qualifiers in normalized wording and carry unresolved ambiguity forward.

When one sentence contains several claims, split it only where the parts can be assessed independently. Retain shared context such as entity names and time periods. Record a parent sentence identifier so a reviewer can reconstruct how the original passage was decomposed. Avoid turning short, dependent fragments into statements that appear complete but no longer mean the same thing.

A useful extraction response

Include an original document identifier, an original text span, a reproducible locator, a normalized claim, and a record of unresolved entity or date ambiguity. If offsets refer to transformed text, identify that exact text version. Do not reuse positions from an earlier parser output after the document has changed.

Keep processing coverage explicit. A partial extraction should say which material was handled and what was omitted. Unreadable tables, missing pages, and length limits should not disappear behind a successful status. Coverage is part of the result that a verification stage needs to understand.

Test the handoff to verification

The FEVER paper is a research reference for connecting claims with textual evidence and distinguishing supported, refuted, and insufficient-information cases. For your application, test extraction separately from that later assessment so you can locate errors at the right stage.

Use reviewed examples containing negation, nested attribution, near-matching entities, and uncertain quantities. Measure omissions, invented assertions, excessive splitting, and incorrect merging separately. A large output is not a good output when it quietly changes the important claim.

Review the ambiguous cases early

Set a rule for when extraction must request review before retrieval starts. An unresolved pronoun or unclear date may be cheaper to fix at this point than after a verifier has searched for evidence about the wrong statement. Show the original wording beside the normalized version.

Continue with the complete extraction guide and the response schema examples. The aim is a faithful question that another component can answer—not a more polished version of a statement whose meaning has been lost.

Structured Fact Data & Provenance-First JSON

Model the relationship, not only the answer

A statement and a source are separate things. An assessment records how a source passage relates to a specific statement during a particular check. Separating those objects makes it easier to reuse evidence, correct an interpretation, and preserve the history of a result.

Use stable identifiers for claims, source versions, evidence passages, and assessments. Document whether those identifiers are local or externally resolvable. One source may support several claims, while one claim may need several pieces of evidence. Your data model should make those relationships visible rather than hide them inside a single explanation field.

What provenance adds

W3C’s PROV overview describes provenance through entities, activities, and the people involved in producing information. That provides a useful conceptual reference: what material was used, which process acted on it, and who or what was responsible for the result.

The FactAPI.com examples use a small illustrative JSON contract rather than claim conformance to a complete provenance standard. The practical objective is reconstructability. Another reviewer should be able to locate the claim, inspect the evidence, and understand the limited conclusion without guessing which document or model version was involved.

Choose fields that cannot silently change meaning

Keep original wording separate from normalized wording. Distinguish source publication, source revision, retrieval, and assessment dates. An old document retrieved today has not become a newly published source. Use null deliberately for unavailable information instead of substituting zero or an empty string.

Separate processing errors from evidence assessments. Define every status in plain language. A supported status in our examples means supported by the named fictional passage, not verified against the entire public record. Any confidence measure should have its own documented interpretation rather than masquerade as a universal probability of truth.

Version the contract and the decisions

Add a schema version and a compatibility policy. Validate successful, partial, and failed responses. Preserve an earlier assessment when a correction is issued, and link the new assessment to the one it supersedes. Do not let a delayed result overwrite a newer decision merely because it arrived last.

Record why something changed: a revised source, an extraction repair, a reviewer correction, or additional evidence. The reason determines how downstream content should be revisited. A bibliographic typo and a contradicted central claim are not the same maintenance event.

Put the schema to work

The developer examples contain a local JSON evidence pack and a machine-readable schema. They are downloadable static files, not an API service. Use them to discuss the shape of an evidence-oriented response and adapt the contract to your own evaluation and access requirements.

Read the full structured-data article for implementation considerations, and connect it to the source-watch operating model. Good structure does not make a claim true; it makes the basis and limits of an assessment visible enough to review.

LLM Fact Checking & AI Evaluation Workflows

Define what your check is allowed to conclude

Checking an LLM answer against supplied documents is a different task from researching it against additional sources. An answer can faithfully repeat a flawed document, and a generally correct statement can be unsupported by the particular evidence supplied. Name that boundary in the result.

For a document-grounded workflow, ask whether each important assertion is supported by the approved collection. For a wider research workflow, record where the system searched and which limitations remain. Do not describe a restricted search as comprehensive verification of the public record.

Evaluate at the claim level

The FActScore research paper describes decomposing generated text into atomic facts and evaluating support from a reliable knowledge source. That principle is useful for detecting mixed support within a long answer. It does not establish the present-day accuracy of any service described elsewhere.

Preserve the original answer and extract statements without losing attribution, dates, or qualifiers. Associate each assessment with a passage. Review whether the conclusion follows from that passage instead of treating shared keywords as proof. An explanation that introduces additional unsupported reasoning is not a repair for weak evidence.

Diagnose the stage that failed

A proposed pipeline contains extraction, retrieval, assessment, and presentation. Check them separately. A correct assessor may return insufficient evidence because the retrieval stage missed the relevant document. An accurate source may be attached to the wrong claim because extraction resolved an entity incorrectly.

Use targeted tests for date mismatches, changed denominators, negation, missing information, and causal overstatement. Keep human rationales with expected labels. Where reviewers disagree about the rubric, clarify the policy before treating every disagreement as a model failure.

Make your scorecard useful

Track support quality, claim coverage, unresolved cases, and reviewer reversals separately. Define denominators and evaluate important slices such as numbers, quotations, and time-sensitive assertions. An answer that avoids difficult facts may look precise while being incomplete. A checker that abstains from everything may be safe from confident errors but operationally unhelpful.

When comparing configurations, use the same claims and evidence boundary. Inspect examples whose labels changed, especially new supported results. Include review effort and correction work in an operational comparison rather than deciding solely from an average automated score.

Keep a person in the decision loop

For consequential material, show the claim, source, passage, and limitations to a reviewer with appropriate domain knowledge. Preserve corrections and model-version information. A second model’s agreement is not an independent source of evidence.

Read the complete LLM evaluation guide, the evidence-grounded citation workflow, and the service-selection checklist. FactAPI.com publishes independent guidance; it does not promise a live AI fact-checking service or automated certification of arbitrary answers.

Citation Checker: Identity, Accuracy & Support

Three checks, three different answers

A bibliography review should distinguish identity, accuracy, and support. Identity asks whether the cited work can be located. Accuracy asks whether its title, authors, year, identifier, and version are correctly described. Support asks whether a passage in that work justifies the specific assertion in your text.

A reference can pass the first two checks and fail the third. That distinction is especially important for fact citation AI and LLM-generated writing: a plausible bibliography is not proof that the accompanying argument follows from its sources. Keep field-level findings separate from semantic support judgments.

Begin with the citation record

Crossref’s REST API documentation describes retrieval of scholarly metadata. It is a useful starting point for bibliographic identity checks. Metadata alone does not determine whether a paper supports a claim or whether its methodology is sound.

Preserve the original reference string before normalization. Compare candidate matches using several fields, not just the first title returned. Distinguish a preprint from a published version. A missing DOI or missing result in one index should not automatically become a fabrication verdict; it may require another identification route.

Inspect the passage that matters

Locate the relevant sentence, result, table, or figure. Keep a reproducible locator and enough context to show what the passage is doing. A paper may quote a claim to dispute it, describe a hypothesis rather than establish it, or attribute a result to a different work.

For quantitative statements, preserve units, denominators, populations, and periods. For comparisons, identify the baseline. For paraphrases, check that important qualifications survived. When the source supports narrower wording than the draft, a useful recommendation may be to qualify the sentence rather than replace the entire reference.

Distinguish access problems from factual conclusions

If the full text is unavailable, say which checks were completed. Matching metadata does not permit an evaluator to invent the missing results. An abstract-only review should remain limited to material actually inspected.

Keep authorized-access and retention requirements separate from the substantive judgment. A source can be legitimate while unavailable to the present workflow. Use an operational status for that limitation instead of declaring the citation supported, contradicted, or nonexistent solely because a retrieval attempt failed.

Produce an actionable review

Return the submitted reference, the matched record, field differences, passage locator, support assessment, and recommended action. Typical actions include correcting metadata, narrowing wording, restoring a missing qualification, replacing an irrelevant citation, or requesting expert review. Keep the unresolved items visible.

The citation-checker field guide walks through the process. Pair it with academic fact checking for interpreting research and source watch for later corrections. This site offers guidance and examples, not a form for uploading papers or a live citation-scanning service.

Academic Fact Checking & Journal Citation Review

A paper is not a universal endorsement

Academic fact checking asks whether the source supports the statement made about it. Correct metadata and a recognizable journal do not eliminate the need to inspect methods, results, and interpretation. A faithfully repeated number can still be attached to the wrong population or generalized beyond the study setting.

Start with the sentence under review. Identify whether it describes an observation, a comparison, a causal claim, or a recommendation. Mark the population, period, setting, and outcome. That gives the reviewer a specific relationship to test rather than a vague request to approve the paper.

Identify the work and its status

Record the exact version consulted, including a stable identifier where available. Keep preprints, accepted manuscripts, published articles, and correction notices distinct. Similar titles do not guarantee identical evidence.

Crossref’s Crossmark documentation describes a way to surface the current status of scholarly content and associated updates. Where available, use those notices as part of checking a work’s version history. An update mechanism is not a certification of scientific validity, and a missing notice does not establish that every possible concern has been resolved.

Connect claims to methods and results

Read the design that produced the finding. Check selection criteria, measurement, comparison groups, and the unit of analysis. Trace quantities to the relevant table or passage and retain their units and denominators. Keep a derived calculation separate from the number directly reported in the source.

Distinguish the study’s own result from background material, a quotation of another author, or a hypothesis in the discussion. An AI summary can compress those roles into a misleading sentence. Preserve the role of the passage in your evidence record so the final text does not accidentally present speculation as an established finding.

Match the wording to the support

Look carefully at scope and strength. A study in one setting may not justify a universal recommendation. A nondetected difference may leave uncertainty rather than establish equivalence. Whether a causal claim is justified depends on the actual evidence and design, not on replacing verbs mechanically.

Record where you need specialized expertise. A targeted citation check should not imply that a complete statistical review or systematic literature review has been conducted. Name the material inspected and the questions left open. High-quality academic citations make their evidentiary role clear instead of borrowing authority from a long reference list.

Preserve the review for future changes

Store the claim, source version, passage locator, interpretation, and reviewer decision. Add a link from the claim to the source so later corrections can be traced to affected content. A bibliographic update and a substantive change to a finding call for different actions.

Use the academic fact-checking article as the detailed reading sequence, then connect it to the source-watch workflow. FactAPI.com provides independent educational material, not peer review, scientific certification, or a substitute for domain-specific judgment.

AI Source Watch: Academic Updates & Corrections

Monitor meaning, not only uptime

A source watch asks whether a change in evidence affects something you have already published or relied on. A working URL is not enough. A source may have a correction, a new version, or a notice that needs interpretation. Conversely, a temporary access failure is not a substantive change to its findings.

Build an inventory of sources linked to specific claims. Prioritize the material supporting important conclusions, quantities, and frequently reused explanations. Assign a review owner before enabling notifications. An unowned alert is not a completed correction process.

Use update channels as evidence to inspect

Crossref’s Retraction Watch API announcement describes the availability of Retraction Watch retractions and corrections through its REST API. Such metadata is a useful discovery input, but a workflow should still inspect the relevant notice and account for incomplete coverage.

Preserve the original signal, source, observed time, and work identifier. Keep discovery separate from assessment: finding a notice does not yet tell you which dependent claims need revision. Avoid drawing conclusions about misconduct or unrelated work from an update label alone.

Keep a baseline and a useful event vocabulary

Store the source version and metadata used during the original review. Where appropriate and permitted, retain a content snapshot or a hash. A hash signals a change but does not explain it. Keep a readable locator for the supporting passage.

Separate metadata changes, content revisions, correction notices, retraction notices, and access failures. Group duplicate signals while retaining their origins. Record a newly observed old notice as newly observed, not newly published. This prevents your alert history from implying knowledge of a source before monitoring began.

Connect the notice to a decision

An alert should identify the source, the observed event, the affected claims, the owner, and the requested action. Use the actual dependencies, not only similar keywords, to locate downstream material. A corrected number may affect one statement while leaving a citation used for background unchanged.

Possible review outcomes include no impact, metadata correction, claim qualification, citation replacement, withdrawal of an unsupported statement, or expert review. Preserve the reason for closing the event. Dismissing a notification should not erase an unresolved evidence question.

Evaluate the watch itself

Test known changes in a controlled source collection. Measure matching accuracy, unresolved cases, alert noise, review workload, and time to a meaningful decision. Choose a cadence appropriate to the consequences of error, and state what the process actually observes rather than promising continuous or comprehensive coverage.

The source-watch field guide explains the full operating model. The structured-data guide shows how versioned evidence records support it. FactAPI.com publishes a workflow design; this static site does not run background monitoring, deliver live source alerts, or offer a monitoring subscription.

Online Fact Checking, Snopes & Claim Context

Start with the statement, not the badge

Write down the exact claim being checked. Include the person or organization, date, place, and any qualification that changes its meaning. Similar topics are not necessarily equivalent assertions. A statement about what happened once differs from a claim about what happens routinely.

Search results are discovery aids. Open a candidate review and compare its claim with yours before adopting its conclusion. A snippet can omit the limitation or update that makes the assessment intelligible. Keep the original review linked to the claim it actually examined.

Read Snopes in context

Snopes’ ratings explanation emphasizes that a rating evaluates the wording of a particular claim statement. Preserve that relationship when citing or organizing a published review. Do not apply a familiar rating to a new claim merely because the same subject appears in both.

FactAPI.com is independent of Snopes. We do not claim an official Snopes API, a data partnership, or permission to reproduce its articles. Any integration with a publisher should be based on current documentation and permitted access, not an invented endpoint or an assumption that public reading access allows unrestricted reuse.

Distinguish the rumor from the analysis

A fact-check article may reproduce an assertion in order to challenge it. When extracting passages, record whether the text is the original claim, a quoted source, analysis, a limitation, or the reviewer’s conclusion. An isolated quotation can reverse the article’s meaning if that role is lost.

Follow the explanation behind a rating and identify the underlying material. Check whether the new question concerns the same event, date, and scope. An old review may provide useful background without resolving a later development.

Preserve disagreement and uncertainty

Keep a publisher’s original claim and rating alongside any normalized labels used in your application. Document mappings rather than assuming all rating systems are interchangeable. Your relevance assessment is separate from the publisher’s assessment of its original claim.

When reviews appear to disagree, compare their wording, dates, and sources first. Where evidence genuinely conflicts, describe the unresolved issue. A count of websites is not a substitute for comparing independent support. If no relevant published review is found, treat that as a limitation of the search rather than evidence that the claim is true or false.

Share an evidence trail

A useful review record contains the incoming claim, candidate review, reviewed claim, original rating, dates, key passages, and a limited conclusion about relevance. It should let another person see why the review was used and what it does not establish.

Read the full Snopes and online fact-checking article for the workflow, and the Fact API guide for separating discovery from assessment. Our focus is careful source use, not political persuasion, a universal truth score, or a claim that one publisher’s name settles every question.

Fact API JSON Examples & Evidence Schema

Read the contract before the code

These are static example files, not live API endpoints. No claim is sent to a server for assessment, no key is required, and no evidence search is performed. The Atlas archive and its source passage are fictional. The visible interface switches between predefined records to illustrate response semantics.

The proposed model keeps the exact claim, the evidence passage, and the assessment separate. A supported status means the named passage supports the claim within the example’s scope. It is not a universal guarantee of truth. The homepage shows a shortened display record; the downloadable files below use the complete contract.

Three outcomes. One evidence pack.
Change the wording of the claim and the relevant relationship changes—even when the source stays the same. The local examples below make that distinction explicit.

The fictional source passage

Atlas demonstration release note · paragraph 1

The Atlas demonstration archive opened in 2021. It accepts JSON exports.

This is the entire evidence used in all three examples. It supplies a year and an export format. It does not supply a collection count. No real project, publisher, or study is being assessed.

The claim

The Atlas demonstration archive opened in 2021.

“The Atlas demonstration archive opened in 2021. It accepts JSON exports.”

Supported

The stated opening year matches the supplied example passage. This assessment applies only to this fictional evidence pack.

LOCAL, FICTIONAL EXAMPLE · No live checks or external requests.

The complete example record

The supported example contains a stable local claim identifier, an explicit scope, a completion state, and an assessment linked to its evidence. Its source URL leads to the fictional passage on this page.

{
  "schema_version": "1.0",
  "example": true,
  "claim_id": "demo-001",
  "claim_text": "The Atlas demonstration archive opened in 2021.",
  "scope": "Fictional Atlas evidence pack only; not a real-world verification.",
  "processing_status": "complete",
  "assessment": {
    "status": "supported",
    "reason": "The example passage explicitly gives 2021 as the opening year.",
    "evidence": [
      {
        "source_id": "example-release-note",
        "source_title": "Atlas demonstration release note (fictional)",
        "source_url": "https://factapi.com/docs/#sample-evidence",
        "locator": "Paragraph 1",
        "passage": "The Atlas demonstration archive opened in 2021. It accepts JSON exports.",
        "relationship": "supports"
      }
    ]
  }
}

Field reference

Field	What it means
`schema_version`	The version of this illustrative contract, not a software release promise.
`example`	Always true here. These records describe fictional evidence.
`claim_id`	A local identifier for a precisely worded claim.
`claim_text`	The actual statement being assessed, including its qualifiers.
`scope`	The evidence boundary within which this example applies.
`processing_status`	Completion of the example’s processing, separate from support.
`assessment.status`	Supported, contradicted, or insufficient evidence.
`assessment.reason`	A short explanation limited to what the passage establishes.
`assessment.evidence`	Source identity, locator, exact passage, and relationship to the claim.

Download the local examples

Every file below is included with this website. Open the record directly or save it for your own implementation discussion. The JSON Schema describes this small example contract; it intentionally does not pretend to cover production errors, authentication, billing, or a real service’s operations.

Supported JSON ↓Contradicted JSON ↓Insufficient evidence JSON ↓Complete evidence pack ↓JSON Schema ↓

Adapt the pattern, evaluate the behavior

For a production design, add a documented error contract, source-version history, assessment timestamps, authorization, and a privacy-appropriate retention policy. Define whether identifiers are local or externally resolvable. Test unknown labels, missing passages, partial documents, and unavailable sources before letting a consumer interpret the result.

Validate the structure and the semantics separately. A record can satisfy a JSON Schema while containing an assessment that does not follow from its evidence. Keep human-reviewed examples for the support relationship, and test the entire handoff from extraction through the final display.

Continue with structured fact data for provenance, claim extraction for preserving meaning, and LLM evaluation for checking an actual assessment workflow.

About FactAPI.com | Independent Evidence Guides

What FactAPI.com is for

FactAPI.com brings together practical explanations of claim extraction, factual API architecture, LLM evaluation, citation checking, academic evidence, and source monitoring. It is designed for developers, researchers, editors, and AI teams who need to make the relationship between a statement and its source easier to inspect.

Our central principle is simple: show the claim, show the evidence, and explain the limits of the conclusion. A confident answer is not a substitute for that relationship. A recognizable publisher name is not a substitute for reading the relevant passage.

What you will find here

The topic guides introduce the boundaries between different evidence tasks. The Evidence Journal develops those ideas through ten long-form fieldnotes, each with a focused editorial source and a practical workflow. The developer section supplies local fictional JSON examples that can be inspected without an account or API key.

Our implementation suggestions are proposed patterns, not a claim that one universal schema or assessment vocabulary fits every organization. The worked examples are identified as fictional. Research references are distinguished from the operational guidance we develop around them.

What this site does not offer

FactAPI.com does not operate a hosted fact-checking endpoint, accept uploaded documents, sell API subscriptions, or provide live journal-source alerts. The interactive example switches between fixed local records; it does not verify anything submitted by a reader. There are no account, payment, or data-entry forms on this site.

The guides do not replace domain expertise, peer review, or specialized professional advice. For consequential decisions, inspect original evidence and involve the appropriate reviewers. The goal is to support informed judgment, not remove responsibility for a conclusion.

Independence and source attribution

References to Snopes, Google, Crossref, W3C, NIST, and academic research describe their public material. They do not imply endorsement, affiliation, a data partnership, or an official integration. FactAPI.com does not claim credentials, certifications, or service-performance results from those organizations.

Visit the research source index to see the primary references behind the guides. The editorial policy explains how we distinguish evidence, inference, and illustrative design.

Help improve the evidence trail

A useful correction identifies the page, the exact statement, and the evidence that supports a change. Send editorial feedback to info@factapi.com. Do not include confidential documents or sensitive personal information in an initial message.

Start with the Fact API overview or browse The Evidence Journal to choose a focused reading path.

Editorial Policy & Corrections

Keep the claim precise

We aim to preserve the subject, date, attribution, and qualifications that change the meaning of a statement. A relevant document is not automatically evidence for every assertion about its topic. The claim and the specific support relationship should remain visible together.

A source may support narrower wording than a draft suggests. In that case, qualification or an unresolved status is more useful than a stronger claim with an impressive-looking citation attached to it.

Distinguish sources from recommendations

Each Evidence Journal article includes one editorial outbound link to a focused primary source, such as official documentation, a standards publication, or a research paper. The article identifies the limited source-backed idea and then develops practical recommendations around it. Our proposed architectures, workflows, and review checklists should not be read as promises from the cited organization.

The source index groups the references for further inspection. Source details and external interfaces can change. An implementation should be checked against current documentation and evaluated in the environment where it will be used.

Keep examples visibly illustrative

The Atlas demonstration archive, its release note, and the example assessments in the developer section are fictional. They explain the difference between support, contradiction, and missing evidence. They are not a live test, benchmark, customer case study, or result from a hosted FactAPI.com service.

Other hypothetical scenarios and calculations in the articles are labeled as examples. We do not present invented performance metrics, testimonials, partnerships, or professional credentials as evidence of a product’s quality.

Preserve uncertainty and scope

Our example labels describe an assessment against a specified evidence set. Missing evidence is not automatically evidence of falsehood. A completed request is not automatically a supported claim. A real citation is not automatically a sound interpretation of a study.

Consequential assertions may require subject expertise or a broader review than a single fieldnote can provide. A targeted source check should not be described as a comprehensive scientific, legal, medical, or financial assessment. The actual work performed and its boundaries should remain clear.

Use research without overstating it

Historical research provides useful concepts and evaluation methods. It does not establish the accuracy of a current model, provider, or deployment. We avoid turning benchmark findings into unsupported service promises. Original findings and our implementation suggestions serve different roles in the explanation.

A source’s recognizable name does not settle a question by itself. Readers should be able to inspect the relevant source and see what the article attributes to it. References to outside organizations do not imply endorsement or affiliation.

Corrections and publication information

To report a possible error, send the page address, exact wording, proposed correction, and a credible supporting reference to info@factapi.com. Clearly distinguish a broken link from an incorrect factual statement or an interpretation you believe needs qualification.

Displayed publication dates are kept consistent across the journal, article metadata, and RSS feed. An update date should describe an actual substantive revision, not a routine page view or an attempt to make an unchanged article appear newly written. Where a source changes, the relevant claim should be reviewed rather than automatically assigned a new conclusion.

Research Sources & Primary References

These are the primary research and documentation references used in the fieldnotes. Each source supports a specific idea identified in its article. The surrounding implementation guidance is a proposed approach, not a promise or endorsement from the cited organization.

Some references describe historical research. They should not be used to infer the current accuracy of a product or model. Check live documentation and evaluate your own workflow before implementing an integration.

Google Fact Check Tools API ↗

Official documentation for searching published fact checks and working with ClaimReview markup. Used to distinguish review retrieval from a new claim assessment.

Read the related fieldnote

FEVER: Fact Extraction and VERification ↗

The original research paper on claim verification against textual sources, with support, refutation, and insufficient-information labels. Used as a reference for separating claims from evidence.

Read the related fieldnote

W3C PROV overview ↗

A conceptual reference for provenance: the entities, activities, and people involved in producing information. Used to frame a proposed evidence-record design.

Read the related fieldnote

FActScore ↗

Research on fine-grained factual precision in long-form generation. Used for the concept of examining individual assertions rather than assuming an entire answer shares one factual status.

Read the related fieldnote

Crossref REST API ↗

Official documentation for scholarly metadata retrieval. Used for bibliographic identity and accuracy, distinct from a claim’s semantic support.

Read the related fieldnote

ALCE: Generating text with citations ↗

Research that evaluates fluency, correctness, and citation quality as separate dimensions. Used to frame an evidence-grounded answer workflow.

Read the related fieldnote

Snopes fact-check ratings ↗

The publisher’s explanation of its rating system and the importance of a specific claim statement. Used to preserve context when reading a published review.

Read the related fieldnote

Crossref Crossmark ↗

Official documentation on displaying scholarly content status and updates. Used for version and update checks, not as a guarantee of scientific quality.

Read the related fieldnote

Retraction Watch data in the Crossref API ↗

Crossref’s announcement describing Retraction Watch retractions and corrections in its REST API. Used as one discovery input for a proposed source-monitoring process.

Read the related fieldnote

NIST Generative AI Profile ↗

A cross-sectoral companion to the AI Risk Management Framework. Used as a reference for organizing questions about trustworthiness across an AI application.

Read the related fieldnote

Fact API & Evidence Glossary: 24 Key Terms

This glossary uses terms as they appear in the FactAPI.com guides. Status labels describe the illustrative local contract, not a universal standard. Follow each topic link for the relevant context, limitations, and research reference.

Abstention

A deliberate decision not to assign a factual conclusion when the evidence or task definition is inadequate. In a proposed review workflow, abstention should have a reason—such as ambiguous wording or missing support—rather than appear as an unexplained failure. Explore the guide ↗

Assessment

A documented judgment about the relationship between a specific claim and specified evidence. An assessment belongs to a scope and a particular check; it should not be confused with the source document itself or a guarantee about every possible source. Explore the guide ↗

Atomic claim

A statement small enough to be assessed independently while retaining the context needed for its meaning. Atomic does not mean stripping away attribution, a date, or a qualifier. A sentence can produce several claims when its parts have different evidence. Explore the guide ↗

Attribution

The connection between a statement and the person or source said to have made it. Checking that someone made an assertion is different from checking whether the assertion is correct. Preserve that distinction when extracting claims or paraphrasing a source. Explore the guide ↗

Bibliographic identity

The question of which work a reference identifies. Titles, authors, publication details, versions, and identifiers help establish a match. An identity match does not show that the work supports the nearby claim or that its research methods are valid. Explore the guide ↗

Citation coverage

In an evaluation rubric, the extent to which claims that need evidence have identifiable citation support. Define which claims count and what constitutes adequate support before measuring coverage; a citation marker alone should not automatically satisfy the requirement. Explore the guide ↗

Citation support

The relationship between a cited passage and the assertion it is supposed to justify. The passage must address the actual wording, including scope and qualifications. Topic similarity and a real bibliographic record are useful checks but do not settle support. Explore the guide ↗

Claim

A statement presented for inspection or assessment. Using this term avoids implying that extracted text has already been verified. A useful record retains the wording, context, attribution, and period that determine what the evidence would need to establish. Explore the guide ↗

Contradicted

One of the local assessment labels used in our examples. It means relevant evidence conflicts with the specific claim under the defined scope. It should remain separate from processing failures and from cases where the available material simply does not resolve the question. Explore the guide ↗

Correction notice

A notice indicating a change to previously published material. Read the notice and identify the affected part rather than assuming every claim in the work needs the same revision. In a source watch, preserve its identity, scope, and downstream review outcome. Explore the guide ↗

DOI

A digital object identifier associated with a work or other object. In citation checking, an identifier helps locate and distinguish the intended record. Its presence does not establish that the source supports a claim, and not every legitimate source has one. Explore the guide ↗

Entity resolution

The process of determining which person, organization, project, or other entity a name refers to. Similar names can refer to different subjects. Preserve uncertain matches rather than letting a normalization step silently select the most familiar candidate. Explore the guide ↗

Evidence boundary

The set of sources and scope within which a check is performed. A review against supplied documents answers a different question from an open-source investigation. State the boundary so readers understand what supported and unresolved labels actually describe. Explore the guide ↗

Evidence locator

A reference to the passage, paragraph, section, table, or other part of a source used in an assessment. A locator should remain resolvable for the relevant source version. A link to a long document alone may not identify the supporting material precisely enough. Explore the guide ↗

Fact API

An interface described as returning factual records, published reviews, or evidence-oriented assessments. The term can cover different jobs, so the data contract should make its actual operation explicit. Retrieving a record is not automatically the same as completing a verification. Explore the guide ↗

Fact extraction

Identification of statements within unstructured material for later inspection. Good extraction preserves original text, context, and source locations. It can identify what a document says without deciding whether the document’s assertions are accurate. Explore the guide ↗

Insufficient evidence

The local example status for a claim that the available material cannot resolve. It does not mean the claim has been disproved. The response should explain the gap and distinguish missing support from a technical failure to access the intended source. Explore the guide ↗

LLM evaluator

A language-model component used to propose assessments under a defined rubric. Its output should remain inspectable against the actual evidence. Model confidence or agreement with another model is not an independent source establishing that a claim is correct. Explore the guide ↗

Provenance

Information about where a record came from and how it was produced. For an evidence workflow, useful provenance connects sources, processing steps, versions, and responsible reviewers or systems. It helps a later reader reconstruct the basis of an assessment. Explore the guide ↗

Retrieval

The stage that finds candidate documents or passages for a question. Retrieval relevance and evidentiary support are different checks: a passage may discuss the right topic without addressing the precise claim, time period, entity, or comparison. Explore the guide ↗

Retrieval-augmented generation

An answer-generation workflow that uses retrieved material as part of its context. In the proposed approach here, the system maps claims to inspected passages and checks the final wording again. Supplying retrieved text does not eliminate the need to evaluate actual citation support. Explore the guide ↗

Source watch

A monitoring workflow that identifies source changes and connects them to dependent claims. A useful watch distinguishes substantive notices from access failures, assigns review ownership, and preserves the reason for any correction. It is more than checking whether links still load. Explore the guide ↗

Supported

The local example label indicating that the specified passage supports the exact claim within the stated evidence boundary. It should carry a source relationship and rationale. It is not a universal certification that every relevant source has been examined. Explore the guide ↗

Versioned assessment

An assessment record preserved with a history rather than silently overwritten. A later source update or reviewer correction can supersede an earlier decision while keeping its basis recoverable. Explicit links between versions help prevent older results from being presented as current. Explore the guide ↗

FactAPI.com — The Evidence Journal

Online Fact Checks & Snopes: Keep the Context

Begin with the specific wording under review

Search for the claim, not just the topic

Read the evidence and explanation behind the rating

Check time and context before carrying a result forward

Preserve a publisher’s rating vocabulary

Compare independent evidence when the stakes warrant it

Design automated discovery with a narrow promise

Keep a compact review record

Share the conclusion without losing its boundaries

Fact Citation AI: Evidence-Grounded Answers

Evaluate citations separately from fluency

Establish a source collection with visible boundaries

Retrieve passages that can answer the actual claim

Draft from an evidence map

Keep citation markers close to the assertions

Check the finished answer, not only the draft plan

Protect the boundary between sources and instructions

Measure answer usefulness and evidence discipline together

Make citations a navigable evidence trail

Structured Fact Data: JSON & Provenance

Start with provenance rather than a truth score

Give claims and sources different identifiers

Preserve both original and normalized wording

Represent evidence as a relationship

Keep assessment labels and processing states apart

Separate the dates that answer different questions

Version the schema and the assessment process

Design updates without erasing history

Test whether someone else can reconstruct the check

Academic Source Watch: Updates & Retractions

Define what deserves monitoring

Use update metadata as a discovery signal

Keep a baseline that can be compared

Classify events before escalating them

Deduplicate without concealing independent signals

Connect each event to affected claims

Design alerts for decisions, not alarm volume

Record review outcomes and corrections

Evaluate the monitoring process itself

How to Choose an LLM Fact-Checking Service

Translate the use case into an evidence contract

Ask for an explicit capability boundary

Use a risk framework without treating it as certification

Build a comparison set before seeing the scores

Inspect the evidence behind changed labels

Evaluate privacy and operational access

Measure the cost of a reviewed result

Test integration, failure handling, and exit options

Make a bounded decision after the pilot

Fact Extraction APIs: Atomic Claims & Context

Separate extraction from verification

Decide what counts as a checkable statement

Split compound claims without destroying context

Preserve attribution, negation, and uncertainty

Give every claim a reliable location

Normalize entities conservatively

Control duplicate claims and document scale

Evaluate extraction with a reviewable rubric

Define the handoff to the evidence stage

Academic Fact Checking: Beyond the Abstract

Identify the exact work and version

Write the claim in a form that can be tested

Read the methods that define the result

Trace numerical claims to the relevant result

Distinguish the authors’ findings from their discussion

Match the strength of the wording to the evidence

Consider the surrounding research without pretending to finish it

Document the decision and the unresolved questions

Leave a trail that can survive a later update

How to Check a Citation: Identity & Evidence

Separate identity from support

Preserve the submitted reference before normalizing it

Verify bibliographic fields independently

Read the passage that is doing the evidentiary work

Check quantities and comparison language

Inspect quotations and attribution

Handle inaccessible material honestly

Record updates and correction decisions