Part 2: Vigilance Is Verification: The Post-Execution Architecture Your Workflow May Be missing
Research Memo #5
The promise: by the end of reading this you will know how to evaluate AI output after it arrives factual outputs by verifying claims, constructed outputs by testing frames.
The most dangerous AI output is often the one that looks finished. Factual outputs need claim verification. Constructed outputs need frame testing. The discipline is knowing which kind of output you have, and applying the right evaluation layer before you trust it.
TL:DR
The Evaluation Vacuum doesn’t die when your brief is clean. It moves downstream, to the moment the output lands looking finished. See RM-4’s Horseman IV.
Anthropic’s Fluency Index surfaces the uncomfortable pattern: discernment appears to drop when the work looks polished. The more finished the artifact feels, the less likely users are to fact-check, question reasoning, or notice missing context.
AI makes this worse because polish is part of the optimisation pattern. RLHF-trained models are not optimised directly for truth; they are optimised for outputs humans rate as helpful, coherent, and acceptable. Goodhart’s Law applies: the proxy can drift from the thing we actually care about. Polish is not evidence of soundness.
There are two kinds of output, and two different failures.
Factual retrieval outputs fail by unverified assertion.
use the Two-Output Architecture: prose plus a real claims database, verified before trust.
Constructed outputs — frameworks, plans, arguments, strategies — fail by unchallenged framing.
use the Five Frame-Checking Conditions. The final two test the warrant: the hidden bridge between what the framework claims and why that claim is supposed to hold.
The evaluation practices have to match the failure.
Ill say it again, because its important, the evaluation practices have to match the failure.
The checklist is the training wheels for phronesis — practical judgement — until the habit of interrogation runs without the scaffold or is encoded into the architecture.
In Part 1, I argued that evaluation begins before you prompt: you need context, success criteria, and a clear task shape before asking the model to task effectively. You can weed out ambiguity with being more clear and specific. You can identify contradicting instructions pretty easy too. Add in scoping and constraints when the output produces something knowable wrong.
But the Evaluation Vacuum wears a blindfold for a reason. Its harder to see. and appears twice.
It appears before execution, when the brief is vague. And it appears after execution, when the output arrives looking so complete and polished that you stop interrogating it.
This memo is about that second vacuum: the moment AI output looks finished.
The Polish Problem
The Anthropic Education Report The AI Fluency Index — a non-peer-reviewed 2026 analysis of 9,830 Claude.ai conversations — surfaces an uncomfortable pattern.
When Claude produced polished artifacts such as documents, code, plans, or structured outputs, users became more directive but less likely to fact-check, question reasoning, or notice missing context.
Discernment appears to drop at the exact moment the output starts to look finished.
That is the Polish Problem. Surface quality creates the feeling that evaluation has already happened. The output looks coherent, so the reader becomes less inclined to test whether it is sound.
Because The Evaluation Vacuum doesn’t disappear after a well-structured brief. It relocates. It moves from the input stage to the output stage, where it’s harder to see because everything looks and sounds so coherent.
An illustrative example
Here is the problem in miniature. An earlier draft of this article included this sentence:
“High-fluency users — the 85.7% whose conversations involve genuine iteration rather than first-output acceptance — treat the finished-looking artifact as a draft hypothesis, not a conclusion.”
It sounds plausible. It is also wrong.
Anthropic does not say that 85.7% of users are “high-fluency users.” It says that 85.7% of analysed conversations showed the observable behaviour “iterates and refines.” That is a conversation-level behaviour, not a classification of stable user competence.
The model had compressed a real finding into a cleaner but false claim. It preserved the shape of insight while damaging the factual boundary.
So the practical question is simple: what does it look like to close the loop after the output arrives?
Two Failure Modes. Two Different Practices.
The first move is to stop treating all LLM outputs as the same kind of object.
For evaluation purposes, there are two broad types.
1. Factual retrieval outputs - make assertions about the world.
Research summaries, cited claims, data synthesis, source-grounded analysis. These fail through unverified assertion; the model produces confident prose that looks sourced but isn’t checked. The failure is detectable in principle: every claim either has a valid source or it doesn’t.
2. Constructed outputs - build something.
Frameworks, strategies, arguments, plans, analyses. These fail through unchallenged framing; the output is internally coherent, structurally complete, and built on a premise that was never interrogated. The failure isn’t detectable by checking sources. There are no sources to check. The failure lives in the architecture of the argument itself.
These two outputs require different practices. Factual outputs need claim verification. Constructed outputs need frame interrogation.
If you are using AI for anything public, professional, reputational, or high-stakes, verification is not optional.
LLMs can compress hours of drafting or research into minutes. The discipline is to reinvest some of that saved time into checking. The time saving is only valuable if it does not become a trust leak.
The uncomfortable corollary is that expertise does not fully protect you. Once the output looks finished, even careful users can become less sceptical.
Factual outputs need claim verification. Constructed outputs need frame interrogation.
Practice One: The Two-Output Architecture
For factual retrieval outputs, use a two-output architecture.
Output 1 is the prose: the readable explanation, summary, article section, or research synthesis. That’s The LLMs default, including your ‘deep research’ reports.
Output 2 is the claims database: a structured table where every important assertion from the prose is made independently checkable.
At minimum, the database should include: claim, source, exact quote or evidence, page/link, verification status, and notes.
The prose is what you read. The database is what you audit and can rely on to update the prose, fact check and reason back to why that paragraph is there in the first place.
This matters because polished prose does not reveal whether the claim underneath it is sound.
Perplexity citing a Reddit post as primary research.
A synthesis that drops a critical qualifier or caveat.
A statistic that exists in a different form in the original source.
The prose will not tell you. It will present all of these with equal confidence. because it summarises and pattern matches and outputs directionally correct. This is not the same as factually accurate.
For low-stakes work, a simple table is enough. For public, professional, or high-stakes work, use a spreadsheet or database with required fields. Markdown is fine for thinking. A claims database is for verification.
The infrastructure point matters here. A claims database is a database, not a note. Markdown gives you maximum flexibility and almost no enforcement.
Don’t take my word for it. There’s a good reason why all reference management systems use databases and IDs for sources. You cant trust, scale, query, or port prose the way you can a tag. Which is trivial to convert to text.
With a probabilistic model writing to a free-form note system, inconsistency is the base case; hallucination is a base case for automated read-writes. The moment you need guarantees (no missing fields, no broken links, no silent drift) you need structure that enforces them. Notes are for thinking. Databases are for systems. The claims verification layer is a system.
An excel, an SQL, or markdown-KV log claims. Either way. Make a database and derive the markdown during or after.
Practice Two: Frame-Checking Constructed Outputs
Constructed outputs need a different practice.
A framework, strategy, argument, or plan may not fail because its facts are wrong but because its frame is weak. It organises the material cleanly but does not actually explain it.
A framework that organises is not the same as a framework that explains. Organisation is the lower bar. Any taxonomy can create categories. Explanation does something harder: it helps you see a distinction you could not see before, act differently, or anticipate what would happen under different conditions.
Most AI-generated frameworks are polished organisation. They feel like explanation because the structure is clean and the vocabulary is precise. Discernment is the capacity to tell the difference.
Practice 2 is running 5 checks
Boundary test
Self-consistency test
Exclusion test
Difference test
Failure test
The last two are warrant tests. They ask whether the framework actually changes what you can see, and whether it exposes itself to being wrong.
1. Boundary test: do the categories still work in messy cases?
Every framework organises the world around a key distinction. Push on the cases that sit near the boundary. If the categories blur the moment they meet real complexity, the distinction may be doing rhetorical work rather than analytical work.
Ask: where does this framework struggle to classify a case?
2. Self-consistency test: does the framework obey its own rule?
A framework that praises nuance while using false absolutes is contradicting itself. A framework that claims to describe a conditional relationship but speaks in invariants is failing its own standard.
Ask: does this frame practise the kind of thinking it recommends?
3. Exclusion test: what did this framework leave out in order to cohere?
A framework that covers everything explains nothing. The boundary should be statable, and the reason for that boundary should be principled rather than convenient.
Ask: what has been excluded, and is that exclusion justified?
Testing the Logic Beneath the Framework
The next two checks test the hidden bridge inside the framework.
The instrument we are using is Toulmin’s argument model. Every argument (including every AI-constructed framework) has six components:
Claim
Grounds
Warrant
Backing
Qualifier
Rebuttal
Toulmin’s argument model gives us a useful term here: the warrant. The warrant is the principle that connects the evidence to the conclusion. In plain English, it is the reason the frame thinks its categories should work.
AI-generated frameworks often sound coherent because the claim and structure are polished. The weakness is usually lower down: in the hidden assumption that says, “this distinction actually explains the thing.”
Difference test: what does this framework help me treat differently?
Before the framework existed, two situations looked similar. After applying it, they should look different in a way that matters for action. If the framework cannot change what you notice, decide, prioritise, or do, it may be producing vocabulary rather than judgement.
“Apply this framework to two borderline cases that look similar. Show me what the framework makes me treat differently. If the difference is only verbal, say so.”
5. Failure test: what would show me this framework is wrong?
If the framework is sound, it should expose itself to possible failure. It should tell you what you would expect to observe if it did not hold. A frame that cannot answer this question may be designed to absorb all evidence rather than learn from it.
“What would I expect to see if this framework is wrong? Give me three observations that would weaken it.”
If you want a simple grammar for running these checks, Paul and Elder’s Elements of Reasoning give three useful questions:
Concepts: is the key term being used consistently, or does it shift meaning at the edges?
Assumptions: what premise is the framework taking for granted?
Implications and consequences: if I accept this frame, what follows — and does that still hold in cases it was not designed around?
The AI-Specific Layer
There is also an AI-specific reason this matters.
Modern chat models are not trained directly against truth. They are trained and tuned to produce outputs humans rate as helpful, coherent, acceptable, and safe. Correctness may be part of that signal, but it is not the same as the signal.
Goodhart’s Law applies: when a measure becomes a target, it can stop being a good measure. Human approval is a useful proxy, but it can reward visible signs of competence more easily than hidden soundness.
That means AI-generated outputs can carry structural pressure toward appearing well-founded. Clear structure, confident language, appropriate qualification, and expert vocabulary may indicate useful optimisation. They do not prove that the frame is sound.
The polish is not evidence of soundness. The substance still has to be tested.
This is why professional scepticism applies with extra force to AI output. In audit, scepticism means you do not accept a claim merely because the source appears credible. With AI, that discipline becomes even more important because the output is often fluent, coherent, and formatted in ways that reduce the felt need to question it.
The model will not reliably trigger your scepticism for you. Discernment has to be brought to the output deliberately.
Phronesis: Why Discernment Can’t Be Installed
The five checks are a scaffold. They are not discernment itself.
Aristotle’s concept of phronesis — practical wisdom — is useful here because it names the kind of judgement that develops through practice in particular situations. No fixed rule can tell you what matters in every case. But repeated use of a good scaffold teaches you what to notice.
That is what the five conditions are for. At first, you run them deliberately. Over time, they train perception. You begin to feel when a framework is too clean, when a category is doing rhetorical work, when a missing exclusion matters, or when a claim has no visible failure condition.
The checklist is training for judgement. The goal is not to run a ritual forever but instead to build the habit of treating finished-looking AI output as a draft hypothesis until it has earned its place.
Practical application
Here is the post-output practice in its simplest form.
If the output reports the world, build a claims database and verify the claims.
If the output constructs a way of seeing the world, run the five frame checks:
Boundary test: do the categories still work in messy cases?
Self-consistency test: does the framework obey its own claims?
Exclusion test: what has been left out, and why?
Difference test: what does this help me treat differently?
Failure test: what would show me this framework is wrong?
The complete loop is simple:
define success before execution → generate the output → identify the output type → apply the right evaluation practice → use judgement on what the test reveals.
That closes the Evaluation Vacuum gap. It does not remove the need for judgement but it does give judgement something to work on.
What Remains Open
What remains open is the integration question.
If pre-execution practice is about defining the task before the model acts, and post-execution practice is about interrogating the output after it arrives, then the next step is a complete interaction architecture: a way of working with AI that holds regardless of which model you are using.
That matters because models will keep changing. The verification layer should not. A claims database and a frame-checking discipline remain useful whether the model is weak, strong, fast, slow, cheap, expensive, open, or closed.
RM-4 named it, RM-5 adds a layer to it: the post-execution practices are model-agnostic in a way the pre-execution protocols aren’t. The claims database and the frame-checking conditions don’t change when the model changes. They’re the necessary verification layer of the architecture, not the model layer.
If this post-output layer is new to your practice, start with one check.
The next time an AI-generated framework, strategy, or argument looks finished, ask:
What did this leave out in order to look coherent?
If the answer is not immediately available, that is the signal. The output may still be useful, but it is not ready to be trusted.
Architect your second mind right, and you’ll think in ways you never could alone.