AI can write the report. Who has to read it?
A review pack can grow faster than anyone can understand it. The revealing question is what happens when the expert disagrees.
Bring the review back to one inspectable question.AI-generated conceptual setting.
A person agrees to help check an idea. They receive a collection of specifications, diagrams, exceptions and linked tables. Each page looks like work has been done. Reading the collection is now another piece of work.
Somewhere in it is a question that person could answer immediately if it were put clearly.
That was the problem described in a set of review notes I have been working from. The engineering record had become the first thing a subject expert was asked to review. The notes describe large rule tables, diagram source and different kinds of review mixed together. A library that could help a developer build the system was also being used to ask whether the system made sense.
AI makes this mismatch especially easy to produce. It can expand a short idea into a substantial package before the person who knows the subject has corrected the first wrong relationship.
Follow the idea
How much work does it take to disagree?
An anonymised review problem described in the source notes, with an invented approval example. Better reviewer feedback and time saved have not been measured.
A library preserves detail. A review needs a question.
First, read all of this
The expert receives the whole library. Finding the question becomes a task before the review can begin.
A library preserves detail. A review needs a question.
Point to the mistake
The example separates checking facts from approving an action. A person can challenge that relationship without decoding every rule.
Return the changed case to the reviewer.
Make the answer stick
The corrected model reaches the rule, the implementation and its check. The next review shows what changed.
The person with the answer gets the most homework
Consider an invented example: a diagram says the operator approves an action. The expert knows that the operator only checks the facts. Someone else makes the decision.
Shown those two steps, the expert can point to the mistake. Asked to sign off on a long specification, they first have to find it, understand the notation and decide whether changing it will break something elsewhere. The cost of disagreeing has increased.
A polished document can make that worse. It looks settled. A small correction feels like reopening a large amount of finished work, even if generating that work took very little time.
The review notes propose putting a rendered model and an ordinary-language question in front of the expert first. The detailed material stays available. It becomes useful when there is a reason to enter it.
A correction should make the next review smaller
Making a nicer summary is only half the repair. Suppose the expert corrects the approval step, then sees the same mistake in the next diagram, the next requirement and the next build. The process has made them responsible for carrying their answer around.
The correction needs to travel. The working model separates checking facts from making the decision. The affected rule changes. A test tries to proceed with factual confirmation alone and shows that it cannot. The expert returns to a changed example instead of an invitation to reread everything.
Google’s review guidance includes asking whether tests are valid. That question reaches beyond the code: a test can faithfully preserve the very misunderstanding the expert was trying to remove.
This is also part of the ambition behind BESF: a correction should survive into later work.
The useful output is the disagreement
Some subjects require dense detail. A friendly diagram can omit the exception that matters most. The answer is to bring the necessary detail into the conversation when it can change the judgement, and keep a route back to it.
The source notes do not establish that the proposed review approach saved time or produced better feedback. They describe a problem and a repair worth trying.
The useful test is a person noticing something false, explaining why, and finding that the next version has actually changed. A room full of agreeable reviewers and a complete document library could still leave the original mistake untouched.