Trace where a studio description comes from

Prerequisite: Lecture 1. You should already know the basic first-reading habit: record the ordinary query, read the answer, and classify how the studio was reshaped. We are still using the four studio reshaping modes as a simple reading tool, not as a score or ranking system.

In a composite teaching scene, a receptionist prints a one-page profile for a small studio because the senior partner wants to “see what is out there.” The studio’s own website says “Studio Sannaro e Associati,” the local directory says “Sannaro Studio,” and an old chamber extract uses the full legal form with initials that nobody says aloud. On a review site, one client writes, “they helped us with payroll after moving office,” although the office move happened years ago. None of these fragments is dramatic. Together, they make a slightly crooked paper stack.

Now imagine an AI answer trying to describe that studio in two sentences. It may not know which fragment is official, which is old, which is casual, and which is only a client’s memory of one service. The machine is good at making the stack look tidy. That tidiness is exactly why we must learn to trace where a studio description may come from.

The first source is usually not one source

A small accounting studio often thinks of its public identity as one thing: “our website.” That is understandable. The website is the place the studio can edit most directly, and it usually contains the careful wording. But AI systems may encounter the studio through many public surfaces: the website, a business profile, directory listings, chamber records, review snippets, old copied descriptions, local association pages, and pages that mention the studio only in passing.

Public evidence means visible material such as website pages, listings, chamber records, reviews, profiles, and repeated service phrases. I use the term in this practical sense because a studio can inspect it without opening client files or private correspondence. Public evidence is the paper left on the counter, not the locked cabinet behind the counter.

In a composite scenario like Object A, the studio’s website is mostly clean. It gives the current address, names the partners, and describes recurring accounting work for small companies. The trouble sits outside the studio’s neat page. One directory keeps an old address. Another shortens the studio name in a way that looks almost like a separate practice. A review uses “payslips” three times because that was the client’s problem, not because payroll is the studio’s whole identity.

A human reader from the town may reconcile these fragments with common sense. They know the street, the surname, the old office. A model does not share that local patience. It sees language patterns and, depending on the tool, may see retrieved pages. If the repeated public wording leans toward payroll, the generated description may lean with it.

This is why the question “Where did the AI get that?” is useful but too narrow. Often the better question is: “Which public fragments made this description easy to write?”

Training data is earlier than the question

Students often ask whether the model has “seen” their studio. The honest answer is uncomfortable: maybe, maybe not, and the answer may not be inspectable from the outside. A large language model may have been shaped by large amounts of text before the user ever asked the question. Some of that material may include public web text, business descriptions, copied directory pages, or language patterns from similar firms. We should not pretend we can open the model and find a receipt.

Training data means material used to shape a model before the user asks a question. In this course, I want you to treat it as an earlier layer, not as a visible folder you can browse. It may explain why a model has a general sense of what accounting studios do. It does not give us a clean source trail by itself.

Here is a teaching example. A user asks, “What does a small commercialista studio usually help with?” The answer may mention bookkeeping, tax filings, payroll, company forms, and advice for small businesses. That answer might not come from a live page about one studio at all. It may be the model drawing on broad learned patterns about accounting work. Useful, yes. Specific, no.

When the same user asks, “What does Studio Sannaro in this town do?”, the situation becomes more delicate. If the tool is not searching live, the answer may still draw from general patterns and whatever earlier traces were available when the model was trained. The result can sound local even when the support is thin. A confident phrase like “known for company setup” may be a pattern wearing a local jacket.

This does not mean training data is bad. It is part of how a model can write coherent language in the first place. The working discipline is simpler: do not treat an answer from stored patterns as if it had just inspected the current studio profile.

Retrieval changes the kind of mistake

Some AI tools can bring external sources into the answer at the moment of the query. Retrieval means bringing external sources into an answer through search or another connected index. When retrieval is active, the model may consult current pages, citations, business profiles, or indexed material before it writes.

That sounds reassuring, and sometimes it is. A retrieved page can help a model find a newer address or the current service wording. It can also introduce a fresh mistake if the retrieved page is a weak directory, a copied listing, or a page where the studio sits beside another provider. Retrieval gives the answer a newer desk to work on; it does not guarantee that the desk is tidy.

Source trail means visible sources that may explain why an AI answer described a studio in a certain way. Notice the caution inside that definition: may explain. A source trail helps interpretation, but it may not reveal every influence. It keeps the check grounded in inspectable evidence without pretending that we can see the whole model process.

In a teaching example, the AI answer says Object A offers “payroll and tax assistance for local shops.” The cited or visible sources include the studio website, a directory page, and a review snippet. The website says recurring accounting and payroll coordination. The directory category says payroll services. The review says the studio helped after a payslip error. The phrase in the answer is not copied exactly from one place. It is a small blend. That blend is the point.

With retrieval, we read sources like a careful clerk checking mismatched invoices. We do not ask only whether a page exists. We ask what language on that page is easy for the model to reuse. A page with a clear heading, repeated service phrase, and current address may be easier to summarize than a beautiful paragraph that hides the facts in polite fog.

Build a small evidence table before blaming the model

When a studio sees a wrong AI description, the first reaction is often irritation. I do not dismiss that. A wrong public description can waste real time. Still, irritation is a poor filing system. Before blaming the model, build a small table of public evidence.

For this lecture, the table can be very plain. Write the studio name as it appears on the website. Then write the name as it appears on two or three public listings. Add the current address, any old address you find, the main service phrases, credential language, and review phrases that repeat. Do not make the table large. If it becomes too large, nobody in a working studio will repeat it.

The purpose is not to prove the model’s hidden process. We are not inside the system. The purpose is to see whether the answer has nearby support in the public record. If the AI says “payroll specialist,” and three public surfaces repeat payroll while the website’s broader service page is vague, the studio has learned something useful. The model may be wrong in emphasis, but the public evidence has given it a slope.

A composite Object A table might show this pattern. Website: “ordinary accounting, VAT deadlines, payroll coordination, periodic advice.” Directory one: “payroll and tax declarations.” Directory two: old address, shortened name, category “employment services.” Reviews: three mentions of payslips, one mention of invoice help, no mention of advisory calls. A model that narrows the studio to payroll has not behaved like a genius. It has followed the loudest crumbs across the floor.

Add one imperfect detail to the table on purpose. Perhaps the chamber record is current, but the directory has the old street number. Perhaps the name is correct in Italian but shortened in a platform title. This prevents a false comfort. Public evidence is rarely a clean courtroom file. It is more like a drawer where receipts, stamps, and one expired train ticket have been kept together.

What we can infer, and what we cannot

This lecture sits before the course becomes more technical about comparison, naming, and correction. So our discipline must remain modest. We can observe that an AI answer resembles a directory phrase. We can observe that a review phrase appears louder than the studio’s own service page. We can observe that a live-search answer cites one source and ignores another. But we cannot always say, with certainty, “this exact sentence came from this exact page.”

That distinction protects the work from becoming theatre. It is tempting to draw arrows everywhere: this word came from this listing, that phrase came from that review, this omission came from that missing profile. Sometimes the arrows are plausible. Sometimes they are only our wish for a clean explanation.

A better habit is to grade our own certainty in ordinary language. “This phrase is directly visible on the directory.” “This emphasis is consistent with several reviews.” “This old address may have contributed to the confusion.” “We do not have enough evidence to explain why the studio was omitted.” These sentences are less dramatic than accusation, but they are much more useful.

The studio can then decide what to inspect next. If the public evidence is consistent and the AI answer is still wrong, the problem may belong to model behavior we cannot inspect from one answer. If the evidence is contradictory, the next step begins closer to home: current website wording, correction requests for public listings, clearer service labels, and a record of what changed. Those later corrections will matter more after we have learned to read the source trail without overclaiming.

What matters to remember

A studio description in an AI answer may come from several public fragments, not from one neat official profile. The website matters, but it is only one surface among listings, records, reviews, profiles, and repeated phrases.

Training data is earlier than the user’s question, while retrieval happens at answer time. Confusing those two layers makes a studio expect visible proof where none may be available.

A source trail helps you interpret an answer, but it is not complete proof of every influence behind the sentence. Use careful language: visible, likely, possible, unsupported.

The course anchor still applies here: four ways an AI answer reshapes a small accounting studio — names the practice, narrows the service, borrows nearby evidence, or leaves the firm unmentioned. In this lecture, we begin asking which public evidence may have made each reshaping easier.

Before correcting anything, build a small evidence table. The table should be humble enough to repeat and concrete enough to show where the public record is clear, thin, or contradictory.

Check yourself

Explain in your own words why a studio website is not the whole source picture for an AI answer.

A studio website is important because it is usually the clearest source the studio controls, but AI answers may also be shaped by other public material. Directories, review snippets, chamber records, copied profiles, old listings, and repeated service phrases can all create a wider public picture. If several outside sources use a shortened name or repeat “payroll” more clearly than the website explains broader accounting work, the AI answer may follow those stronger fragments. So the website is central, but it is not the only public evidence a model may use or echo.

Give a practical example of public evidence that could narrow a studio’s description too much.

A practical example would be a studio whose website describes ordinary accounting, VAT deadlines, payroll coordination, and periodic advice for small companies, while two public directories list it mainly under payroll services. If several reviews also mention payslips because clients remember that concrete task, an AI answer may describe the studio as a payroll specialist. The description is not completely invented, since payroll is part of the work. The problem is that the public evidence has made one service louder than the rest, so the generated description becomes too narrow.

How would you distinguish training data from retrieval when reading an AI answer about a studio?

I would treat training data as the earlier layer that shaped the model before my question, and retrieval as source use during the answer. If the tool gives a general answer without visible current sources, I should not assume it has just checked the studio’s website. It may be answering from learned patterns about accounting studios. If the tool shows current links or citations, retrieval may be involved, but I still need to inspect those sources. A retrieved source can be current and still weak, vague, or misleading.

When does a source trail help, and when does it fail to prove enough?

A source trail helps when visible sources explain why the AI answer used a certain name, address, service phrase, or category. For example, if the answer calls a studio payroll-focused and several public listings repeat payroll language, the trail gives a reasonable explanation. It fails to prove enough when the visible sources do not contain the claim, or when the answer seems blended from general patterns and local fragments. In that case, I can say the claim is unsupported or only partly explained, but I should not invent a precise cause.

How would you explain this evidence-table habit to a busy accounting partner who dislikes “AI audits”?

I would describe it as a small public-record check, not a big technical audit. The point is to see whether the studio’s name, address, services, and repeated phrases are consistent across places clients and machines may read. The table can be short: website wording, two directories, one record, and a few review phrases. It helps the studio avoid guessing. If the AI answer is wrong, the table shows whether the public evidence is already clear or whether old listings and narrow descriptions are making the wrong answer easier to write.