Part 1: Introduction

The Machine’s Job Changed. The Publisher’s Must Change With It.

For more than two decades, web publishing developed around a relatively stable division of labor.

Publishers created documents.

Search engines discovered, indexed, and ranked them.

Humans clicked the results, read the documents, and performed much of the remaining interpretation themselves.

The publishing model reflected that arrangement:

Publisher
    ↓
Document
    ↓
Search Engine
    ↓
Ranking
    ↓
Human
    ↓
Interpretation

Search engine optimization evolved around improving performance within that system. Keywords helped establish topical relevance. Links helped establish authority and discovery. Structured data helped describe certain entities and page features. Information architecture helped crawlers and humans navigate the site.

That model still exists.

But it is no longer the only model publishers must serve.

The machine’s job changed.

From Finding Documents to Producing Answers

Search systems increasingly operate alongside answer engines, large language models, retrieval systems, and agents capable of doing more than locating documents.

These systems may attempt to:

• identify entities;
• extract factual claims;
• combine information from multiple resources;
• compare alternatives;
• interpret relationships;
• apply geographic or temporal context;
• resolve identifiers;
• summarize source material;
• and synthesize an answer directly for the user.

The machine is no longer operating only between the publisher and the document.

It increasingly operates between the document and the answer.

Publisher
        ↓
   ┌────┴────┐
   ↓         ↓
Search     Answer Engine
   ↓         ↓
Rank       Retrieve
   ↓       Interpret
Document   Compare
   ↓       Resolve
Human      Synthesize
             ↓
           Answer
             ↓
           Human

This does not mean search ranking is dead.

It means ranking is no longer the entire visibility problem.

The Publisher’s Old Output Was a Document

Traditional web publishing assumes that a great deal of meaning can remain implicit because a human reader will reconstruct it.

Consider a table containing:

Plan Name        Monthly Premium
Example PPO      $18.50

A human reader may infer from the page that:

• the value is a monthly premium;
• the premium belongs to the named plan;
• the plan applies within the geography described by the page;
• the value applies to the current plan year;
• the source citation beneath the table supports the value;
• and the plan name links to another resource containing additional information.

Some of those relationships may exist explicitly in the underlying data system.

But once published, much of their meaning may be communicated only through presentation.

Headings establish context.

Tables establish visual relationships.

Navigation establishes hierarchy.

URLs imply identity.

Citations imply provenance.

Labels imply definitions.

Proximity implies association.

Humans are remarkably good at reconstructing those signals into meaning.

When machines primarily returned documents to humans, that was often enough.

When machines begin producing answers themselves, the weakness becomes visible.

A Correct Fact Can Still Produce a Wrong Answer

Suppose a machine retrieves this fact:

monthly_premium = 18.50 USD

The value may be completely accurate.

But accuracy alone does not make it an applicable answer.

The machine may still need to know:

What entity does this describe?

Which plan?

Which segment?

Which geography?

Which year?

Which source?

Was the value observed or derived?

Under what conditions does it apply?

Now suppose the same plan has multiple geographic segments:

Plan
├── Segment A
│   ├── appliesIn → County X
│   └── monthly_premium = 18.50 USD
│
└── Segment B
    ├── appliesIn → County Y
    └── monthly_premium = 32.00 USD

Both premiums may be correct.

Retrieving either value successfully does not answer the question:

Which premium applies here?

That requires more than retrieval.

It requires identity, relationships, context, and resolution.

The Final-Mile Publishing Problem

This exposes an unusual failure in conventional digital publishing.

The publisher often already knows the missing structure.

The database knows:

Plan
→ Segment
→ Premium

The geographic data knows:

Segment
→ County

The source pipeline knows:

Premium
→ Source Dataset
→ Applicable Year

The application knows:

Plan
→ Canonical Resource

The publisher may therefore possess everything required to interpret the fact correctly.

Yet conventional publishing can discard much of that structure at the final mile and produce a human-facing document from which machines must reconstruct it.

We publish the answer’s ingredients.

Then we ask the machine to rediscover the recipe.

From Retrieval to Resolution

The first version of this paper described the emerging problem primarily through retrievability.

That was incomplete.

Retrieval remains important. A machine cannot use knowledge it cannot locate or access.

But retrieval answers only one question:

What information might be relevant?

Answer generation frequently requires another:

Which information actually applies?

That distinction separates retrieval from resolution.

Retrieval
→ finds candidate information

Resolution
→ determines what the candidates represent,
  how they relate,
  which context governs them,
  and which knowledge applies

A machine may retrieve five correct facts and still need to resolve which one answers the question.

This is why the emerging publishing problem cannot be reduced to ranking, retrieval, or machine memory.

It is increasingly a problem of knowledge representation.

What the Publisher Controls

The original Memory-First Publishing framework asked questions such as:

• Will the machine remember this entity?
• Can the publisher reinforce its retrieval?
• Can repeated semantic exposure condition future answers?

Those questions arose from observable behavior, but they extend into systems the publisher does not control.

A publisher does not control:

• what a language model stores internally;
• what a search engine indexes;
• what an answer engine retrieves;
• how a model ranks competing evidence;
• what a system chooses to cite;
• or what a machine decides to trust.

The publisher controls something upstream of all of them:

what the publisher publishes.

And publishers frequently know considerably more than their human-facing documents explicitly represent.

They know identity.

They know provenance.

They know relationships.

They know definitions.

They know derivations.

They know collections.

They know applicability.

They often know the resolution paths connecting one information object to another.

The 2026 framework begins there.

Two-Tier Publishing

The emerging model does not replace conventional web publishing.

It adds a second responsibility.

ONE RESOURCE

Human-Facing Representation
│
├── prose
├── tables
├── charts
├── navigation
├── interaction
└── presentation


Machine-Facing Representation
│
├── identity
├── assertions
├── provenance
├── relationships
├── applicability
├── collections
└── resolution structure

The human representation explains.

The machine representation makes the publisher’s known semantic structure explicit.

They are not competing versions of the truth.

They are two representations of the same underlying knowledge for two different kinds of interpretation.

From Memory-First Publishing to WebMEM®

Memory-First Publishing began as an attempt to understand how publishing should change when machines increasingly mediate discovery and answers.

That original work produced several durable ideas:

• Semantic Data Templates;
• modular machine-facing knowledge fragments;
• structured factual bindings;
• explicit provenance;
• defined terminology;
• entity identity;
• cross-object relationships;
• and machine-facing publication within ordinary HTML.

Production implementation exposed the missing architecture around those ideas.

The current WebMEM Protocol formalizes that architecture through:

• Semantic Data Templates for page-level knowledge representation;
• Fragment Classes for declaring the semantic role of modular knowledge objects;
• Facts and Assertions for representing what the publisher states;
• Identity for preserving what the knowledge is about;
• Provenance for preserving where the knowledge came from;
• Relationships for preserving how identifiable objects connect;
• Resolution for preserving the structure required to determine applicability;
• Resolvers for publishing recurring resolution spaces;
• Serialization for carrying the knowledge model into machine-readable syntax;
• and Conformance for determining whether the applicable semantic contract survived publication.

This changes the central publishing question.

It is no longer only:

“How do I get this page ranked?”

Nor is it:

“How do I make the machine remember me?”

It becomes:

“What does the machine need to know about this knowledge that the publisher already knows but the document leaves implicit?”

That is the foundation of publisher-side knowledge engineering for answer engines.

The New Publishing Responsibility

The answer-engine web does not eliminate SEO.

It expands the publisher’s responsibility beyond it.

Search still needs discoverable documents.

Humans still need understandable pages.

But machines producing answers increasingly need recoverable knowledge structure.

The publisher now serves both.

Publish for Humans
        +
Represent Knowledge for Machines

The objective is not to tell machines what to think.

It is to stop unnecessarily forcing them to infer what the publisher already knows.

The machine’s job changed.

Now the publisher’s must change with it.