How Ethos Verifies AI Citations
Developer Guides

How Does Ethos Verify AI Citations Against Source Documents?

DocuShell TeamJuly 6, 202614 min read

Direct answer

Ethos verifies an AI citation by comparing a caller-provided evidence claim with a trusted document evidence source. It checks source fingerprint freshness, resolves pages or evidence identifiers, tests the requested quote, value, cell, presence, or region, records source capability limits, and returns a structured verification report.

The verifier does not accept the model’s reference as truth. The application must resolve model-returned IDs through trusted parser artifacts or a source map. Ethos then answers the bounded question: does this citation bind to evidence exposed by this grounding source?

For the product overview, read what Ethos is for document AI. For general implementation principles, use the AI citation verification guide.

The verification inputs

Ethos needs two main inputs.

A grounding source

The source exposes trusted document evidence through GroundingSource. It can provide:

  • parser identity;
  • capabilities;
  • document fingerprint;
  • page geometry;
  • text elements;
  • spans or character offsets where available;
  • tables and cells where available;
  • stable evidence identifiers;
  • regions and crop support where available.

Citation claims

The caller provides the propositions to test. A citation may expect:

  • a quotation at an element or page;
  • a normalized value;
  • page-level presence;
  • a particular table cell;
  • a region or evidence target;
  • a matching document fingerprint.

Ethos does not generate the final answer or invent missing citations during this step. Verification evaluates the submitted request.

The end-to-end verification flow

generated answer
  -> application extracts or receives structured claims
  -> evidence IDs resolve through trusted source map
  -> citation request is validated
  -> Ethos reads GroundingSource evidence
  -> fingerprint and evidence checks run
  -> VerificationReport is written
  -> application adds relevance and synthesis policy
  -> show, partial, review, block, or abstain

Every transition is a security and correctness boundary. A generated evidence ID is merely a request until the trusted source confirms it.

Step 1: validate the request

Before evidence matching, the verifier checks whether the citation shape is valid. Malformed IDs, invalid coordinates, unsupported evidence kinds, or schema errors should produce an invalid-request or usage outcome rather than an ambiguous ungrounded score.

Applications should distinguish:

  • malformed input;
  • adapter or source-shape failure;
  • completed verification with negative evidence results;
  • infrastructure failure.

These states require different remediation.

Step 2: compare source fingerprints

When citations are fingerprint-pinned, Ethos compares the requested fingerprint with the grounding source fingerprint. A mismatch means the citation was prepared against different source content.

Fingerprint checking prevents a dangerous shortcut: approving an old citation simply because similar text also appears in a new file. The submitted citation is stale even if a correction might be generated later.

Fingerprint state Interpretation Safe action
Match Citation and source version align Continue evidence checks
Mismatch Citation targets different source content Mark stale and block reuse
Required but unavailable Source cannot prove exact version Report limitation or fail policy
Not requested Verification lacks version pinning Continue only if policy permits

The application still determines which source revision is authoritative. Ethos checks identity against the source it receives.

Step 3: resolve the locator

Locators narrow the evidence proposition. Depending on the claim, Ethos may resolve:

  • page identity;
  • element ID;
  • span or character range;
  • table and cell identity;
  • bounding region;
  • page-level presence.

IDs must be stable and unique within their namespace. Foreign parser adapters should reject ambiguous duplicate IDs rather than selecting the first match.

Page numbering requires care. Parser-neutral page identity may differ from printed page labels. Applications should display human labels while retaining the verifier’s stable machine index.

Step 4: check the evidence

Quote checks

The verifier compares the requested text with source evidence according to its configured matching rules. Normalization must be bounded so whitespace or encoding differences do not create noise without erasing meaningful negation, signs, or qualifiers.

Value checks

Values should retain unit, scale, sign, currency, date, and source context. A number appearing elsewhere on the page is not necessarily the cited value.

Presence checks

Presence can establish that specified content or an element exists on a page. It should not be described as semantic support for a broader conclusion.

Table-cell checks

Cell verification depends on table capability. Row and column context matter. When a foreign source exposes only flattened text, Ethos reports a capability limitation rather than pretending to verify table structure.

Region checks

Region evidence depends on page geometry, coordinate origin, bounded boxes, and stable element relationships. Optional crops can provide human-inspectable artifacts.

Step 5: respect source capabilities

GroundingSource makes capabilities explicit. A source can declare whether it supports spans, character offsets, tables, fingerprints, coordinates, or cropping.

Requested proof Required source evidence If unavailable
Exact source version Fingerprint Report capability or policy failure
Page quotation Page plus element text Limit or reject check
Table cell Structured table and cell mapping Capability limited
Character range Stable offsets or spans Capability limited
Visual region Geometry and coordinate convention Capability limited
Rendered crop Crop support and source PDF access Descriptor-only or unavailable

This fail-honestly behavior is central to Ethos. Parser output is never silently upgraded into stronger evidence than it contains.

Step 6: produce a canonical report

The verification report records individual checks, overall grounding state, warnings, fingerprint status, source identity, configuration identity, and capability limitations according to the active schema.

An illustrative application-facing summary might contain:

{
  "proof_status": "partially_verified",
  "request_certified": false,
  "reusable_grounded_checks": ["v0001", "v0002"],
  "needs_review_checks": ["v0003"],
  "proof_limitations": ["table capability unavailable"]
}

The canonical report remains the audit artifact. A summary is derived communication, not replacement evidence.

Grounded does not mean semantically complete

Suppose a source contains: “Revenue increased to $12.4 million.” Ethos can verify that a citation binds to that evidence. The claim “the product launch caused revenue to increase” adds causality not contained in the quotation.

Applications should maintain three axes:

Axis Question Owner
Citation grounding Does the reference exist and match? Ethos
Question relevance Does the evidence answer or support the user? Application or evaluator
Synthesis level Is the claim direct or inferred? Application policy

Only a grounded, relevant direct source fact should normally flow directly into a final answer. Calculations need deterministic recomputation; synthesis needs an explicit policy.

Native Ethos JSON verification

The native path provides the fullest current evidence shape because the parser and verifier share a documented document model. Pages, elements, coordinates, tables where supported, fingerprints, citations, and crop descriptors can remain connected.

A typical CLI shape is:

ethos verify document.ethos.json \
  --citations citations.json \
  --fail-on-ungrounded \
  --out verification_report.json

When verification completes but requested evidence is not fully grounded, the enforcement flag can produce a non-zero gate while still writing the report. Invalid input uses a separate failure path.

Foreign parser verification

A foreign parser can integrate through an adapter. The adapter maps parser-native pages, elements, tables, regions, fingerprints, and capabilities into Ethos evidence concepts.

foreign parser output
  -> adapter
  -> GroundingSource
  -> Ethos citation checks
  -> VerificationReport

The current documentation includes an OpenDataLoader-style JSON adapter path. Other integrations should implement stable ordering and IDs, deterministic geometry conversion, explicit capabilities, and fail-closed locator validation.

Verification from Python

The published Python wrapper is intentionally thin and invokes a caller-provided Ethos CLI. A representative JSON-verification call is:

from ethos_pdf import EthosCli

ethos = EthosCli(binary="/path/to/ethos")
report = ethos.verify(
    source="document.ethos.json",
    citations="citations.json",
    fail_on_ungrounded=False,
    output_format="json",
    timeout=30,
)

print(report["all_evidence_grounded"])

The wrapper does not turn negative grounding outcomes into semantic truth decisions. Applications should inspect the report and apply release policy.

Adversarial cases to test

  1. Correct quote and fingerprint.
  2. Correct quote on the wrong page.
  3. Changed negation.
  4. Missing element ID.
  5. Duplicate foreign-parser ID.
  6. Stale source fingerprint.
  7. Correct number with wrong unit.
  8. Correct cell value under wrong header.
  9. Out-of-page bounding box.
  10. Table request against text-only source.
  11. Valid evidence attached to an irrelevant claim.
  12. Multi-source synthesis with a missing premise.

The first ten test verifier and adapter behavior. The last two test the application boundary above Ethos.

Definitive verdict

Ethos verifies AI citations by resolving bounded evidence claims against a trusted, capability-declaring document source. It validates requests, checks fingerprints, resolves locators, compares evidence, reports limitations, and preserves a canonical audit artifact.

Use DocuShell Parse PDF to evaluate source-aware document artifacts, Ethos for citation grounding, the RAG release-gate guide for application policy, and the DocuShell hallucination index for broader workflow-risk context.

Primary keyword: Ethos citation verification
Optimized meta title: How Ethos Verifies AI Citations
Optimized meta description: See how Ethos checks source fingerprints, locators, evidence, and parser capabilities to produce auditable AI citation reports.
Proposed URL slug: how-does-ethos-verify-ai-citations-against-source-documents

Frequently Asked Questions

Ethos resolves caller-provided citation claims against a trusted GroundingSource, checks the source fingerprint and evidence locator, compares the requested evidence, and records structured outcomes.
The verifier can check evidence such as quotations, values, page presence, elements, table cells, and regions when the grounding source declares the required capabilities.
It proves the recorded citation-grounding checks and limitations for a specific request and source. It does not independently prove answer relevance, reasoning, or universal factual truth.
No. Native Ethos JSON offers the fullest current path, but a foreign parser can supply evidence through a GroundingSource adapter.

Free Tool

PDF to JSON

Turn PDFs into structured, source-aware data for RAG, review, and automation.

Try PDF to JSON
Ethos citation verificationverify AI citationssource document verificationGroundingSourcedocument evidenceRAG citations
D

DocuShell Team

The DocuShell editorial group writes and maintains guides for everyday PDF workflows, with updates made when tool behavior or documented limits change. See our editorial standards for the process behind each article.

Focus: Ethos integration, source-aware document evidence, citation verification, and RAG release controls

Questions or feedback? Get in touch.

Related Articles