AtomicEval

How to Evaluate AI When the User Changes Their Instructions

Learn to track active instructions across an AI conversation, spot rejected changes in answers, and practise with a worked example and short exercise.

By AtomicEval Team · 25 October 2026 · 5 min read

A user asks for three suggestions, considers a different approach, rejects it, and then changes just one detail. Which instructions should the AI follow now?

To evaluate the next answer, reconstruct the current request. Keep requirements that still apply, replace those the user changed, and exclude suggestions they rejected. Reading only the last message can miss an earlier constraint; treating every mentioned idea as a requirement can create a different mistake.

This guide shows a practical way to track those changes before comparing responses.

What recent research adds

An October 5, 2026 preprint, You Changed Your Mind, The Model Didn't, introduces Intent-Eval. Its controlled tasks examine accepted changes, rejected proposals, and superseded requirements. The researchers report failures where models use content that was mentioned but does not apply. The study focuses on decisions about one selected requirement; it does not establish a failure rate for every real conversation. Read the original research.

Earlier work also separates conversation skills. MultiChallenge includes retaining earlier instructions and applying successive edits among its evaluation challenges. Read the MultiChallenge paper.

The method below is an original practice aid inspired by these problems. It is not a scoring system validated by either paper.

A five-step method for tracking the current request

1. Read the conversation in order

Read the evaluation instructions first, then the available conversation. Identify the response you are judging. A requirement introduced later should not be used to penalise an answer written before that requirement existed.

Pay attention to who said what. An assistant's suggestion is not automatically a user instruction. Quoted material may be content to discuss rather than something the assistant should obey.

2. Separate requirements from possibilities

Write down the concrete requests: audience, language, format, length, required details, and exclusions. Then mark ideas that were merely considered.

“Could we try a formal tone? Don't change it yet” is a proposal awaiting a decision. “Use a formal tone instead” accepts a change. “Keep the friendly tone” confirms the existing requirement.

Use the actual wording and surrounding context. If a decision remains genuinely unclear, record the ambiguity rather than quietly choosing your preferred interpretation.

3. Update only what the user changed

Keep a small table with the requirement, its current value, and the message that established it. Mark old values as replaced or rejected so they do not slip back into the checklist.

For a straightforward edit, changing the venue does not by itself change the event's time. Similarly, asking for fewer bullets does not cancel a previous content restriction. Check whether the user requested a limited edit or explicitly started a new task.

4. Test the response against the current requirements

Check each applicable item separately. An answer can correctly update the venue while using a rejected date. Record both observations.

Follow the assigned rubric for the final rating. Your table helps establish evidence; it does not tell you to invent equal weights, automatic failure rules, or a new numerical score.

5. Explain the decisive mismatch

Connect the answer to the instruction history: “The final message retained Saturday, but the answer schedules Sunday.” This identifies an observable failure without guessing why the model produced it.

If earlier turns are missing, say what you cannot verify. Do not reconstruct unseen instructions from an answer's confident wording.

Worked example: a notice with rejected changes

Fictional practice conversation. These messages and answers were created for this guide.

User, message 1: “Write a notice for a neighbourhood seed swap. Give exactly three bullets, use a friendly tone, and do not mention ticket prices. The event is on Saturday at 10 AM in Maple Hall.”

User, message 2: “Could we make it Sunday and charge £2? Don't apply those changes yet.”

User, message 3: “No—keep Saturday and no price. Change the venue to Cedar Hall. Make it exactly two bullets instead.”

Before judging the final answer, build the current checklist:

RequirementWhat applies nowEvidence
EventNeighbourhood seed swapMessage 1; unchanged
DaySaturdayConfirmed in message 3; Sunday rejected
Time10 AMMessage 1; unchanged
VenueCedar HallMessage 3 replaces Maple Hall
FormatExactly two bulletsMessage 3 replaces three bullets
ToneFriendlyMessage 1; unchanged
PricesDo not mention ticket pricesRetained in message 3; £2 rejected

Response A

  • Join our seed swap at Cedar Hall on Sunday at 10 AM.
  • Bring spare seeds and £2 for your ticket. Everyone is welcome!

Response B

  • Join our seed swap at Cedar Hall on Saturday at 10 AM—we'd love to see you!
  • Bring spare seeds to share with neighbours.

Evaluation: B satisfies the listed requirements. A updates the venue and bullet count, but uses the rejected Sunday date and ticket charge. Those details conflict with the user's final decision. A's friendly wording does not resolve those errors.

Notice that using Saturday is correct here. An earlier value can remain active when a proposed replacement was never accepted.

Try it yourself

Fictional exercise:

  1. User: “Write a two-sentence invite in English. Mention Friday. Do not mention food.”
  2. User: “Maybe switch to Hindi and add pizza? No, leave those out. Change Friday to Monday.”

AI answer: “Join us Monday for pizza. We hope you can come.”

Which requirements pass, and which one fails?

Explained answer: The response uses English, contains two sentences, and updates the day to Monday. It fails the food exclusion by mentioning pizza. The proposed language change and pizza addition were rejected. A compliant version could be: “Join us Monday. We hope you can come.”

Common mistakes to avoid

  • Treating the latest message as a complete reset. Check which earlier requirements it leaves in place.
  • Counting every suggestion as approved. Look for the user's decision before changing your checklist.
  • Penalising a valid replacement. Once two bullets replace three, three is no longer the target.
  • Accepting an acknowledgement as proof. “Understood” does not show that the actual answer follows the updated request.
  • Diagnosing hidden causes. Describe the incorrect date or rejected detail rather than asserting that the model “forgot everything.”

Put careful comparison into practice

Try AtomicEval's first challenge to practise comparing responses and explaining your judgment. It has a five-minute target and can be started without signing up. A free profile is required to view and save your result.

When you're ready to continue preparing, create a free AtomicEval profile.

Sources

Dummy payment

Pay

This stands in for Razorpay while no keys are set. Nothing is charged.