How a Machine Sees Meaning

Before AI can decide what to cite, it first has to understand what your words mean.

You write your homepage for a person to read. Increasingly, the first reader is a machine: an AI system deciding what to cite, summarize, or use when answering a question about your company. How it arrives at that answer starts before it says anything back, and it starts by not reading your page the way a person does.

Humans read. Machines transform.

A person reading a homepage does it the way they read anything: left to right, one sentence building on the last, filling gaps with everything they already know. A phrase like “built for teams that move fast” means something to a human reader because they bring their own experience to it. They've met teams like that. They know what “fast” implies in context.

A language model — the kind of AI behind tools like ChatGPT or Claude — doesn't read that way. Before it can do anything with a page (answer a question about it, decide whether it's relevant to a search, summarize it), the text first gets broken apart and turned into a different kind of thing entirely — one built for comparison, not for comprehension the way a person means it. That doesn't mean it processes words out of order. It still tracks sequence closely. It just means what it builds from that sequence is a different kind of thing than human understanding.

We'll walk you through what that transformation involves: how a page gets split into pieces, how those pieces become something a machine can compare, and what happens once a model turns that into an answer (FIG. 1).

Words become chunks.

A model can't take in an entire page at once and treat it as a single unit. So before anything else happens, a page gets cut into smaller pieces, usually a few hundred characters each — in the script built for this piece, that target is roughly 600 characters a chunk. This process is called chunking, and it's what makes it possible to compare or retrieve one section of a page independently of the rest.

The split tries to respect structure. It breaks on a heading, a paragraph, or a sentence, gets each piece close to that target size without going over, and copies a little text across every seam so nothing gets stranded. Nothing is lost in the process — the page is only broken up. But here's the part that changes everything: from this point on, the model works on the pieces, not the page (FIG. 2).

Whatever piece the model is working with, that piece is the whole of what it sees: not the page, not a section chosen because it means something on its own, but a fixed-size slice lifted out of everything around it. If a fact only makes sense because of a sentence three paragraphs up, that sentence isn't in the slice — and the model doesn't go looking for it.

The example above uses a fictional company we built specifically for this piece, called Verdrax, invented so the model couldn't lean on anything it might already know about a real brand.

Meaning becomes vectors.

Once a chunk exists, it gets converted into something else entirely: a long list of numbers meant to capture what the chunk is about. That conversion is called an embedding, typically hundreds of numbers per chunk, computed here using OpenAI's embedding model. What matters isn't the individual values. It's what they're used for: two chunks that mean similar things end up with numbers that are mathematically close together, and two chunks about different things end up far apart.

The diagram above (FIG. 3) uses three real chunks from the same homepage split apart in the last section. The “What We Do” chunk and “The Problem” chunk scored 0.79 out of a possible 1.0 for closeness — both talk about vendor documentation and onboarding friction, so that tracks. The “Deployment & Security” chunk, about hosting and certifications, scored only 0.58 against “What We Do”: related enough to still register as connected, but noticeably farther.

One thing we should be upfront about: real embeddings have far more dimensions than a flat picture like this can show, so this is a simplified “closer or farther” illustration, not a literal map of where these chunks actually sit. What stays true either way: comparing meaning, once everything is embedded, comes down to measuring distance between lists of numbers, not reading anything.

Retrieval is not understanding.

Retrieval is what this pipeline calls finding a page, and it's a different step from understanding what's on it. A search query gets converted into the same kind of number-list as any other chunk, and a system compares it against every page's numbers to see which ones land closest. That's what “relevant” means here: mathematically close, not necessarily correct.

But a page landing close to a query doesn't guarantee anything about what happens next. It just means the page got a look. Whether a model can actually pull a correct answer out of what it was handed is a separate question — and it's the one that matters. The question isn't whether the model is smart enough to understand your page. It's whether your page gave it anything to understand.

The model builds an answer.

Once a model actually has content in front of it, whether that arrived through retrieval like the last section, or simply by being handed a page directly, its job is to build an answer using only what it has. That step is generation — a separate question from how the content got there, and the one this whole project was really built to measure. Given what it was handed, does the model answer correctly? Does it invent something when it wasn't given enough?

For this part, we didn't chunk or retrieve anything. We tested it with Claude directly, handing over one full page at a time — the whole page at once, no retrieval ambiguity — and asking ten real questions about the company plus one question with no true answer anywhere in any version, built specifically to see what happens when the model has nothing to work with. The clear version's page names NetSuite, SAP Ariba, and Coupa directly in its integrations section, and questions about those got answered correctly every time. Handed the trap question, on a page where no price is ever stated, Claude answered: “The text does not state a dollar price for the Starter plan… No monthly dollar figures are given.”

Across every version, every question, every time we asked, Claude never once invented a specific detail in place of a missing one. The two versions that stated their facts directly each answered 95% or more of the ten questions correctly (FIG. 4). The version that left everything vague answered about a third. The model didn't misread it — there just wasn't much stated to extract.

The failure mode here isn't the model getting something wrong. It's a vague page giving it very little to say in the first place.

What this changes.

Put together, here's what happens between your homepage and an answer an AI gives about it: the page gets split into pieces, each piece becomes a list of numbers representing what it means, a question gets compared against those numbers to find what's relevant, and then, using only what was found, the model builds an answer. Nothing in that chain reads your page the way a person does. Nothing in it invents what isn't there, either.

That makes your homepage's real job a little different from the one it was probably written for: not to make a good impression on a reader who's already paying attention, but to make sure every important fact can stand on its own, pulled out of context with nothing around it to prop it up. The practical implication is blunt: whatever fact isn't stated plainly somewhere on the page (a specific integration, a specific price, a specific industry) won't survive the trip through this pipeline into an answer. Not because the model misunderstands it. Because there's nothing there to find, retrieve, or generate from.

The two versions that performed well in our test didn't have much in common stylistically. One was repetitive and keyword-heavy. The other was clean and direct. But they shared the one thing the vague version didn't: both stated the same key facts explicitly, by name. That's the one thing we can point to with confidence. Whether polished writing helps or hurts on top of that is still an open question — this test wasn't built to isolate it — but explicit, named facts weren't optional in either version that worked.

A machine doesn't read your homepage. It takes it apart, measures it, and tries to answer questions using only the pieces that survived that process. Whatever you want it to know about your company has to actually be there, stated plainly, in the pieces.