When an AI may give a clear-cut verdict (and on what terms)
Direct answer: an AI system may allow itself a clear-cut verdict only when that verdict is anchored to a precise, verifiable citation — the exact text supporting it, shown to the user. In every other case it must explicitly state that it is making an inference, and separate that from the documented fact. This is not a tone preference: it is a structural rule deciding what the model is permitted to say, and it has to be written before the code is.
TL;DR
- The hard question in an AI product on sensitive topics is not technical: it is «how assertive may it be».
- Two symmetrical wrong answers: the model that asserts without anchoring, and the model that never concludes anything («it depends, consult a professional»).
- The rule that works: clear-cut verdicts allowed only with a precise citation; everything else is labelled as inference.
- You need an explicit, visible separation between documented fact and system inference — in the answer, not in the documentation.
- This pattern is not new: it is the same one used in knowledge graphs to distinguish authoritative edges from generated ones, and it transfers unchanged.
The problem, in the abstract
Imagine a system that answers questions about laws and public data. A user asks whether a given entity falls within a category defined by a constitutional provision. A correct answer exists, it is arguable, and it has consequences: if the system says «yes», it is asserting something heavy about a real entity; if it says «I cannot know», it renders the entire product useless at exactly the moment it was needed.
That is the situation. And it is a design situation, not a prompt-engineering one.
The two wrong answers
The model that asserts without anchoring. The most dangerous, because it is also the most convincing. It produces a clean conclusion, in good prose, with an authoritative tone the user has no means to verify. When it is right it is useful; when it is wrong it is indistinguishable from when it is right. That is exactly the failure knowledge graphs are supposed to prevent, and which returns whenever the view is mistaken for the asset.
The model that never concludes. This is failure through excess caution, and it is almost always mistaken for responsibility. «This is a complex matter depending on many factors; you should consult a professional.» Technically unimpeachable, practically useless. A product that never concludes anything does not have a safety problem: it has an existence problem.
The point is that these two failures do not cancel each other out. Tightening against the first produces the second. You need a third thing.
The rule: verdicts only with citation
The rule I adopted, and which held:
The system may give a clear-cut verdict if and only if it shows the exact text supporting it. No precise citation, no verdict.
The trick is that this rule does not constrain the model by topic — there is no list of forbidden subjects, which would be brittle and arbitrary — but by the form of the evidence. The model may be blunt on an explosive topic, provided it is reading aloud from a text the user can go and check. And it may not be assertive even on a harmless topic if it is reasoning on its own.
That moves the risk to where it is manageable: from the model's opinion to the verifiability of the source.
The second rule: fact and inference, separated and visible
Citation alone is not enough, because most useful answers are composite: a documented piece plus a logical step. So the answer has to be structured into two declared blocks:
| Block | What it holds | How it is presented |
|---|---|---|
| Documented fact | What follows from verifiable sources: texts, acts, statutes, precedents, public data | With the precise citation beside it |
| System inference | The logical link between facts, the conclusion, the assessment | Labelled as such, with a confidence level |
The separation must be in the answer the user reads, not in a methodology note nobody opens. If the user has to work to see where the document ends and the model begins, the separation does not exist.
The pattern was already there (and that is the interesting part)
What struck me is that I invented nothing. The same system already used this distinction elsewhere, for a completely unrelated problem: in the knowledge graph, edges between norms come in two kinds — authoritative edges, derived from explicit references in the texts, and generated edges, proposed by the model and marked as such with a confidence level.
It is precisely the same idea: distinguish what is documented from what is deduced, and make it visible to whoever consumes it. It had been designed for a data-quality problem. It turned out to be the exact answer to an editorial and legal accountability problem.
Worth keeping as a general heuristic: when you face a hard design decision on an AI product, check whether the system has already solved the same shape of problem elsewhere. Very often the good pattern is already inside, applied to a different domain, and reusing it costs a fraction of inventing a new one — while making the system more coherent with itself.
Why this is a product problem, not a prompt problem
The temptation is to solve it in the system prompt: «be cautious», «do not make claims about people». It does not work, for two reasons.
First: tone instructions are negotiable by context. A sufficiently insistent or ambiguous input erodes them. A rule saying «no citation, no verdict» is verifiable downstream: you can check programmatically whether the citation is there.
Second: the prompt is not inspectable by the user. The fact/inference separation has to be an observable property of the output, because that is what lets the reader do their own checking. A product that asks for trust instead of providing the means to verify has moved the problem, not solved it.
And there is a compliance point worth stating: making it visible when a conclusion is model-generated is not just good editorial practice. It is the direction transparency obligations for AI systems are heading — the same logic by which a chatbot has to disclose that it is a chatbot. A system that labels its own inferences is already aligned by construction.
FAQ
Is it not safer to stop the model from concluding on sensitive topics?
No: that is the most common failure mode dressed up as caution. A system that never concludes is not safe, it is useless — and users with a legitimate question will go find the answer from a less rigorous source. Safety lies in anchoring, not in silence.
How do you verify that an answer is genuinely anchored?
By making it a programmatic check rather than a hope: if the answer contains a verdict but no precise reference to a retrieved text, it does not ship as it is. It is a constraint you can test like any other business rule.
How is this different from simply asking the model to cite sources?
«Cite your sources» is a style instruction and gets applied unevenly. «No verdict without a precise citation» is a structural constraint on the shape of the answer: it ties the degree of assertiveness to the presence of verifiable evidence, and makes the difference between what the system read and what it deduced observable.
Does this approach only apply to legal domains?
No. It applies anywhere a wrong conclusion has consequences for someone: healthcare, finance, compliance, assessments of people or companies. The shape of the problem is always the same — a model linking facts and producing a judgement — and separating documented from deduced is always the right lever.
If you are building an AI product touching areas where being wrong has consequences, and you need to decide how far the model may go, let's talk. It is an architecture decision, and it is best made before writing the code — not after the first embarrassing answer.
Related articles
- PNRR contracts: five public systems that do not talkFinding out who won an Italian PNRR contract takes at least five different public databases, none of which is designed to be queried alongside the others. The technical record, source by source, from someone who actually tried.
- The worst bug does not break the feature. It breaks the view26 tools connected and working in production, the dashboard showed zero. The bug had been there for months for another product too, and nobody had seen it because whoever could notice had admin permissions.
- It knew 22,000 rulings, but not one bill numberA system holding constitutional case law since 1956 could not find a bill searched by its number. Nobody had ever tested it: it seemed too obvious to be broken.