Grounding a disagreement in what you shipped
A disagreement is only worth hearing when it names the system, the users, and what actually happened — and stating the narrowness of your evidence is what makes the rest of it credible.
You have said the thing. You cited the guideline accurately, you disagreed with it, and now somebody in the room has asked the only question that matters: based on what?
There are two ways to lose here. The first is to have nothing, and retreat into “in my experience.” The second is worse and far more common: to have something real and describe it larger than it is, in a room where several people have shipped agents and will spot the inflation in one follow-up question. Once they do, the accurate citation you opened with stops counting for anything.
This lesson is about the third way. State exactly what you shipped, at exactly its size, and let the narrowness be the reason to believe you.
Say what the two systems are, at their real size
Write these down once, precisely, and never describe them more expansively than this again:
- The HouseWarm review gate. Document extraction with a human in the loop: per-field confidence, the source image crop, the raw OCR text, and approve-or-correct before any downstream step fires. It is an app-level gate. Request and response. There is no resume.
- The points-and-miles flight recommendation chatbot. Advisory. It recommends and it deliberately does not execute. Request, wait, render — not streaming.
Now the harder half, which is the list of things you did not ship. No multi-step autonomous workflow. No streaming. No tool-calling loop. No agent that can fail halfway through with side effects already committed. If your disagreement is about what a UI owes the user after a run dies at step two, neither of these systems saw that happen, and saying so out loud is not a weakness in your argument. It is the thing that makes the rest of your argument credible.
The inflation failure
The tempting sentence is “we built an agentic review flow with confidence-gated autonomy.” It is not false, exactly, and it is how the review gate would be described in a deck. In a room of people who have shipped agents, it invites one question — what did it do when a step failed after the first one succeeded? — and the honest answer is that it never had a second step. You will have spent your credibility to buy an adjective.
What a groundable claim contains
This is this course’s own four-part test, not a published framework. A claim from shipped work is worth hearing when it names all four:
- The system. What it did, at what level of autonomy, in what shape. “A per-field human approval gate over extracted values”, not “an AI product.”
- The users. Who they were and what they were trying to finish. Not a persona. The actual people who used the thing.
- What happened. An observation, not an impression. Something that would have looked different if the opposite were true.
- The limit. One sentence naming what your evidence cannot reach. This is the part almost nobody says, and it is the part that converts a war story into evidence.
Three of those four are usually easy. The third is where most claims quietly fail, because “users didn’t like it” feels like an observation and is not one. It has no shape. Nothing about it could have come out the other way.
A published example of doing this correctly
The best worked example of naming your own narrowness is not from a vendor. It is from Nielsen Norman Group’s study of China’s Qwen agent, by Feifei Liu and Maria Rosala, published 8 May 2026. It is the most directly agent-relevant empirical piece on the site. It is six participants, and the article says six.
Name the interest first, as you would with any other publisher in this course: NN/g sells training, consulting and paid reports, advertised on the same pages as the research it gives away. That is a real interest, and it makes what the piece does next more impressive rather than less. A consultancy with something to sell printed the number six.
Then notice the scoping. The study reports that users “still retained control; they needed to authenticate with AliPay before allowing payments”. Read that as a limit statement rather than a finding. It tells you the six sessions never observed the case where an agent commits a consequential action on its own — so nothing in the piece licenses a claim about that case, and the authors do not make one.
The target sentence, and the part of it you still owe
The register this course is aiming at is one sentence with two halves. The position document states it as the calibration example:
The HAX guidelines say to scope services when in doubt — that is G10, filed under “when wrong”. In practice, with brokers, over-hedging destroyed trust faster than a confident wrong answer did.
The first half is finished work. G10 is real, the wording is exact, and the phase is right — you did that in the guidelines lesson.
The second half is a template, not a result. It is written in the shape a filled row takes; it is not something this course has established, and you should not say it in a room until you can answer what “destroyed trust” meant, which users, and how you know. That is precisely the gap this lesson exists to close, and it is why the position document keeps the evidence cell blank on purpose. A sentence you borrowed the cadence of is not a sentence you can defend.
So write the version you can defend. It will be less quotable and it will survive: that is G10, under “when wrong”. In our extraction review gate, every field carried its own confidence and the reviewers developed a habit I did not expect — and I should say up front that this is one shallow extraction agent with a human gate, not an autonomous run, so how far it carries to your case is a fair question.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Someone asks: “your review gate had no autonomous run, so why should your view on agent failure carry any weight?” That objection is fair. What is the answer?
Check your answer
Concede the range and defend the mechanism. Something like: it should carry less weight than someone who has run one, and I would say so. What it does give me is the reviewer side of the same problem: what people did when a machine handed them a value with a confidence number attached, and how quickly that number stopped being read. If your failure case is about whether the human downstream is actually reviewing or just clicking, I have seen that part.
The move is to narrow the claim to the part your evidence actually covers, rather than defending the whole territory. A position that retreats to solid ground on the first fair objection reads as confident. One that defends everything reads as unfamiliar with its own limits.
Hands on
Write one evidence cell that names all four parts
Done when: One framework row in POSITIONS.md has a filled evidence cell containing the system, the users, one thing that happened that could have come out the other way, and a limit sentence — and a second person reading the cell could tell you what it does not cover.
- Pick the row whose guideline you already filled a citation for. If that is the HAX row and G10, good — the advisory chatbot is the system that speaks to it.
- Write the evidence cell in four clauses, in order: the system, the users, what happened, the limit. Keep it under sixty words. If a clause will not come, leave the cell empty rather than filling it with the clause you wish you had.
- Read the third clause back and ask what the opposite observation would have looked like. If you cannot describe it, you have written an impression rather than an observation. Rewrite it or cut it.
- Add the limit sentence explicitly, in your own words, drawing on the list above: no multi-step autonomous run, no streaming, no tool-calling loop, no partial failure. Name the ones that actually apply to the row you are filling.
- Bring the cell into the chat. I will read it as a hostile room would: I will ask what “users” means, what the counterfactual observation was, and whether any word in it is doing work your systems did not earn.
What this does not cover
This lesson gets a defensible claim onto the page. It does not test whether the claim holds when someone keeps asking. That is the next lesson, on surviving the third why, which takes a position that reads well in a document and pushes it three levels down to find out whether anything is underneath. After that, the change-your-mind lesson asks the question that separates a position from an opinion: what evidence would move you off it. The over-hedging lesson in the previous module is where the substantive argument about confidence and hedging is actually made; this lesson only supplies the evidence discipline it needs.
Read this next — primary source
Designing AI Agents: 4 Lessons from China’s Qwen AgentFeifei Liu & Maria Rosala, Nielsen Norman Group — 8 May 2026, n = 6. Fetched 2026-09-05. NN/g sells training, consulting and paid reports, advertised on the same pages as the research it gives away.
Read this one for its shape rather than its conclusions. It is the most directly agent-relevant empirical piece on NN/g’s site, it is six participants, and it says so. Watch what the authors do with that: they state the sample, they say who the participants were, and they scope their claims to what those six sessions could actually show — including the line that the users still had to authenticate with AliPay before any payment went through, which quietly tells you the study never observed a committed autonomous action. That is the exact discipline this lesson asks you to apply to your own two systems, published by people who sell expertise and still print the number six.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.