Avoiding Hallucinated Citations in Automated Content

A fabricated citation is an unusually dangerous kind of plausible text. It can contain a credible author, a familiar journal, a realistic title, and even a DOI-shaped string. The sentence around it may be accurate. Yet the cited work may not exist—or it may exist without supporting the claim.

That is why citation safety cannot be reduced to asking a writing model for sources or checking whether a URL returns a successful response. An automated publishing system needs a verification boundary between generated prose and publication.

For Coffee House Digital, the rule is simple:

no verified source record -> no supported claim -> no publication

This rule treats citations as evidence objects that must pass explicit checks, not as decorative strings added after drafting.

Define the failure precisely

The term “hallucinated citation” often hides several different failures:

| Failure | What went wrong | | --- | --- | | Fabricated source | The named work does not exist. | | Corrupted identity | The title, author, date, journal, or identifier belongs to a different work. | | Unsupported claim | The source exists but does not support the sentence attached to it. | | Scope inflation | The source supports a narrower result than the article claims. | | Version mismatch | The citation points to a different edition or revision than the one reviewed. | | Unverified secondary citation | The draft repeats another author's citation without checking the original source. |

NIST calls confidently stated false content from generative AI confabulation and specifically notes that generated output can contain confabulated citations that appear to justify an answer [1]. Fluent presentation is therefore not evidence of source validity.

The distinction matters operationally. Identifier lookup can catch a fabricated DOI or corrupted title, but it cannot determine whether a real paper supports a particular sentence. Citation verification needs both machine checks and editorial judgment.

Make the researcher prove source identity

The Researcher should create a structured source record before the Writer uses a source. At minimum, record:

• the exact title and authoring organization or authors;
• the canonical URL or persistent identifier;
• the publisher, standards body, journal, or repository;
• the publication date and version when relevant;
• the access date;
• the specific claim the source can support; and
• the section, table, figure, or page where that support appears.

For scholarly material, a DOI should be resolved through https://doi.org/, then compared with authoritative metadata. The DOI Foundation describes a DOI name as a unique, persistent identifier that resolves to a maintained record, while also making clear that persistence depends on maintaining that record [2]. Crossref's REST API exposes deposited scholarly metadata and provides a single-record lookup for a DOI [3].

Those systems make identity checks automatable. A workflow can normalize a DOI, resolve it, retrieve registry metadata, and compare title, authors, publisher, and date with the proposed citation. A mismatch should stop the citation from entering the draft.

Not every authoritative source has a DOI. Standards, laws, product documentation, and public datasets may use stable publisher URLs, report numbers, or versioned releases instead. The underlying test remains the same: can the workflow establish that the cited object is the object the researcher actually reviewed?

Separate reachability from validity

A successful HTTP request proves very little about editorial correctness. It shows that a server handled a request; it does not prove that the returned page is the intended source or that the page supports the article's claim.

HTTP defines HEAD as a way to request the same headers a server would send for GET without transferring the response content [4]. That is useful for inexpensive link monitoring, but it is only a transport check. Redirects can lead to a generic home page. A publisher can replace content at the same URL. An error page can return 200 OK. Some valid sources reject HEAD while serving GET correctly.

Use layered checks instead:

1. Syntax: Is the URL or identifier well formed?
2. Resolution: Does it resolve without an unexplained redirect or error?
3. Identity: Do title, author, publisher, date, and version match the source record?
4. Authority: Is this the original publisher, registry, standards body, or official repository?
5. Support: Does the source directly support the attached claim?
6. Context: Does the article preserve the source's limits, qualifications, and uncertainty?

The first three checks are good candidates for automation. The last three usually require editorial review.

Bind each important claim to evidence

A list of five sources at the end of an article does not show which source supports which assertion. During research and editing, preserve a claim-to-source mapping:

claim_id: citation-identity-01
claim: A DOI identifies a referent independently of its current location.
source: DOI Handbook, sections 1.3.1 and 5.4.1
support: direct
limitations: persistence requires record maintenance
verification: researcher checked identity and passage on 2026-09-24

This record gives the Editor something concrete to test. Starting from the claim, the Editor can find the evidence. Starting from the evidence, the Editor can see whether the draft expanded beyond its scope.

Claim binding is especially important for numbers, causal statements, comparisons, legal or safety guidance, and claims attributed to named researchers or institutions. General editorial advice may not need a citation in every paragraph, but any citation that appears must genuinely earn its place.

Do not let the Writer invent the bibliography

The safest sequence constrains the Writer to an approved research packet:

Researcher: discover -> retrieve -> verify identity -> map claims
Writer: use only approved sources -> draft with source markers
Editor: open sources -> test support and scope -> accept or reject
Publisher: validate metadata -> build -> merge -> verify production

The Writer may flag a missing source, but should not silently fill the gap with a plausible reference from memory. When evidence is absent, the valid choices are to soften or remove the claim, return the question to research, or block publication.

This boundary also prevents citation laundering. Repeating a reference found in a secondary article is not verification. The Researcher should retrieve the original work when the claim depends on it, then cite the source actually inspected. If the original cannot be obtained or verified, the article should state the limitation or omit the claim.

Give the Editor a citation-specific checklist

General copyediting does not reliably catch citation failures. Add explicit acceptance criteria for every consequential citation:

• I opened the cited source rather than relying on a generated summary.
• Its identity matches the article metadata.
• The relevant passage supports the attached claim.
• The draft preserves material conditions and uncertainty.
• Quotations, figures, and numbers match the source.
• The citation points to the most authoritative practical version.
• The public reference contains enough information for a reader to locate it.

A failed item is a finding, not a minor style note. The Editor should reject the claim or return it for another research pass. A QA score cannot average away an unverifiable citation: citation validity is a hard publication gate.

Automate the checks that fail predictably

Automation is useful when it narrows the Editor's attention without pretending to replace review. A citation validator can:

• reject duplicate or malformed URLs;
• require HTTPS except where an authoritative source does not provide it;
• normalize DOI forms and compare registry metadata;
• follow redirects and record the final host;
• flag a final host that differs from the expected publisher;
• compare page title and structured metadata with the source record;
• require an access date in YYYY-MM-DD format;
• detect citations that are never referenced in the article; and
• fail when a claim marker has no approved source.

The validator should preserve reasons, not merely produce a pass/fail light. “Title mismatch: proposed source says X, registry says Y” is actionable. “Citation confidence 0.72” is not.

Network checks must also be repeatable and bounded. Record redirects and retrieval time, use timeouts, and distinguish a transient outage from a confirmed identity mismatch. A temporary failure can justify a retry; it cannot justify publishing an unverified citation.

Treat sources as mutable dependencies

Citation verification is not finished forever at publication. Web pages change, registries update metadata, standards release new editions, and links disappear.

The source record should therefore retain the version, publication date, report number, or section used during review. For high-consequence claims, preserve an archival reference when policy and licensing allow it. Periodic link checks can identify operational decay, while editorial review determines whether the evidence itself has changed.

When a source changes materially, update the article transparently. Record the new access date and modification date, revise affected claims, and let Git preserve the content diff. Do not silently swap a citation for a superficially similar source.

A practical stop policy

An automated article should stop before publication when any of these conditions is true:

• a cited work cannot be found in an authoritative location;
• identifier metadata conflicts with the proposed citation;
• the source is reachable but the relevant support cannot be located;
• the article states a stronger conclusion than the source permits;
• only a secondary mention is available for an important claim;
• the version reviewed cannot be identified; or
• the source requires access the Editor does not have and no qualified reviewer can verify it.

The run record should name the exact failure and the next useful action. “Citation check failed” is too vague. “DOI resolves, but Crossref title and authors do not match the proposed reference; Researcher must identify the correct work” is auditable and recoverable.

The goal is warranted trust

Perfectly formatted references can still be false, and real sources can still be misrepresented. A trustworthy automated publishing system therefore verifies four separate things: the source exists, its identity is correct, it is authoritative enough for the claim, and its contents support the language that readers will see.

That process deliberately introduces friction. The friction is useful. It moves confidence away from a model's tone and into evidence that a Researcher, Writer, Editor, and later reviewer can inspect.

The practical test is not “does this citation look credible?” It is: “could another editor follow this reference, find the same source, locate the supporting passage, and agree that the article preserved its meaning?” If not, the citation is not ready to publish.

Sources

1. National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1. Accessed September 24, 2026. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
2. DOI Foundation, “DOI Handbook.” Accessed September 24, 2026. https://www.doi.org/doi-handbook/html/
3. Crossref, “REST API.” Accessed September 24, 2026. https://www.crossref.org/documentation/retrieve-metadata/rest-api/
4. Internet Engineering Task Force, “RFC 9110: HTTP Semantics,” section 9.3.2. Accessed September 24, 2026. https://www.rfc-editor.org/rfc/rfc9110.html