Case study / A correction in development
When “not found” says too much.
A shortened book title became a lesson in making uncertainty visible.
An authored walkthrough of the development case described on Anavi’s Discipline page. It is not a live product demonstration, a customer record, or a reliability benchmark.
The answer
A failed match became a stronger claim.
“Not owned.”
A shortened book title led to a confident answer. A failure to match the wording was treated as evidence that the reader did not own the book.
The problem: the answer concealed the uncertainty in the lookup.
The evidence
A candidate deserved a closer look.
A possible matching copy.
A likely match was available to inspect. The difference in the title did not establish absence; it also did not confirm that the two titles identified the same book.
The supported conclusion: possibly the same book. Check the candidate.
The correction
Keep the reader’s judgment in the loop.
Show the possible match. Mark the uncertainty.
The repair kept the candidate visible and let the reader inspect the copy before deciding. The uncertainty became part of the answer.
The design principle: make the path from evidence to conclusion available for examination.
What this establishes
The published case identifies a failure mode and describes a correction. It supplies no book title, customer data, accuracy percentage, or test count. One correction does not establish the reliability of the whole system.