Put Your Brand in the Answer | GEO Product Notes 13: The Hardest Part May Not Be the Model or the Code

The hardest part of a GEO product may not be the model or the code

When I started building a GEO product, my biggest concern was that the model would not be capable enough.

Could it understand brand materials? Could it identify a brand, competitors, and citations in an answer? Could it write a structurally sound article? Could the system remain stable across dozens of questions, several AI platforms, and different collection environments?

These questions are difficult. Models fluctuate, external platforms change, browser pages are redesigned, and code keeps meeting new edge cases.

But as I worked on the product, one thing became clearer: the hardest part is usually not getting the model to produce a result. It is deciding what that result means, what the team may do with it, and how to return to the evidence that existed when something goes wrong.

Models and code answer whether something can be built.

A product has to answer a different set of questions: What counts as a brand being seen? What counts as getting it right? After an action is completed, what supports a claim that it worked? Which information may be public, and which must remain internal? When the system does not know, should it keep guessing or honestly leave an “unknown” behind?

None of these questions disappears just because we switch to a stronger model.

01 Producing a result is not hard; making it accountable is

A demo version of a GEO product is easy to find exciting.

Enter brand materials, generate a set of questions, call an AI for answers, detect whether the brand appeared, then generate articles and recommendations from the gaps. Once the pages are connected, the product already looks like a complete loop.

The questions arrive when it starts making real judgments.

Does any appearance of the brand name count as a mention? If the user already put the brand name in the question and the model only repeats it, should that share a metric with a brand being recommended naturally in a category question? If an answer says “suitable for some situations,” a sentiment rule might call the limitation negative, even though it may be an accurate description of the product boundary.

Code can return a boolean quickly, and a model can provide an explanation that sounds complete.

The real difficulty is whether the product is willing to define the scope of that judgment and let later readers see how it was reached.

I now separate “the system produced an answer” from “the system formed a usable conclusion.” The first can happen automatically. The second needs the question, original answer, citations, collection context, judgment rules, and any necessary human review.

The interface becomes more complex and the workflow less smooth than in a demo. Without this context, intelligence is only hiding the judgment process.

02 Every simple number rests on product definitions

The easiest number to understand on a monitoring page is mention rate.

How many questions were asked, how many times did the brand appear, and divide one by the other. It seems straightforward.

Once I started building it, I found that both numerator and denominator needed definitions.

Should failed collections enter the denominator? When a login expires, a page asks for verification, or the network breaks, the system has not received a valid answer. Counting that as “not mentioned” turns a collection failure into a brand result.

Should a brand name already present in the question count as an active mention by the model? Can fact checks, reputation questions, and natural category questions share one statistic? If the same question is collected several times, should each run count, or should the system first form a question-level conclusion? After a reviewer changes a judgment, should historical metrics use the original result or the current effective result?

These are not database-field questions. They are questions about how the product intends to explain the world.

I once thought a note beside the metric would be enough. I later understood that the definition has to enter the entire data flow: constrain the scope when a task is created, preserve context during collection, use one denominator in statistics, freeze the samples in the report, and compare under the same conditions during a later retest.

If different pages each interpret “mention rate” differently, even a beautiful chart is only displaying several numbers that do not recognize one another.

03 Evidence is more than a screenshot beside the result

In content products, it is easy to reduce evidence to a source link.

If there is a link, the article seems reliable. If there is a screenshot of an answer, the monitoring event seems proven.

Evidence in a GEO context has to be more complete.

A monitoring observation should retain at least the original question, complete answer, citations shown on the page, platform, account scope, session mode, model, web-access state, language, and collection time. Without this context, the same sentence collected in another environment may no longer be the same event.

A brand fact cannot be stored as only a sentence called “the correct answer.” It needs a source, an owner, and a time boundary. A product file being in the knowledge base only means the system can retrieve it. Before it becomes public content, the team must confirm that the fact is approved for publication and which version was actually used during generation.

I have become increasingly concerned with snapshots.

A monitoring report should not quietly change when the database gets newer results. A published article should not lose the reason it was written that way merely because brand materials were updated. History is not just storage overhead; it lets a team answer: “What did we see at that point in time, and what did we decide from it?”

Once that chain breaks, a retrospective becomes an argument from memory.

04 Boundaries define a product better than a capability list

Product descriptions usually say what a product can do. They rarely say what it must not do.

But the credibility of a GEO product often depends on whether it protects the places where it does not act automatically.

Private knowledge cannot automatically become a public fact. A monitoring anomaly cannot automatically become a content task. A successful publication cannot automatically become improved GEO performance. A user completing an external publishing step does not mean the system has verified the public link. A model’s high-confidence judgment cannot replace the original answer or the history of human corrections.

These boundaries appear to slow the workflow.

Remove them and the product becomes wonderfully smooth: upload materials, click generate, publish automatically, declare success, then show a chart that keeps rising. But that path compresses different states into one state and packages external uncertainty as the system’s own certainty.

I would rather put these boundaries into the product than leave them in a usage guide.

Where human confirmation is needed, let the state stop. Where an external result is uncertain, keep it pending verification. Where a public fact is missing, return to the source and ownership of the material. When a stated verification criterion is not met, do not announce improvement merely because the task itself is complete.

Reliability is not a product that always has an answer. It is a product that knows which answers it cannot give yet.

05 A workflow is not a few pages connected by arrows

At first, I understood a workflow as a feature path: questions, then content, then publishing, then monitoring.

Later I realized that page order is only the outermost layer.

A real workflow carries context forward. Why was this article created? Which user question and GEO opportunity led to it? Which confirmed facts did the writing use? Where was it published? Was a public link obtained? When should the original platform be revisited for a comparable retest?

If context is lost at every step, the team is only moving tasks between tools.

A workflow must also make room for failure.

Collection can stop because of a login or verification step. A publish request can time out even though the external platform received it. A report can have only a partial sample. The system cannot turn every failure into “retry,” because blindly repeating an external side effect can create duplicate content. Nor can it quietly erase partial success, because the report would look complete while its evidence was not.

State machines, idempotency, recovery paths, and human handling are therefore not internal engineering details. They decide whether users see a process they can continue or a set of buttons that forces them to start over after failure.

06 Human review is not an automation failure

The more a product emphasizes AI, the easier it is to see human steps as a regression.

I have had that instinct too: if a judgment still needs a person, is the model not good enough? Should we keep refining the prompt until the system can give the final answer directly?

But mentions, sentiment, factual accuracy, and action priority carry different responsibilities.

A model is well suited to finding candidate issues in many answers, flagging possibly negative wording, organizing citations, and surfacing a possible conflict in a brand fact. It can greatly reduce the material a person has to read.

Whether a fact may be public, whether a limitation is an accurate boundary, and whether an opportunity deserves business resources still require someone to own the judgment.

I therefore stopped trying to remove people from the workflow entirely. I focus instead on making their judgment cheaper, clearer, and usable by later parts of the system.

Human corrections must not cover history either. The original observation stays where it was; the new conclusion is appended as a record. This is not distrust of reviewers. It recognizes that human judgment can change and also needs to be explained.

07 The hardest thing to change may be the team’s habits

After a feature is built, the product does not automatically become a way of working.

The team may still begin with a popular keyword instead of confirming a user question. Someone may say “there is a problem here” in a group chat without adding the standard fact or its source. Publication may still be treated as project completion, with no return to the original question for a retest. A total score may cause people to skip the samples and evidence below it.

Simply telling people to “follow the new process” rarely lasts.

Every additional field, review step, or state should answer which repeated judgment it removes. Information that can be derived from the project or previous step should be carried forward automatically. When material is missing, the user should return to where that material belongs. When a report identifies a problem, it should show the answer and source directly instead of making the user search several pages again.

The product should not hand an important responsibility to the model just to save a step. It should also not push every evidence-organizing task onto the user in the name of rigor.

There is no permanent answer to this balance. It has to be adjusted through real use: what people cannot understand, what they skip, what they enter twice, and where the recovery path disappears after failure.

Models can upgrade overnight. Work habits rarely do.

08 Models still matter, but they should not own the final definition

This is not an argument that models and code are unimportant.

Without stable collection, parsing, generation, and task systems, product judgments remain documents. As models improve, content understanding, anomaly detection, and recommendation generation will improve too.

But I no longer treat a stronger model as the universal answer to a product problem.

If a metric has no clear definition, a stronger model will only explain an ambiguous number more fluently. If public boundaries are missing, it will turn internal material into definite claims more naturally. If evidence is not frozen, it can write a more convincing retrospective that still cannot prove what happened at the time.

I prefer to keep the model in the role it handles well: read large amounts of material, find candidate signals, generate content for review, and reduce mechanical work.

The product must protect definitions, permissions, evidence, states, and responsibility.

This is probably the biggest shift in my thinking since I started building a GEO product. At first I wanted to prove how much work AI could complete. Now I care more about how a product can keep every conclusion understandable, traceable, and open to reversal as AI takes part in more work.

In the next note, I will put these abstract judgments into a real iteration. We did not change the model or add a flashy generation button. A seemingly simple set of diagnostic questions nevertheless forced me to rethink data ownership, metric definitions, failure recovery, and report evidence.

It showed me that a real product redesign is often not a new visual treatment. It is admitting that the first version answered the wrong question.