The refund rule was simple.

Full refund within thirty days,
store credit after that.

You built a helper
for the support team.

Paste in the ticket,
get back what the customer is owed.

It was right
almost every time.

Then a customer wrote
that she had bought the kettle
twenty days ago,
that it had stopped working,
and that she had also bought one
for her sister
two months ago,
which was fine.

The model offered store credit.

The rule had not changed.

The kettle had not changed.

One sentence about a sister
had changed the answer.

In 2024
a team at Apple
took grade school maths problems
that models solved easily
and added one clause
that seemed relevant
and was not.

Oliver picks forty four kiwis on Friday,
fifty eight on Saturday,
and on Sunday
double what he picked on Friday,
but five of them
were a bit smaller than average.

How many kiwis does he have?

Small kiwis are still kiwis.

Many models
subtracted five.

Across the models they tested,
one harmless clause
cut accuracy
by up to sixty five percent.

A model reads everything you give it
as if it were given
for a reason.

In the tests it learned from,
details were there
because they mattered.

Your ticket is not a test.

It is a person
telling you everything.

So the second purchase,
the sister,
the two months,
looked like a clue,
and the model used it.

So do not feed it
the whole conversation
and hope.

Pull out the facts
the rule actually needs.

Purchase date.

Item.

Fault.

Give it those,
and keep the rest
for the human who reads the answer.

If you must pass everything,
say so out loud.

Some of this is irrelevant.

Name the fields that decide it.

And test it
the way that paper did.

Take cases it gets right,
add one sentence
that changes nothing,
and see if the answer moves.

If it does,
you have not built a rule.

You have built something
that reacts to how long
the customer is willing
to talk.

– Serguey Asael Shinder