Your RAG pipeline is quoting sources it never verified

A 404 in the citation list nobody caught. Not an anomaly — this is the baseline of retrieval-augmented generation.

Your team reviews the RAG output. One answer cited three sources. Two resolved. The third returned a 404, and nobody had caught it, because the citation looked plausible and the prose sounded confident. Your team is not careless. This is what the tooling makes normal.

That failure is not an outlier or the result of an under-tuned model. It is the baseline operating reality of retrieval-augmented generation. When researchers aggregate cross-model evaluations across different domains and extraction methods, the reported citation fabrication rates span from 11% up to 57%. That spread reflects varying test methodologies rather than a single static base rate, but the lower bound is what matters for production systems. Even in favorable conditions, more than one in ten citations points to a phantom domain, a dead path, or a real document that says nothing about the generated claim.

If you maintain these systems, the structural problem is obvious. An LLM emits a citation-shaped string because its training objective rewards generating plausible citation syntax. Meanwhile, the retrieval layer may have fetched a document, or it may have pulled from stale cache, or it may have failed entirely while the model completed the answer from parametric memory. Standard pipelines keep no verifiable record of what was fetched, which endpoint returned it, what network route was taken, or whether the payload matches what reached the context window. When an incident occurs and an operator asks where a claim originated, the common answer is "it was in the prompt context." That is an execution trace, but it is not provenance.

Relying on prompt engineering to fix citation accuracy fails the moment you have to defend an answer to an auditor, a security team, or a regulator.

The legal and regulatory boundary has shifted

This stopped being an internal quality debate once legal and regulatory requirements caught up with deployed systems.

In Mata v. Avianca (678 F. Supp. 3d 443, S.D.N.Y. 2023), attorneys submitted federal court briefs citing non-existent judicial opinions generated by ChatGPT. The court imposed Rule 11 sanctions, establishing a clear precedent: submitting unverified machine output to a judicial body is sanctionable, and naming the model does not mitigate the failure. The entity operating and presenting the output bears full legal responsibility for verifying the underlying sources.

On the regulatory side, the EU AI Act's transparency framework takes effect on August 2, 2026. Under Article 99(4)(g), violations of these transparency mandates fall into the penalty tier carrying fines up to €15 million or 3% of total worldwide annual turnover, whichever is higher. Even if your direct infrastructure sits outside EU jurisdiction, enterprise customers subject to these requirements pass provenance expectations down the vendor chain. Showing an auditor a system prompt that says "cite only verified facts" is not acceptable documentation.

Academic and open-source work has started addressing parts of this stack. PCRAG focuses on answer-level certificates, while verbatim-rag targets provenance-first passage selection. Both projects are necessary progress, but they operate higher up the stack. A gap remains at the transport layer, where the raw network fetch actually occurs.

Implementing transport-layer provenance

In our production-ready pipeline, we treat every retrieval call as an auditable transport event. Rather than piping raw network responses directly into vector stores or prompt buffers, the retrieval engine issues a structured receipt containing four properties:

1. Byte integrity: A SHA-256 hash calculated over the exact payload received at the wire, ensuring downstream services can confirm the text was not modified or truncated between ingress and prompt construction.
2. Transport metadata: An immutable record of the retrieval transaction, capturing the UTC timestamp, HTTP status code, and TLS handshake parameters.
3. Egress security assertions: A recorded assertion that the retrieval request satisfied network egress policy — matching target allow-lists and passing CIDR block validation. This prevents the fetch worker from being coerced into hitting internal metadata endpoints or private network resources via server-side request forgery (SSRF).
4. State machine classification: An explicit status tag of VERIFIED, DEGRADED, or FAILED. If a fetch yields a non-200 status, an invalid TLS cert, or an unverified payload hash, the citation is flagged immediately so degraded or missing inputs cannot silently feed the generation context.

This approach requires no experimental components. It is standard infrastructure hygiene applied to the retrieval boundary — the specific surface auditors inspect when data integrity is questioned.

Reference implementation and technical guide

Reliability comes down to making failure states explicit rather than hoping components behave correctly.

We are packaging this retrieval architecture into a technical guide and a sanitized reference implementation. The material covers:

• SSRF-safe retrieval workers with strict egress boundary enforcement.
• The transport provenance schema and byte-level hashing pipeline.
• The citation state machine and verification lifecycle.
• Telemetry integration for compliance and security audit logs.

The package is available in paid early access for $199 while we validate demand across engineering, legal-ops, and security teams. This is a pay-now, ships-when-built model. If the validation threshold is not reached and the project does not proceed to full release, all early access purchases are refunded automatically in full.