One Home Many Windows

/ Uncategorized / By

How to author a canonical record that renders your site, your feeds, and your machine layer from one governed source, and why the page is now an output rather than the original

The first two articles in this series built the case for this one. “The Friction Is the Code, Not the Feeling” argued that the machine layer matters and that emotion can be structured rather than trapped in a layout. “Search Was the Detour” argued that you have to model your meaning and own it. This one is about the part nobody shows you: how the source of truth should be built, enriched, and kept honest, and why building it inverts the order in which the web has been made for thirty years. The price lived in five houses because there was no home. This is how you build the home, move the truth in, and let every house become a window onto it.

The inversion: author the record, render the web

Part two ended on a vacancy: the modeled data layer that almost no one owns. This article is about filling it, and the first thing to say is the most disorienting, because it reverses the order the web is built in.

For thirty years the page has been the original and the data an afterthought scraped back out of it. The canonical record flips that. The record becomes the thing you author, and the page, the feed, the schema, the llms.txt, and the agent manifest all become things you generate from it. You do not write a product page and then reverse-engineer structured data to describe it. You author the product as a record, once, and the page is one rendering of that record, the feed is another, the machine layer is another. The page stops being the source. It becomes an output.

That is not a tooling change. It is a new build order, and it is heresy to how most sites are made, because it puts the data first and treats the creative as a view rather than the deliverable. It is also the only arrangement that survives an agent reading you, because the agent reads the record, and if the record exists only as a side effect of the page, you are back to archaeology.

Hold onto the image from the last article. The “product price” lived in five houses: the page, the schema, the feed, and soon the llms.txt and the EntityMap, because there was no home, and every consumer kept its own copy. The canonical record is the home. Once it exists, the five houses are not five sources to be reconciled. There are five windows in one room, and a window cannot disagree with the room it looks into. The whole maintenance nightmare of keeping copies in sync dissolves, not because you got better at syncing, but because you stopped having copies and started having views.

It helps to see this as a progression through three states, because the middle one is a trap if you mistake it for the destination. Today, most organizations author into the page and then scrape the page to recover structure: data last, the retrofit world part two indicated. The migration state keeps authoring into pages but runs an extraction loop to bootstrap the record, so you are not starting from an empty database. That is fake it: useful, temporary, and dangerous only if it becomes permanent. The end state is to make it: structured content is authored directly in the CMS, the record is populated at the moment of creation, and every surface renders from it. The offers team fills in the price and the validity dates as named fields. The product team authors the entity and its relationships. The writer attaches the emotifact as a structured attribute rather than pasting prose into a layout. Nobody is reverse-engineering anything, because nothing was buried in the first place. The CMS stops being a page builder and becomes the front end of the record.

The tell that you have actually inverted the build order is simple: the extraction loop stops teaching you anything, because the CMS already captured it at authoring time. If a year in you are still scraping your own site to populate the record, you did not invert anything. You bolted a database onto the same broken workflow and kept doing archaeology.

The emotifact faces both ways

Here is the part that turns this from a database project into the center of the whole series.

A plain attribute, “heated seats: yes,” is machine-facing and inert. It tells an agent a fact and does nothing for a human. The glossy headline on the page, “command the winter,” is human-facing and inert to a machine, which cannot tell aspiration from noise. The first article called the fusion of the two an emotifact and argued that emotion could be structured rather than trapped in a layout. The canonical record is where that claim pays off, because the emotifact is the one authored object that faces both directions at once.

“Warm enough for a Reykjavik winter, packs to nothing” is a single field in the record. Rendered to the page, it is the pageantry that stimulates the purchase, the feeling a human buys on. Rendered to the machine layer, it is a disambiguating, connecting signal an agent matches against a long, intent-loaded prompt. One authored object, two audiences, zero duplication. The human channel and the machine channel are not two contents you maintain in parallel. They are two renderings of the same emotifact.

That is the resolution of the tension the series opened with. The emotifact is not a compromise between selling to people and being legible to machines. It is the single source both renderings come from, which is why structuring your data does not sand the soul off the brand. The soul is in the record now, authored once, and it renders into the pageantry and into the machine layer from the same place.

Collection is how you move in, not how you live

So how do you get a record when everything you own today lives as multiple pages? You mine it out of them, once, with a pipeline, and then you stop.

This is worth saying carefully because the pipeline that bootstraps the record is, structurally, the same archaeology that the last article indicted: reverse-engineering structure from the rendered page. That is fine as a migration. You use it to set up the home quickly from the mess you already have. It becomes a problem only if you mistake it for the steady state and keep extracting from the page forever, which quietly rebuilds the inside-out architecture the series condemns. Extraction earns its place only as the on-ramp to not needing it.

A workable version, kept to its shape here so it does not crowd the argument, runs in three stages. You crawl and pull the clean page text away from the rendering. You extract, passing that text to a model that returns a structured candidate record: the primary entity, the secondary ones, the type, the aliases, a confidence score, and an evidence paragraph lifted from the page. And you resolve, checking that candidate against an external authority so the thing you found is tied to the canonical entity the rest of the world already recognizes, with its identifier written back into the record. The full mechanics, the tool chain, the extraction prompt, and the field-by-field schema are in the addendum at the end, so the concepts can stand here without the implementation on top of them.

Two disciplines make this trustworthy rather than tidy-looking. First, keep extraction and resolution as separate jobs. Extraction proposes what a page is about; an authority determines which canonical thing that is. Trusting the model’s memory for a canonical identifier is how you end up with an island only you recognize, instead of an entity the agentic web can match. Second, treat the confidence score for what it is. It is the model grading its own homework, a self-report useful for routing a human’s attention and worthless as a guarantee. High confidence is not accuracy. Accuracy comes from the resolution step and from agreement over time, not from the number the model assigned itself. Use confidence to decide what to send for review, never as proof.

Augment until the record is prompt-complete

Mining your pages gets you a record of what you already said. It does not get you a record that can answer what an agent will ask, because your page knows your spec and your price and almost nothing about how your product relates to anything else.

The goal is not to model your catalog. It is to model your catalog richly enough that the prompts an agent could pose are already covered by the relationships in the record. That is a higher bar, and you clear it by augmenting: enriching the record with relationship edges and external data until it is, for lack of a better word, prompt-complete. Compatible accessories. Substitutes. What it works with. The occasion it suits. The regulatory scope it is valid in. The canonical identity that ties it to the wider graph of things the machine already knows.

You do not have to guess at the shape of those prompts, because the platforms are telling you. Google’s Merchant Center is rolling out dozens of new conversational attributes that go past keywords to include answers to common product questions, compatible accessories, and substitutes. That is the platform publishing the shape of the prompts that are coming: comparative, compositional, occasion-driven. And the reason is on the demand side. By Google’s own figures, queries in AI Mode run two to three times longer than traditional searches, because the shopper no longer types “casual sweater,” they type something closer to “I am going to Atlanta in a few weeks and need a casual sweater.” For the first time the system can see why a shopper wants a thing, not just what. That sentence is a verb arriving in full, occasion-loaded form, which is exactly the shift our friend Jeremy Sanchez named as the verb economy in part two: a noun asks to be found, a verb asks to be fulfilled. The longer query is the verb, and it asks the record to be fulfillable, not merely findable.

Here is the corroboration worth pausing on, because it comes from the least likely source. As Courtney Rose, VP of Google Ads, stated in an interview with Retail TouchPoints interview, product data is shifting from advertising material into, in her words, “the language of agent interaction.” That is the supply side of Jeremy’s thesis, confirmed by the one party with the most to lose by admitting it. When the platform reclassifies your product data from copy-to-be-ranked into the language an agent speaks when it acts, it has conceded the whole premise: the unit of commerce is no longer the keyword you rank for, it is the capability the agent invokes. The narrow commerce case is proving the wide claim. Your record becomes fulfillable when it can answer in that language, which means when the relationships the verb needs to traverse are already in it.

Find the real questions, not the flattering ones

There is a trap sitting in the middle of all this, and a lot of the industry has already fallen into it. The moment “cover the prompts an agent could pose” became the goal, a gamed version of finding those prompts appeared: dream up the questions you wish you won, fire them at a few models, screenshot the wins, and call it a visibility study. It is the old vanity-keyword move aimed at LLMs, and it produces a number that climbs but means nothing. Marty Weintraub names the failure plainly: the self-promoted prompt engineer who types a handful of prompts into a premium model, watches the brand surface, and feels bullish, because the AI is very good at confirming the bias it was handed. The tell of the rigged version is that the prompts were chosen to be won.

The honest version inverts the sourcing. You do not invent the question-space; you observe it, and you weight it by provenance. Marty strongly argues that the real prompts come from first-party demand: support tickets, service chats, the brand’s own FAQs set against the category’s, reviews, the arguments in communities where buyers actually compare, the People Also Ask already exposed in search. Weintraub’s hinge is that provenance is the single most important test of a prompt-fanning program, and the reason is structural. A single buyer query does not hit the engine once; it fans out into roughly five to twenty internal sub-retrievals, so your brand is judged across the whole fanned space at once. A handful of hand-picked prompts does not just flatter you, it measures the wrong space entirely, and precision on the wrong question-space buys nothing.

This is why the question space belongs in the augment step and not in a measurement report. The honestly sourced question-space is the specification for the record. It tells you which relationship edges you actually need, because it is the real demand the record has to satisfy. Build against invented prompts, and you enrich the record toward answers no one is asking for. Build against observed ones, and every edge you add earns its place. The Absolut Vodka example from the emotifacts article is the working example of doing it right: the taste question was not invented in a war room; it was one of the most common things buyers actually asked; and the brand authored emotifacts to answer it before a machine answered it for them with a competitor. Find the real question, author the real answer. That is prompt fanning in its honest form, and it is the demand that the supply side builds against.

The record is a graph

Notice what “the relationships the verb needs to traverse” implies. A prompt like Google’s Atlanta sweater example is not answered by a record; it is answered by a connected one: the sweater, its weather suitability, what pairs with it, and whether it arrives in time. The agent is not fetching a fact. It is walking a path from one entity to the next. Which means the canonical record is not really a record. It is a graph.

This is the same artifact that two traditions have been building from opposite sides, and the convergence is worth naming because it is what makes the series cohere. The content-engineering world has long argued for a connected graph of entities and relationships as a governed source of truth rather than a pile of pages; Benu Aggarwal of Milestone puts it plainly: AI sees entities and relationships, not pages. EntityMap, from part one, is an entity-and-relationship model. The isPartOf and hasPart links from the car example in part two are graph edges. Jeremy’s verbs traverse relationships. Google’s language of interaction is spoken over connected data. They are all describing a graph that the machine walks.

And the consuming side is moving to meet it. Retrieval is increasingly graph-aware: instead of fetching loose passages from a flat index and guessing at the connections, systems retrieve a connected subgraph and reason over the relationships already declared in it. The honest version of this point matters, so here it is: not every AI system does graph retrieval today, and you do not need to ship a graph database to compete. Plenty of retrieval is still flat vectors, and a clean record with declared relationships captures most of the benefit. The defensible claim is narrower and sturdier: the relationships are the asset, however you store them, and graph-native retrieval is where the consuming side is heading, so modeling the edges now is the bet that ages well.

This is also where the emotifact stops being a flat field and becomes part of the structure. In a graph, the emotifact is a labeled attribute on a node or an edge, the persuasive signal living right alongside the factual ones the agent traverses. “Suited for a New England winter” is not decoration bolted to the page; it is an edge between the product and a use case, weighted with the confidence the standard requires. The pageantry and the facts are in the same graph, and the agent walks both.

Augmentation is also how you poison the well

Everything good about augmentation is also the risk, and the article would be dishonest not to say so. The moment you fuse external and relational data into the record, you create a path for wrong, stale, or conflicting data to enter your single source of truth. Augmentation without provenance and validation is not enrichment. It is a way to scale a mistake, because now the error renders into every window at once.

So two rules ride with augmentation. Every fused fact carries its provenance: where it came from, when, and how confident you are in it, so a bad source can be traced and pulled rather than silently believed. And the record is monitored for drift, which in a world with a canonical home has a precise meaning. Drift is disagreement with the home. You re-read the world, the pages, the feeds, the external sources, and you diff what you find against the canonical record. A page that no longer matches the record is not new data; it is a rendering bug, and the home wins. The reason the inversion matters here is that it makes drift legible. If you are still extracting from the page, you cannot tell an authorized update from drift, because you have no authority to compare against. Once the record is the source, every disagreement has a right answer.

And the well is not only poisoned by your own hand. Even a pristine record is read alongside the open web, which is an adversarial surface in its own right. A recent Cornell Tech study of deep-research agents found that because an agent fans one question into many sub-queries and keeps retrieving the same handful of community pages, a single short planted comment on one frequently-retrieved Reddit or Wikipedia page, on the order of thirteen words, can push an attacker-chosen entity into the answers for an entire cluster of related questions. A competitor or a scammer can inject themselves into your category without ever touching your site. Worse, the obvious defenses failed in the study, and failed instructively: filters that try to catch the injected text by its awkwardness throw away the wrong thing, because the optimized poison reads as more fluent than the surrounding organic human writing. The lesson points exactly where this series has been heading. You cannot filter your way to trustworthy answers at read time. The defense is provenance and verified, owned structure established at authoring time, which is the case for the canonical record stated from the threat side rather than the efficiency side. This is also the adversarial twin of the measurement point that follows: the same retrieval overlap that makes honest prompt fanning necessary is the thing an attacker exploits.

There is a matching honesty owed to the scorekeeping, because the same maturing stack that lets you build the record is starting to hand you measurement surfaces, and they can fool you as easily as bad data can. As Marty Wintraub observes, Google’s AI-search control stack, the controls, the reporting, and the impression definitions, is now concrete enough to write operating procedures around, which is real progress. The catch is that these tools manufacture false confidence the moment a team treats an “impression” as if it were the same thing as being retrieved, being used to ground an answer, or actually influencing the buyer. Those are four different layers, and a dashboard that blurs them tells you that you are winning when you may only be present. This is the measurement-side echo of Jeremy’s mentioned-versus-used distinction: separate the layers, or you will optimize the record toward the number that is easiest to move rather than the one that is worth moving.

That same machinery is where this article hands off to the next one. Diffing one record against the world is drift detection. Doing it across forty markets, where the “same” product carries different prices, claims, and regulatory scope, is where a single confident record meets the problem of cross-market contamination, and that is the subject of part four.

One record, many envelopes

Now the satisfying part, the payoff, the first article’s whole zoo of formats was waiting for.

Once the validated, augmented record exists, llms.txt, EntityMap, OKF, the schema markup, and the ARD manifest are not five strategies. There are five serializers reading the same record. The website is a serializer. The merchant feed is a serializer. The agent envelope is a serializer. None of them is a source; all of them are renderings. The parser you need is not four parsers; it is one canonical object with a rack of emitters hung off it.

It is worth being honest that the emitters are not free to build. Each one is real work to stand up. But they are cheap to run and, crucially, cannot disagree with one another because they share a source. That is the structural cure for the five-copies-of-the-price problem, stated as architecture rather than discipline. You do not keep the copies in sync. You generate them, so there are no copies to keep in sync. One home, many windows.

This is also where we have to break an older reflex: one entity, one page, optimize the page. That was a search-era assumption, because the page was the unit the engine ranked. Once the record is the source, the machine view is free to have a completely different shape than the human one, and the car from part two is the clearest case. A Tesla model takes a dozen pages for the marketing experience, the glossy hero, the configurator, the towing story with its own photography, and it should, because paginating the experience is how you sell to a human. But the agent wants the opposite shape: a single, deep, complete representation of the model that it can read in a single retrieval, not twelve documents it has to crawl and stitch back into one thing. You do not choose between them. Both are renderings of the same record. The twelve pages are twelve partial views, each surfacing the slice relevant to that step of the human journey. The machine view is the full view, the same entity serialized whole. Twelve windows for the human walk-through, one door for the machine, authored neither by hand.

This is the assembly tax from part two, solved from the supply side. There, the agent paid to assemble your scattered model by crawling and stitching, and the fix was to make it cheap to assemble. The record makes that literal: you assemble the entity once, at authoring time, and publish it whole, so the agent retrieves the model in one call and pays no assembly tax, because you already paid it where it was free. And the connective tissue inverts too. Today, the dozen pages are tied together by navigation and a buried link, presentation-layer plumbing that the agent has to infer from URL patterns and breadcrumbs. In the record world, each page does not link to the others as the source of truth about their relationship; each declares that it is a view of the same model entity, carrying the same canonical identity and a stated membership in the model. The human navigation still works as navigation. The machine simply never depends on it, because the membership is asserted in the data, not implied by the menu.

The honest caveat keeps this from sounding like magic: the single deep machine representation has to be generated from the record, not hand-built as a thirteenth artifact. The moment someone authors a separate “machine deep-dive” by hand, you have a thirteenth house, free to drift from the other twelve. It works only because it is emitted from the same record, which guarantees that all thirteen views agree.

What this actually takes

None of this is a weekend project, and the series has earned the right to be plain about the cost. The pipeline is the easy part. The hard part is the same hard part as always: someone has to own the record, decide its model, govern what gets augmented into it, and keep the drift loop running. The build is not the milestone; the maintenance is the discipline. A record that is authored once and then left to rot is worse than no record, because it is confidently wrong in every window at the same time.

Which is why this loop is not a project you finish but a program you run, and it is the architecture under the role and the program that the earlier articles are named. But notice what the role actually owns. Not a scraper, and not a database off to the side, which would only be a sixth house with a sync problem. It owns the workflow change: getting structured authoring into the CMS and the commerce process, so that the offers team, the product team, and the writers populate the record as a normal part of their jobs when they create the thing. That is the hard part, and it is organizational rather than technical, which is exactly why it needs an owner senior enough to change how other teams work. The VP of Answers owns the record by owning the workflow that fills it. The Answers Management Program is how the loop, collect, resolve, augment, validate, monitor, and emit is run as a managed discipline rather than a one-time migration, driven through the CMS and the content workflow rather than bolted alongside them. The canonical record is what it produces, and the site, the feeds, and the machine layer are what the record renders into.

So the destination, stated cleanly, is the inversion of the article opened with. You bootstrap the record by mining your pages, and then you turn the architecture around, so the page is generated from the record and the crawl-and-extract loop stops being your supply line and becomes a verification harness, the thing you run to catch drift rather than the thing you depend on to know what you sell. You stop doing archaeology on your own website. You author the home, and let every window render from it.

That is the build. The next article is about what happens when one company has to say the same true thing in 40 markets at once.

This is the third article in a series. Part one, “The Friction Is the Code, Not the Feeling,” makes the case for emotifacts; part two, “Search Was the Detour,” argues for modeling the data layer and owning it . The verb economy framing is Jeremy Sanchez’s, “The Verb Economy”. On entities, relationships, and schema drift, see Benu Aggarwal (Milestone) in Search Engine Land and MarTech. On prompt fanning, the question-space, and separating measurement layers, see Marty Weintraub, “AI Measurement & Prompt Fanning WTF: A C-Suite Survival Guide”. On adversarial poisoning of agents through user-generated content, see Zhang, Triedman, and Shmatikov, “Deep-Research Agents Can Be Poisoned via User-Generated Content”. The “language of agent interaction” phrasing, the two-to-three-times-longer AI Mode queries, and the Atlanta sweater example are from Courtney Rose, VP of Google Ads, in an interview with Retail TouchPoints (April 7, 2026); Merchant Center’s conversational attributes and the Universal Commerce Protocol are Google announcements, 2026.

Addendum: a worked extraction pipeline

This is fake-it scaffolding. It bootstraps the record from twenty years of pages you already have, so you are not starting from an empty database, and that is the only reason it exists. In the make-it end state, there is nothing here to run as a supply line, because nothing is extracted: the record is authored directly in the CMS at the moment content is created, and the pages are rendered from it. Crawling your own site to recover structure is, by definition, a symptom that the workflow has not been fixed yet.

So this loop has two lives. As a migration tool, it populates the record once from the mess you already shipped. As a permanent tool, it shrinks to a verification harness: you still crawl, but not to learn what you sell, only to check that what is published still matches the record, which is the drift loop pointed the other way, extraction as audit rather than extraction as source. If it is still teaching you new facts about your own catalog a year in, the workflow has not inverted. The specific tools below are one instance of a general pattern, so read the stages as the durable part and the products as interchangeable.

The stages. Crawl, extract, resolve, in that order, with the last two kept strictly separate.

Crawl. Pull clean page text away from the rendering. Any crawler that can isolate main content will do; the point is to hand the next stage meaning, not markup.

Extract. Pass the text to a model and require a single structured object back, nothing else. A useful starting schema per page:

  • primary_entity: the one thing the page is mainly about
  • secondary_entities: the important supporting entities
  • entity_type: Person, Organization, Product, Place, Concept, Event, and so on
  • aliases: common alternate names
  • confidence: a number between 0 and 1
  • evidence_paragraph: a passage copied verbatim from the page that supports the call
  • external_id: left blank at this stage, filled by resolution

An illustrative prompt: “Analyze the page content below. Return only valid JSON in the schema provided. Identify the single primary entity, list important secondary entities, specify the entity type, include common aliases, give a confidence between 0 and 1, and copy an evidence paragraph directly from the page. If you are not certain of an external identifier, leave it null rather than guessing.” Structured-output or function-calling modes enforce the schema more reliably than free-form prompting and are worth using where available.

Resolve. This is the stage people skip, and it is what separates a private island from a recognized entity. Take the extracted entity and look it up in an external authority, Wikidata being the obvious first one, to retrieve the canonical identifier, then write that identifier back into the record. Do not trust the model’s memory for the identifier. A model may recall many identifiers from training and still return the wrong one with full confidence, so the lookup, not the recall, is the source of truth for identity.

Why are extraction and resolution kept separate? Extraction proposes what a page is about. Resolution disposes of which canonical thing that is. Collapsing them into one model call reintroduces exactly the unreliability the separation exists to remove, because you lose the independent check that the entity you named is the entity the wider graph already knows.

Reading the confidence score. It is the model’s self-report, useful only for triage. Route low-confidence and conflicting records to human review; never treat a high number as verification. Real accuracy comes from the resolution step and from agreement across re-runs over time.

The shape of the loop.

crawl clean text
   -> extract structured candidate record (with confidence + evidence)
   -> resolve entity against external authority -> write back canonical ID
   -> store / augment / validate
   -> emit to formats
   -> re-run later and diff against the record to catch drift

For large crawls, an off-the-shelf instance of this is Screaming Frog’s AI integration with an OpenAI key for the extraction stage, a Wikidata lookup for resolution, and export to a sheet, a warehouse, or whatever holds the record. The tools will change. The four moves, isolate the text, propose the entity, confirm it against an authority, and keep confidence as a flag rather than a fact, are the part worth keeping.

Related Posts