Language models are fluent. That is their gift and their hazard. A fluent wrong answer reads exactly like a fluent right one, and in a business context the wrong one can end up in a proposal, a commitment, or a board slide.
The fix is not a smarter model. It is a rule: every claim points to where it came from, or it does not get made.
What a citation has to do
A citation is not decoration. It has three jobs.
Let someone verify in thirty seconds. The reader should be able to click through to the exact file, and ideally the exact passage, and see the sentence that supports the claim. If verification means opening a folder and searching, the citation has failed.
Make the model honest. A model that must cite cannot invent. If there is no passage to point to, there is no claim to make. This is a stronger constraint than any instruction to "be accurate."
Preserve the words that matter. Reasons and decisions especially. "Declined because it would compete with an existing study for the same patients" is a citation to a committee's note. "Declined for strategic reasons" is a paraphrase that lost the information.
Grounding is a discipline, not a feature
Citing is necessary but not sufficient. A model can cite a real file and still infer beyond it: read that a project was lost and that a vendor was slow, and connect the two because it seems plausible.
The discipline we hold Desk to is stricter:
- State only what a file states. Reasons and causes are claims too, and a reason attaches to an item only when a file gives that reason for that item.
- Do not transfer a reason from one item to a similar one, and do not connect two facts causally unless a file connects them.
- When files disagree, report both and their sources.
- When files are silent, say so in one sentence and stop.
- When the model does go beyond the files because the question asked for a judgement, mark the sentence: "My inference:" or "Not stated in the files:".
The last rule matters most. A reader should never have to guess which sentences are sourced and which are the model's.
Report, do not interpret
There is a temptation, when building these tools, to let the model be helpful: to fill gaps, smooth over inconsistencies, and produce a tidy narrative. Resist it. The value of a knowledge base is that it says what the organization actually recorded, including the gaps and the inconsistencies. A report that a file is silent on a question is useful information. A plausible guess presented as fact is a liability.
What this looks like in practice
Ask a well-grounded system "why did we lose the phase-two proposal" and a good answer looks like this: the proposal was not selected; the client list records "budget deferred to next fiscal year" as the reason; source, the 2025 client list and the proposal close-out. Every clause points somewhere.
Ask it something the files do not cover, and a good answer says so and lists what it searched for. That is not a failure. It is the system telling you the truth about what your organization has written down, which is exactly what you asked it to do.
How Desk helps
Grounding is how Desk is built, not a setting.
- Every claim in an answer links to the record or the file it came from; one click shows the supporting passage.
- Desk is instructed to report what the files state, to keep their wording for reasons and decisions, and to label anything beyond that as its own inference.
- When the files are silent, Desk says so and lists what it searched for, instead of filling the gap.
Thinking about how this would work for your team?
Let’s chatKeep reading
"Have we done this before?" is the most expensive question in your company
It gets asked a dozen times a week, it is almost always answerable from files you already have, and the answer usually arrives too late to matter.
Read more →Tribal knowledge: what it costs and how to capture it without a reorg
The knowledge that walks out the door is rarely written nowhere. It is written somewhere unfindable. The fix is not asking people to document more.
Read more →