Skip to content
Article 11 of 11 — part of the Interpretability Engine Optimization series.
Juan Carlos López

The Method Behind Every Before-and-After You Just Saw

The five-step IEO cycle, the five kinds of gap it finds and the two checks that keep it honest. An open method agencies can run on any store, with any tools.

IEO methodecommerce catalogsagencies
The five-step IEO cycle drawn as a loop, with the five kinds of gap around it

In this article: all of Interpretability Engine Optimization (IEO) in one place. The question it starts from, the five steps it repeats, and the names for what it finds. It's written for the agencies and practitioners who will run it on someone else's store.

Nine articles, nine things that went wrong for a store. An assistant called a jacket waterproof when the page said water-resistant. An About page said who the brand was, and no machine could use it. A sofa came with free delivery, and nobody could say whether they'd carry it up three flights. A subscription said "save 15%", and nothing said when a customer could cancel.

Each one was fixed the same way. That isn't luck. It's a method, it's public, and you can run it with any tools you like, ours or not.

Start with one question: interpretable for what?

A store's information isn't interpretable in general. It's interpretable for a task.

The same candle page works for "what does it smell like?" and fails for "will it get here by Friday?". So the first move is never "fix the catalog". It's to name the decision the machine has to make, and then write down three things:

  1. What the machine has to resolve. For "a woody candle, made in the USA, here by Friday": the scent, where it's made, how long the order takes to leave and how long it takes to arrive.
  2. What counts as correct for each one, and where the truth lives: the product page, the About page, the shipping page, or the owner.
  3. What a mistake costs. Getting the color wrong is a small miss. Getting the delivery date wrong ruins a birthday.

That short list is what the rest of the work answers to. Skip it and you'll end up enriching five hundred products with fields nobody asked a question about.

Write the contract before you fix anything

Before anyone touches a field, put the rules in writing. For each decision, the Methodology calls this the interpretability contract, and in plain language it's five lines:

  • What the right answer looks like. Not the value itself, but what would count as correct, and against what: the store's page, the platform's category list, the owner's word.
  • What evidence is enough. A sentence on the product page? A line on the About page? Only the owner's confirmation?
  • How much doubt you accept. For a color, some. For an allergen, none.
  • When the machine has to say "I don't know". Which fields stay empty until the business speaks.
  • Which mistakes are not allowed. The ones that cost a return, a complaint or a customer.

It's a short exercise per decision, and it changes everything after. With the contract written, anyone can check your work without trusting you. Without it, "fixed" is an opinion.

The five steps

Measure → Find → Remediate → Validate → Re-measure

1. Measure. Before you touch anything, record where things stand. Use something you can repeat exactly: an audit tool, or a fixed list of questions asked the same way every time. Without a "before" there's no "after", only an opinion.

2. Find. Go through your list item by item and name what's wrong with each one. There are only five kinds of gap, and each has a different fix. This is the step that gets skipped, and when it is, "AI optimization" turns into rewriting copy that was fine.

3. Remediate. Fix what the store's own evidence supports. Structure what's sitting in paragraphs. Where the store says nothing, leave the field empty and write down the question for the owner. Never fill a gap with what's probably true.

4. Validate. Check your own work before a machine does. Every value you added has to trace back to something the business published or confirmed. The page a person reads and the data a machine reads have to say the same thing. And nothing can have slipped in that the store never said.

5. Re-measure. Run the same measurement again: same questions, same conditions. The difference between the two is what you can report. One caution: a question asked once before and once after gives you two answers, not a result. Assistants can vary from one run to the next on their own. Ask the same set of questions several times, before and after, and see how much the answers move by themselves before you credit any change to your fix. And if you changed the tool or the questions in between, the two results can't be compared. Start a new baseline.

Then do it again. This is a loop, not a project. Prices change, policies change, and the machines reading them change too. A store that was understood in March can be misread in June without anyone editing a word.

The five kinds of gap

Almost everything you'll find is one of these. Four are failures of meaning. The fifth isn't a failure of the fact at all, and the Methodology calls it the most common condition in source data.

The gap In plain words The fix
Ambiguity It says something, but it could mean two things Resolve it against a reference, such as the platform's own category list
Conflict Two places say two different things The business decides, then says it once. Never pick one silently
Absence It isn't written anywhere Leave it empty, and say what it would take to fill it
Unsupported inference Someone, a person or a machine, filled the gap with a guess Take it out, then resolve it from evidence
Representation deficiency It's there, in words a person reads fine, but not in a form the machine can use for this task Structure it for the task. No new facts needed

The fourth is the expensive one, because it looks like success: the field is full, the validator passes, and the value is wrong. The fifth is the common one. Much of what a store needs to tell a machine, it has already told its customers. A paragraph isn't a deficiency by itself; plenty of prose gets interpreted correctly. It becomes one when the task needs a value the paragraph doesn't hand over. That's why the question comes first: deficient for what?

The nine cases, sorted

Here is the series again, this time by what each article was teaching.

Article About What went wrong Its name in the method
2 Product The assistant said "waterproof". The page said "water-resistant" Unsupported inference
3 Brand The About page says who you are, and no machine can use it The mirror principle
4 Transaction The product page is perfect, and the sale fails at shipping and returns Conflict
5 Product The best selling point stayed in a paragraph Representation deficiency
6 Brand "Organic", "made in Italy", "doctor-founded": which claims a machine can carry, and with what behind them Evidence and declared states
7 Transaction Free delivery, and nobody could say whether they'd carry it upstairs The decision context
8 Product Shoppers search the store for things it sells, and find nothing Ambiguity
9 Brand Three names online, and a machine sees three companies Identity
10 Transaction "Save 15%" was on the page, and the cancellation policy wasn't Absence

Five of those names are the gaps from the table above. The other four are what the method is built on:

  • The decision context. The question you started with: interpretable for what?
  • The mirror principle. What a person reads and what a machine reads have to be the same facts, because they come from the same source. If your About page says it and your data doesn't, the mirror is broken.
  • Evidence and declared states. Every value carries a label: stated by the source, derived from it, inferred (with how sure, and why), unresolved, or in conflict. Without the labels, a checked fact and a guess look identical.
  • Identity. Before a machine can understand anything else about a product or a brand, it has to know which one it's looking at.

Two checks that keep it honest

The boundary test. Ask of every change: did the machine understand the store better, or did we only improve how the information is formatted, distributed or surfaced? The Methodology gives a practical version: "if the same information were delivered through a different channel tomorrow, would the improvement still remain?" Understanding travels with the information. Positioning doesn't.

Three labels for every number. A measurement is what you observed before the fix. A projection is what you expect after it. An observed result is what you measured once the fix was live. Clients will hear all three as "results" unless you keep them apart. Keep them apart.

What it doesn't do

IEO doesn't rank you, and it doesn't make a machine prefer you. It doesn't replace SEO, AEO or GEO. Those get you found, answered and cited. IEO works underneath and gives all three something accurate to work with.

It doesn't decide anything either. It prepares what the store's information means. The assistant, the ad system or the checkout does the deciding.

And if a product doesn't fit what the shopper asked for, IEO doesn't make it fit. It makes that clear. Sometimes that costs you a recommendation you were never going to keep.

For agencies

You can run this for any client, on any channel, without rewriting anyone's copy.

Pick the decisions each channel makes. Measure a sample of products. Report what you found by kind of gap. Fix what the store's own evidence supports. Send the rest back as questions only the client can answer.

That last list is worth more than it looks. You don't supply the facts about the business. The client does. Your job is to make those facts explicit, checkable and measurable, and to know which ones are still missing.

Many of you already do parts of this without a name for it. Now it has one, and a public method anyone can read, practice, adapt and teach.

Practical example

Back to the candle store from the first article. One question, the whole cycle.

The decision: "A woody candle, made in the USA, here by Friday. Is it safe to burn around cats?"

The contract, in short. Correct means what the store published, nothing more. Evidence means the store's own pages, or the owner's confirmation. Some doubt is fine on the scent; none on delivery or safety. Anything the store never said stays empty. And a wrong answer on delivery or on safety is not allowed.

1. Measure. Ask an assistant exactly that, several times, and write down what comes back each time.

2. Find.

What has to be resolved What the store says, and where The gap
Scent Description: "A woody blend that opens with cedar…" Representation deficiency
Where it's made About page: "hand-poured in small batches in Portland, Oregon" Representation deficiency, on another page: the mirror is broken, nothing connects that page to the candle
Delivery time Shipping page: "orders leave in two business days and take two to three more to arrive" Representation deficiency
Safe around cats Nothing, anywhere Absence

Before you read on, decide what you'd do with the fourth row.

3. Remediate. Scent family: Woody. Made in: USA (Portland, Oregon). Processing: 2 business days. Transit after dispatch: 2–3 business days. Safe around cats: left empty, with a question for the owner.

Candles are often sold as pet-safe, and that's exactly the guess to refuse. An empty field with a question attached is an honest empty. A filled one would be an unsupported inference with your agency's name on it.

Whether the candle makes Friday still depends on the day she orders and where she lives. The fields give the assistant what it needs to work that out.

4. Validate. Four values trace to three pages. One is empty on purpose. The page and the data say the same thing, and nothing was added.

5. Re-measure. Ask the same assistant the same question, the same way, the same number of times. Compare the two sets, not two answers. What changed beyond the assistant's own back-and-forth is your observed result, and it's the only thing you report as a result.


Check what's explicit, what's missing and what contradicts itself on one of your products → Run the free audit

Read the full method → The IEO Methodology (doi.org/10.5281/zenodo.22416784) · The founding paper (doi.org/10.5281/zenodo.22104280) · nsolvia.com/ieo

Source: López Castaño, J. C. (2026). Interpretability Engine Optimization: Methodology. Version 1.0, sections 4 to 9, 12 and 16.

← "Save 15%" Is on the Page. The Cancellation Policy Isn't. · ⌂ IEO · Back to the start: The Platforms Now Describe Your Products For You →

Series: Interpretability Engine Optimization · Knowledge Domain: Interpretability (IEO)

Interpretability Engine Optimization (IEO)
The UNDERSTAND Layer
nsolvia.com/ieo