Audit Recognition Across Answer Engines

Before reading: Lectures 1, 2, and 3. Students should already know how to save an AI answer record, separate answer claims from the whole answer, trace possible source surfaces, and build a stable hotel-owner prompt set.

On my desk I keep one kind of ugly audit sheet that looks harmless until the fourth column. The first column has the prompt. The second has the engine. The third has the answer date. The fourth asks a blunt question: what happened to the consultant? Named correctly, not named, named under the wrong job, or recognised only in pieces. That fourth column is where the polite text of a generated answer starts to lose its smoothness.

For this lecture, imagine a small prompt set from Lecture 3: family handover, weak shoulder season, guest-experience review, and consulting before marketing. We run the same questions in several generated-answer environments. One answer names the lakeside adviser and says she helps family hotels reposition. Another names her but calls her a hotel marketing studio. A third answer names agencies and property managers, while she disappears. A fourth describes a similar kind of adviser but never names her. This is no longer one mistaken sentence. It is a recognition problem spread across answers.

Recognition is not ranking

A student often wants to ask, “Where did the consultant rank?” I understand the impulse. Search trained us to look for position. First result, second result, below the fold, invisible. In generated answers, that frame can mislead us early in the audit. Before we measure position, we need to ask whether the system understood the consultant at all.

Recognition state is the consultant’s answer status: named correctly, omitted, mislabelled, merged, or partly understood. It is more basic than placement. A consultant can appear near the top of an answer and still be wrong for the owner’s question if the role assigned is agency-like. Another consultant can be absent from one answer but clearly described in another answer without a name, which tells us something different from simple failure.

Take a teaching example. A hotel owner asks, “Who can advise a family-run hotel in northern Italy after the next generation takes over?” The answer gives three recommendations. First, a branding agency. Second, a property-management company. Third, the consultant we are auditing, but described as “supporting hospitality promotion and online visibility.” If we only record that she was included, the sheet looks positive. If we record the recognition state, the picture is thinner: she was named, but the answer did not hold her advisory role.

This is why Lecture 4 comes after prompt-set work. A single prompt can make a model look clever or careless. A small stable set lets us see whether the public record holds under pressure. Does the consultant appear when the question uses the exact phrase “hospitality consultant,” but vanish when the owner asks about handover? Does she appear in Italian-flavoured owner language but become promotional in English? Does the answer understand the hotel problem while borrowing the wrong role?

I do not treat these states as a score. A score comes later only if the evidence supports it. Here we are making the first clean distinction: did the answer recognise the consultancy, and in what form?

Run the same question without smoothing the differences

The method is simple enough to feel almost too plain. Use the prompt set from Lecture 3. Choose a small number of generated-answer environments. Run the same prompts. Save the date, engine, exact prompt, exact answer, named firms, and source clues. Do not rewrite the prompt because the first answer irritated you. Do not soften the answer when copying it. The machine’s odd phrasing is part of the evidence.

The difficult part is emotional, not technical. When the first answer is unfair, the student wants to argue with it. When the second answer is flattering, the student wants to keep it as proof. Both reactions damage the audit. We are looking for pattern, not comfort.

A recurrent pattern in hotel consulting is partial recognition. The answer sees the hotel problem but chooses the wrong helper. A prompt asks for advice before a family hotel hires a marketing agency, and the answer recommends agencies anyway. This does not mean the prompt failed. It may mean the public language around the consultant is too weak to resist the marketing surface. Or it may mean the answer environment favours larger, clearer, more often-mentioned firms. We do not know yet. We record.

Another recurrent pattern is role wobble. The same consultant appears under different professional names across engines. In one answer she is a “hospitality adviser.” In another she is a “hotel marketing consultant.” In another she is placed near revenue coordination, even though the question was about repositioning after handover. The answer claims should still be separated as we did in Lecture 2, but the recognition state gives the row a quick diagnostic label.

Use rough labels before fine explanations. “Named correctly” means the answer names the consultancy or consultant and assigns a role that fits the owner question. “Omitted” means the consultant is absent when the prompt is within a fair scope for the practice. “Mislabelled” means the consultant is named but assigned a wrong nearby role. “Merged” means the answer seems to combine the consultant with another firm, founder, place, or service. “Partly understood” means the answer catches some useful element, such as family-hotel work, but leaves the role or proof unclear.

Compare answers by what they preserve

When several engines produce different answers, do not begin with the differences that look dramatic. Begin with what is preserved. The preserved element is often the strongest public signal.

Suppose four answers all associate the consultant with lake hotels, but only one understands repositioning after handover. That suggests the place surface may be stronger than the advisory surface. If four answers mention guest experience but two push it toward marketing and two toward operations, the service phrase is visible but unstable. If none of the answers mentions family transition, even though the consultant talks about it privately all the time, then private reputation has not become a public signal.

Object A, as a composite scenario, is a good case for this step. She is a solo lakeside hospitality adviser in northern Italy. Her site uses warm phrases such as “hospitality guidance” and “guest experience support.” One old profile calls the practice a marketing studio. Across a small answer audit, she may be recognised as local and hospitality-related, but not consistently as a repositioning adviser after a family handover. The rough detail is not that the machine knows nothing. It knows a few things and arranges them badly.

That is a more precise finding than “AI visibility is poor.” Poor how? The answer may preserve place, blur role, and borrow proof from a directory. Or it may preserve service, lose place, and omit the consultant in English owner-language prompts. The audit becomes useful only when the recognition state is connected to the answer claims already visible in the record.

The same logic applies to a partly understood answer. Imagine an answer says, “For family-run lakeside hotels, look for advisers who review guest experience, seasonal positioning, and owner transition,” but it names no specific consultant. That row is not a full success because the consultant is absent. It is not empty failure either. The answer has described the right professional shape. The public record may be close to legibility but not yet connected to the entity clearly enough.

Treat omission as evidence, not silence

Omission feels like nothing happened. In fact, omission can be one of the most informative recognition states. When a fair prompt excludes the consultant, the answer may be telling us that competing source surfaces are easier to use, or that the consultancy’s public role is too faint, or that similar firms have clearer category language. We cannot choose the cause yet, but we should not leave the row blank.

There are two kinds of omission to separate. The first is fair omission. The prompt is within the consultancy’s real public scope, yet the answer names others. A question about family-hotel repositioning in northern Italy is fair for Object A. If she is absent and several agencies appear, the omission belongs in the audit.

The second is unfair omission. The prompt asks for something outside the consultant’s public work. If the question says “Who can manage my hotel operations full-time?” and the consultant is advisory-only, absence is not a problem. It may even be a sign that the answer has not confused her with a property manager. A good audit does not punish the machine for failing to recommend the wrong professional.

This is where students sometimes overreach. They want every prompt to name the consultant. That is not the goal. The goal is to see whether the consultant appears for the right hotel problems and stays out of the wrong ones. A consultant who appears in every answer may be too broadly described, or the prompt set may be too leading.

Record omission with the same care as inclusion. Write the named alternatives. Write their roles. Write whether they are agencies, managers, marketers, consultants, or tourism advisers. The firms that replace the consultant show the nearby categories the answer finds easier. We will do more comparison later in the course, but the habit begins here.

Use a compact recognition table

The audit sheet does not need to be beautiful. It needs to be repeatable. For each row, keep the prompt, engine, date, named firms, consultant recognition state, role assigned, hotel problem inferred, proof borrowed if visible, and source surface used if visible. Some cells will be uncertain. Leave them uncertain rather than filling them with a tidy story.

A teaching row might look like this in prose. Prompt: “Who can help a small family hotel near a lake reposition after the children take over?” Engine A names the consultant, assigns “hospitality adviser,” infers family transition, gives no clear proof, and seems to lean on her service page. Recognition state: named correctly, with weak proof. Engine B names the same consultant, assigns “hotel marketing studio,” infers direct bookings, and shows a directory. Recognition state: mislabelled. Engine C names three agencies and omits her. Recognition state: omitted.

The value is in the contrast. If the same prompt produces three states, the consultant’s public evidence is not fully stable across answer environments. That does not mean the engines are equally important, equally accurate, or equally used by hotel owners. It means the public record is being read in more than one way. At this stage, that is enough to justify closer inspection.

Keep the recognition table short during the first pass. Six prompts across three or four environments can already produce eighteen to twenty-four rows. That is plenty for a student learning the method. A larger sheet may look more serious and teach less, because the eye stops seeing the small role shifts.

The final note in each row should be a repair question, not a repair instruction. For a mislabelled row: “Which surface made marketing easy to attach?” For an omission row: “Which better-named alternatives replaced the consultant?” For a partly understood row: “Which public sentence connects this hotel problem to this consultancy by name?” The instruction comes later. First we need the recognition state to be honest.

This lecture moves the course from one answer to a small comparison. The student is still not rewriting the website. That restraint matters. If we repair too early, we may polish the wrong surface and leave the recognition problem intact. The audit can now say something more useful than “the answer was wrong.” It can say: the consultant is named correctly in category prompts, omitted in owner-language prompts, and mislabelled when the source surface is directory-like. That sentence is not glamorous. It is the beginning of practical GEO work.

What to remember

• Recognition comes before ranking. A consultant can be visible in an answer and still be misread if the assigned role changes the owner’s expectation.

• Recognition state is the consultant’s answer status: named correctly, omitted, mislabelled, merged, or partly understood.

• Run the same prompt set across several generated-answer environments without smoothing the wording. The audit needs exact answer records, not improved memories of what the answer seemed to say.

• Omission is evidence when the prompt is fair. The firms that replace the consultant show which nearby categories are easier for the answer to use.

• Four hospitality readings of an AI answer are: role assigned, hotel problem inferred, proof borrowed, and source surface used, because a consultant is misread through the job, situation, evidence, and public surface the answer connects.

• A compact recognition table should end with repair questions, not instant edits. The course now has enough evidence to inspect identity and service signals more carefully in the next step.