The refund assistant
returned structured output.
A small schema,
two fields.
decision,
approve or refuse.
reasoning,
a few sentences
for the person who checks it.
The team liked the reasoning.
It was careful.
It cited the policy.
It weighed the dates.
On easy cases
the decisions were right.
On the hard ones,
an order past the return window
with a fault reported inside it,
they were close to a coin toss.
And every wrong decision
came with a careful paragraph
explaining why it was right.
Look at the order of the fields.
A language model writes
one token at a time,
left to right,
and every token it writes
becomes part of what it reads next.
Structured output modes
usually write the keys
in the order the schema lists them.
Some providers say so
in their documentation.
So the first thing this model wrote
was the word approve
or the word refuse.
Then it wrote the reasoning,
with the decision already sitting there,
fixed,
part of its input.
The reasoning was not
how it reached the answer.
It was a defence
of an answer
it had already given.
This is why asking a model
to work step by step
helps on hard problems.
The steps come first,
and the answer is written
after them,
on top of them.
A schema that puts the answer first
asks for the opposite.
The fix is one line.
Put reasoning above decision.
Same fields,
same words,
different order.
Then measure it,
because a fix you believe
is not a fix you have checked.
Take the hard cases
people already agree on.
Run them with the decision first,
then with the reasoning first,
and compare.
If the scores move,
the order was deciding.
Two cautions.
Reasoning written first
is still not proof
of how the answer was reached.
It is a better place to start,
not a confession.
And models that think
in a separate step
before they answer
are less sensitive to this,
not immune.
A schema looks like a form.
To the model
it is also a script,
and it reads the lines
in the order you wrote them.
– Serguey Asael Shinder
