Detecting Hallucinated Facts in Automated Articles at Scale
An evidence-led model for detecting hallucinated facts in automated articles, with error types, detection layers, measured limits, and review thresholds.
For teams detecting hallucinated facts in automated articles, the central decision is whether each checkable assertion has enough evidence to publish. This whitepaper proposes a layered control model: extract factual claims, evaluate their supporting passages, use model disagreement to prioritize investigation, and route unresolved claims to editors. The unit of verification is the individual assertion; the publication decision applies to the complete article.
The framework below is a proposed operational design, without measured performance results. It distinguishes evidence-backed approval from unresolved uncertainty and explains how to evaluate detection before expanding publishing volume. Any numerical evaluation is explicitly hypothetical.
What counts as evidence for a factual claim
Article verification needs separate judgments about source support and factual validity. This framework treats them as distinct requirements.
A passage can support what an article says while leaving the underlying assertion unverified. For example, a vendor page might document a vendor’s stated capability. Treating that statement as independently demonstrated performance would require different evidence.
Use four evidence states:
- Supported: an acceptable source directly establishes the assertion within its stated scope.
- Contradicted: acceptable evidence conflicts with the assertion.
- Unresolved: available evidence cannot establish or reject the assertion.
- Not applicable: the text expresses advice, opinion, or an explicitly hypothetical example rather than an external fact.
These are proposed editorial labels, not probabilities. An unresolved claim should never become supported merely because repeated verification attempts produce similar wording.
Evaluate evidence against the exact proposition: entity, relationship, quantity, population, geography, and time. A statistic about surveyed enterprise customers does not establish the same statistic for all businesses.
Source eligibility also needs an explicit rule. Decide which records can establish product capabilities, which documents can support research findings, and who may approve proprietary business claims. Record exceptions alongside the claim they affect.
Four failure types require different checks
A useful detection taxonomy should tell reviewers what to inspect. The following categories describe proposed failure cases, rather than measured frequencies.
| Failure type | Illustrative defect | Required verification |
|---|---|---|
| Fabricated statistic | A percentage appears without an identifiable underlying measurement | Locate the original result and match its value, denominator, population, and period |
| Wrong entity | A capability belonging to one product is assigned to another | Match the named entity, product version, and attributed relationship |
| Invented source | A citation names a report that cannot be established | Verify the document’s identity, publisher, and relevant passage |
| Outdated claim | A historical capability is presented as currently available | Establish the claim’s effective period and evidence of continued applicability |
Treat these categories as overlapping. A statistic can have both the wrong denominator and an expired validity window. Preserve multiple defect labels when they explain different repairs.
An inaccessible source is a separate operational condition. It establishes an evidence-access problem, not fabrication by itself. Route the claim to review until an acceptable copy or replacement source is available.
Citation existence is also insufficient. A real report may contain no support for the attached assertion. Verify both the document and the proposition attributed to it.
For historical writing, retain the relevant date in the sentence. For present-tense guidance, require evidence appropriate to the publication period. Keep the entity, assertion, and validity window together.
Give every checkable claim an evidence record
Claim extraction should produce a reviewable inventory before any verification score determines publication. In this design, each record contains:
- A stable claim identifier and its exact location in the article.
- The original wording and a normalized proposition.
- Named entities, quantities, units, comparison groups, and time qualifiers.
- Evidence passages, document identity, and available version information.
- Evidence state, consequence category, reviewer decision, and resolution history.
Split compound sentences when their components need different evidence. A sentence can assert that a product exists, supports a capability, and produces a particular business result. Those are separate propositions.
Preserve the original sentence beside the normalized form. Otherwise, extraction could remove a qualifier that changes the claim’s meaning. Review hedges, exceptions, and words such as “all,” “only,” and “current.”
For a team using SiaSEO, the proposed evidence record should accompany each article version presented for approval. This recommendation describes an editorial requirement rather than an assumed platform capability.
An auditable content workflow provides the organizational context for assigning those records to owners and review stages.
Audit extraction separately from verification. Include headings, tables, captions, metadata, and comparative statements. A checker cannot assess an assertion that never enters its claim inventory.
Grounding and disagreement need separate jobs
The proposed detection layers answer different questions. Grounding evaluates support from evidence; disagreement identifies assertions that deserve additional investigation.
Match propositions to supporting passages
Retrieve evidence for the normalized claim, then compare the proposition with the relevant passage. Document-level similarity should not satisfy this check.
For a numerical assertion, compare the reported value, unit, denominator, population, and period. For a capability assertion, compare the entity, action, conditions, and version.
Consider a hypothetical draft that says a product supports every CMS. Its supporting passage documents an integration with one CMS. The passage supports a narrower statement. Rewrite the assertion to that scope or supply evidence for the broader claim.
RAG grounding practices belong at this stage, with an explicit boundary between supplied context and accepted evidence. The proposed check must still judge whether a passage supports the final wording.
Keep retrieved text within the evidence boundary. Instructions embedded in documents should have no authority over verification rules or publication decisions.
Use disagreement to prioritize investigation
Ask a separate verifier to assess the same claim against the evidence. Require a disposition and the specific passage that justifies it.
A disagreement should create a review task. Agreement should still require acceptable evidence. Two matching answers, without supporting material, leave the assertion unresolved.
Changing models or prompts does not, by itself, establish independence. Treat any benefit from verifier diversity as a hypothesis to evaluate on labeled articles.
Separate disagreements about evidence from disagreements about policy. One verifier might accept vendor documentation while another demands independent measurement. Resolve that difference through source eligibility rules before interpreting it as a factual dispute.
Preserve uncertainty through revisions
A repair creates new text that requires verification. Shortening a claim may resolve an unsupported generalization, but the revised sentence still needs its own support check.
Retain the earlier disposition in the history. Record whether the editor narrowed the claim, replaced its evidence, added a date, or removed it. Never overwrite an unresolved result with an unexplained approval.
Set publication thresholds by claim consequence
Publication thresholds should combine evidence state with the consequences of an error. A single article score is insufficient for this proposed policy.
Use categorical rules before numerical cutoffs. For example, block publication when an unresolved claim materially affects the article’s recommendation. Escalate consequential statements about security, contractual commitments, or financial outcomes to an appropriately qualified reviewer.
For lower-consequence claims, allow editors to remove unsupported detail or rewrite it as clearly identified analysis. An article with fewer factual assertions can still answer its intended question.
Auto-publication eligibility should require supported factual claims, completed mandatory reviews, and a verified final revision. A broken evidence dependency should return the affected claim to review.
The resulting queue needs an owner and a defined resolution path. Manual editorial queues can hold exceptions while editors inspect evidence, narrow wording, or reject a draft.
An interactive review selector would be useful here. It could accept claim type, consequence, evidence state, and time sensitivity, then display the applicable disposition and missing evidence.
Treat any numerical confidence threshold as provisional until evaluated against editor-labeled material. A model-generated confidence value should not be interpreted as an observed error probability without calibration.
Calibrate detection on editor-labeled articles
Detection quality needs an evaluation set that represents the intended publishing workload. The following design separates missed errors from unnecessary escalations.
Build labels around the actual editorial task
Select articles across the relevant topics, formats, claim types, and publication conditions. Include both routine drafts and difficult cases.
Reviewers should identify checkable claims before judging the detector’s output. Otherwise, the evaluation could exclude assertions the extraction stage missed.
Use written labeling rules and adjudicate disagreements. Distinguish contradicted claims from unresolved ones, and distinguish extraction failures from verification failures.
Keep development examples separate from the final evaluation set. Record model, retrieval, and policy versions so a later change has a defined comparison point.
When monitoring content quality drift, preserve these labels and slices. An overall average should not conceal poor results for numerical claims or a particular content category.
Measure errors that pass and flags that waste review
Consider a hypothetical evaluation containing 1,000 factual claims, including 100 editor-confirmed errors. Suppose the detector flags 200 claims and correctly identifies 80 errors.
Its error recall is 80%: 80 detected errors divided by 100 actual errors. Its flag precision is 40%: 80 actual errors divided by 200 flags.
The 800 unflagged claims still contain 20 errors. Their residual error fraction is 2.5%. These figures illustrate the calculations; they are not benchmark results or recommended acceptance thresholds.
Also report unresolved-claim frequency, extraction coverage, review time, and the proportion of articles containing a missed error. Claim-level averages alone cannot describe article-level exposure.
Choose acceptance thresholds before examining final results. Specify which errors are unacceptable and which content categories remain ineligible for automatic publication.
Bind approvals to the version that reaches the CMS
Verification should apply to the exact article revision approved for publication. A later wording change creates a new verification obligation.
Store a content hash or equivalent immutable version identifier with the claim inventory and approval record. Before publication, confirm that the payload matches the approved revision.
Treat edits to titles, tables, and metadata as potentially material. A headline that broadens a qualified claim should return to review even when the supporting paragraph remains unchanged.
For an agency using SiaSEO, this proposed control should apply consistently across client accounts. Assign responsibility for the final publication decision and document who can override a blocked claim.
The same discipline applies to evidence changes. Record which claims depend on each document. When a relevant source changes or becomes unavailable, identify the affected claims and assign reassessment.
Automated publishing risks belong in this release design because verification decisions must remain connected to the content delivered to readers.
A correction record should identify the affected assertion, the published revision, the replacement wording, and the approval decision. Set a review date or update trigger for claims whose validity depends on changing conditions.
Questions at the editorial gate
Exceptions need explicit answers before a draft leaves review. These decisions should remain visible in the claim record.
Can proprietary data support a claim?
Under this proposed policy, yes, when an authorized owner supplies the underlying record and approves its use. Preserve the measurement definition, period, population, and any restrictions on disclosure.
An editor should be able to distinguish a documented internal result from an unsupported promotional assertion. If the evidence cannot be reviewed by an authorized person, keep the claim unresolved.
Does every unresolved claim require deleting the article?
No. An editor can remove the assertion, narrow its scope, or replace it with clearly marked analysis. Recheck the revised article against its headline and intended purpose.
If the central recommendation depends on the unresolved assertion, withhold the recommendation until its evidence is adequate.
What remains outside this model?
This design cannot establish that an accepted source is itself correct. It also supplies no measured guarantee about extraction completeness, verifier accuracy, or reviewer consistency.
The operational findings are therefore conditional: preserve claim-level evidence, prevent uncertainty from becoming approval by repetition, and evaluate missed errors before widening publication eligibility. Keep unsupported claims out of the approved release.
