Show AI the day that worked and the day that did not── A matched pair of inputs, plus one line naming the range that should hold, narrows the fix far better than any adjective

01Lining up two dates narrowed the fix to one place

A short exchange survives in the record from March 2026. The operator was using a tool for registering appointments and found that dates were not being read correctly. That was the whole of the first report.

It went nowhere. The operator then changed the wording. One day's entry went through. The day before and the day after did not. And any date ought to be handled, the operator added, stating the expectation out loud.

The second version carried three things the first did not: an input that worked, an input that failed, and a rule that should hold. With all three present, an AI no longer has to guess at "date parsing is broken". It can suspect something much narrower: a piece of code written to fit one particular way of writing a date.

That trio is the thing to take away. When you report a fault to an AI, do not add an adjective. Add an example. And look first for the example that worked, not the one that failed.

02A matched pair of examples points at the edge of a rule

Hand over only the failing case and the AI learns one fact: it broke here. Put a working case beside it and one fact becomes a line. The difference between the two inputs is where the broken rule lives.

Software testing has read failures this way for decades. Inputs are divided into groups that ought to be treated alike, and one case is tried from each group; the division is called equivalence partitioning. The edges between groups are where behaviour switches over, so faults gather there, and boundary value analysis aims deliberately at those edges.

A user who writes "this day goes through, that day does not" is not consciously applying a test method. The effect is the same. They have handed over one boundary.

03A one-word symptom gets a one-word repair

A language model works inside the description it is given. Write that a date cannot be read and it inspects date reading. It patches things so that input goes through, and reports the matter closed. The neighbouring days were never mentioned, so they are never tried.

The awkward part is that the failure is invisible at first. The input you named does start working. It looks fixed. Then a different input, failing for the same underlying reason, stops working days later.

There are published guidelines on writing fault reports. Mozilla's bug writing guide treats steps to reproduce as the most important part of any report, and asks for expected results and actual results to be written out separately. The demand was framed for human developers, but it does not soften for an AI. If anything it hardens: an AI is not looking at your screen, so anything left unwritten does not exist.

04Three parts, and a fourth that says when it is done

Showing the gap with examples means handing over four things at once. No prose is needed. Four lines will do.

The pattern does not suit everything. Faults that appear only sometimes, features not yet built, and matters of taste all sit outside it. If a fault is intermittent, the first job is finding the conditions that trigger it. If it is taste, a model to copy travels faster than an example.

Where it earns its keep is the symptom of partial success: some inputs pass, others do not. Dates, languages, categories, digit counts, formats. Whenever an input has kinds and only some kinds pass, the code has almost always been written around one kind.

05In material review, an approved piece beside a rejected one turns the standard into words

The same trouble arises when an AI does a first pass over promotional material at a pharmaceutical company. Write only that a judgement is wrong and the AI revises that one judgement. The standard behind it has not moved, so the next similar piece comes back judged the same way.

Put two pieces side by side instead. One that contains the phrasing in question and cleared review, and one that was stopped. Then ask which condition separates them. The condition the AI names will not always match what the reviewer had in mind. When it does not, the thing out of step is often not the AI's judgement but a condition the reviewer had never put into words.

This links back to an earlier piece in the series. Variation between reviewers shows up less in the judgements themselves than in whether the grounds for them have been articulated. Lining up a working case against a failing one is a way of getting those grounds out into the open. What comes out feeds straight into the review of the next piece.

One caution. Whether internal material may be handed to an AI at all is a matter of company rules. Where it may not, build examples that carry only the pattern of the phrasing, and run the same exercise on those.

06Inputs that pass only sometimes come from a hard-coded format

So one date passes and another does not. The cause is usually plain. The part of the code that interprets a string as a date assumes exactly one way of writing it.

Dates are written differently from country to country and setting to setting. RFC 3339, which defines how timestamps travel across the internet, states that a string such as "10/11/1996" is completely unsuitable for global interchange because different countries read it differently. Requiring year, month and day in that order, with four-digit years, exists to remove the clash. Where that much variation exists, code built around a single form will miss somewhere.

There is also a reason the failure is partial rather than total. Studies run at the National Institute of Standards and Technology between 1999 and 2004 found that most software failures are caused by one or two parameters, with progressively fewer caused by three or more. If one or two conditions are enough, only the inputs meeting those conditions drop out. The system does not stop; a slice of it does.

The same work yields guidance on testing. Covering every pair of conditions finds very nearly as many faults as testing every combination, at a fraction of the cost. A user who supplies one working and one failing case is opening the first door of that coverage by hand.

07Before reporting a fault, go and find one case that works

Four steps for tomorrow.

1. Find a working case first. Before writing the complaint, locate one input that behaved as expected. If none exists, this is not partial failure; nothing is working.
2. Pick a near neighbour that fails. Choose an input differing in one place only. The smaller the gap, the narrower the region the AI has to suspect.
3. State the range in one line. "Any date." "Any language." Skip this and you get a repair sized to your examples.
4. Hand over the test for done in advance. The named input, its neighbours, and the extreme values. Fixed means all three pass.

This fits how the models themselves ask to be prompted. Anthropic's prompting guidance recommends three to five examples that mirror the real use case, cover edge cases, and differ enough from one another. The examples in a fault report work the same way. Similar examples add no boundaries at all.

One last thing: the pattern is not only for the AI's benefit. Hunting for a working case is often the first moment your own expectation becomes a sentence. Without that sentence, saying "something is off" over and over buys you nothing but patches, one symptom at a time.