Skip to content
Teardown

Teardown: Deterministic Citation Provenance

The model writes the answer; the backend decides what it may point at. A grounding critic, marker resolution against the execution record, and why rendering a citation is a security boundary.

4 min read

A number in a forecast is worth nothing unless it can be opened to reveal the query that produced it. That property is architectural, not a prompting technique: citations are generated deterministically by the backend from the tool-call record, never by the language model, and any marker the model invents is stripped before the text is rendered.

This is the teardown of that mechanism: where the citation comes from, what rejects a bad one, and why the rendering step is a security boundary rather than a presentation detail.

From the standard

“Manipulating LLMs via crafted inputs can lead to unauthorized access, data breaches, and compromised decision-making.”
OWASP, LLM01: Prompt Injection — owasp.org

Why model-generated citations fail

Asking a language model to cite its sources asks it to produce a token sequence that looks like a citation. It is very good at that. The resulting marker is generated by the same process that generated the claim, which means it inherits exactly the same failure mode: a fluent, plausible, confidently formatted reference to something that does not exist.

Verifying such a citation requires the reader to do the work the citation was supposed to save them. At that point the feature is worse than absent, because it manufactures confidence.

Where the citation actually comes from

  1. tool call dispatched
  2. args, result set, timestamp, trace id
    EXECUTION RECORD Written before the model speaks The record of what actually ran exists independently of the narrative that describes it.
  3. THE MODEL COMPOSES A NARRATIVE Free to reason, not free to assert
  4. 1 · GROUNDING CRITIC Does it reference an entity absent from the index? If so, the answer is rejected before any human sees it.
  5. passes
    2 · MARKER RESOLUTION Invented markers stripped, real ones linked A marker matching an execution record is bound to it. A marker matching nothing is removed rather than shown.
  6. every marker in the rendered answer resolves to a real call
Citations are generated by the backend from execution records — never by the model.

The ordering is the design. The execution record exists before the narrative does, so a citation is a pointer into something that already happened rather than an assertion made alongside the prose. The model's job is to write; the backend's job is to say what the writing is allowed to point at.

The grounding critic

Stripping invented markers handles the citation. It does not handle output that is confidently about an entity which is not in the index at all — a signal that does not exist, a requirement nobody wrote, a table absent from the catalog. A grounding critic runs first and rejects that output before a reviewer ever sees it.

Why it runs before the human, not after

A reviewer who is shown mostly-correct output learns to skim. Every ungrounded item that reaches the queue trains the reviewer to trust the queue slightly more than it deserves, and review quality degrades across everything else in it. Filtering before the queue protects the reviewer's attention, which is the scarce resource in the whole system.

In the verification deployment this pattern came from, the index holds roughly 35,000 signal entities and more than 45,000 embedded code chunks. Requirements are matched against real signal entities with a re-ranking pass, and generated cases that reference a signal absent from that index are rejected rather than queued.

Separate citation planes

Not every source is the same kind of thing, and collapsing them loses the distinction that makes a citation useful. Conversational questions over the corpus carry three separate citation planes — signals, requirements, and code — with repository-scoped filtering across multi-turn context.

An engineer reading an answer can then tell whether a claim rests on a requirement document, on the implementation, or on a measured signal, which are three different kinds of evidence with three different failure modes.

Rendering is a security boundary

A citation that renders as a clickable link is an egress channel if the URL is attacker-controlled. This is the subtlest of the tool-abuse failure modes: an attacker who can influence a URL the model emits gets data out encoded in the request itself, with no tool call involved and nothing in the logs that resembles exfiltration.

Deterministic citations close this by construction. A marker that does not resolve to a recorded tool call is removed rather than rendered, so there is no path by which model-authored text becomes a live outbound request.

What it changes in practice

In the revenue deployment, this single property is what moved the conversation from whether the system could be trusted to which systems to connect next. A number in a forecast could be opened to reveal the exact query behind it, so the question of trust became a question of scope.

The cost is that the system says less. An answer that cannot be grounded is not produced, and a user asking a question the corpus does not cover gets told so rather than getting a fluent paragraph. Whether that trade is right depends entirely on what the answer is used for — and in a forecast, a report, or a test plan, it is not close.

Axionalytics

Production agentic AI for enterprise engineering, data, and revenue teams.

Keep reading

Facing this in your own environment?

Forty-five minutes with the engineers who build these systems. Bring the constraint that has been blocking you — you will leave with an architecture opinion whether or not you work with us.