• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

The Visibility Code™

Knowledge Engineering for Answer Engines

  • Visibility Code
  • Publisher’s Job Description
  • About

Prologue: What Search Left Behind

We were taught to optimize for ranking.

  • Add keywords.
  • Get backlinks.
  • Mark up your schema.
  • Build authority.
  • Make the page easier to find.

For more than twenty years, that made sense.

The publisher had a fairly clear job.

Publish a document
        ↓
Help the search engine understand it
        ↓
Get the document ranked
        ↓
Get the human to click

The machine’s job was discovery.

The human’s job was interpretation.

Then the machine’s job changed.

Search did not disappear.

It split.

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

One machine still helps people find documents.

Another increasingly attempts to answer the question itself.

That is not a small change in interface.

It is a change in the division of labor between publisher, machine, and reader.

And nobody updated the publisher’s job description.


Traditional web publishing assumes that much of the meaning of a document will be reconstructed by a human.

A human can look at a page and understand that:

  • this table describes this product;
  • this premium applies to this plan;
  • this citation supports this statement;
  • this county determines which options are available;
  • this number was calculated rather than copied from the source;
  • this definition governs how a term is being used;
  • and this link leads to the canonical resource for the thing being discussed.

Much of that meaning is carried through presentation.

Headings. Tables. Labels. Navigation. Page hierarchy. URL structure. Citations. Proximity. Visual grouping. Prior knowledge.

Humans are extraordinarily good at reconstructing meaning from those signals.

Machines can reconstruct some of it, too.

But now we are asking machines to do something fundamentally different.

We are asking them to answer.


That changes the publishing problem.

A machine producing an answer may need to determine:

  • What entity is this?
  • What does this identifier identify?
  • Which facts belong to which entity?
  • Where did those facts come from?
  • Were they observed or derived?
  • How do these entities relate?
  • Which relationships matter to this question?
  • Which geography applies?
  • Which time period applies?
  • Which of several correct values is applicable?
  • Where does resolution continue?

Those are not merely retrieval problems.

They are knowledge representation problems.

And increasingly, they are resolution problems.


Consider a simple factual value:

monthly_premium = 18.50 USD

The value may be completely correct.

But correct for what?

Which plan?
Which segment?
Which geography?
Which plan year?
Which source?
Observed or derived?

A machine can retrieve the correct number and still produce the wrong answer.

That is the problem traditional publishing was never designed to solve.


The old publishing question was:

“How do I help the machine find my page?”

The emerging publishing question is:

“How do I help the machine correctly interpret the knowledge associated with my page?”

That requires a different kind of publishing infrastructure.

Not because keywords stopped mattering.

Not because links stopped mattering.

Not because search stopped ranking documents.

And not because structured data stopped being useful.

It requires different infrastructure because machines are now being asked to perform a job the original publishing model largely left to humans.


The first version of this paper, published in July 2025, called the response Memory-First Publishing and Optimization.

At the time, we described the problem through the language of machine memory, retrieval conditioning, semantic reinforcement, and trust.

That language captured an observable change in the information environment, but it reached too far into mechanisms controlled by proprietary machine systems.

A publisher does not control what a language model remembers.

A publisher does not control what an answer engine retrieves.

A publisher does not control what a search engine ranks.

A publisher does not control what a machine decides to trust.

But the publisher controls something much more fundamental:

the representation it publishes.


A publisher knows things about its information that may never be stated explicitly in the human-facing document.

The publisher may know:

  • the canonical identity of the subject;
  • the identity of the source dataset;
  • which fields came from which source;
  • which values were calculated;
  • how entities relate;
  • which objects belong to a collection;
  • which geography governs applicability;
  • which time period governs applicability;
  • and which resource represents the canonical continuation of the knowledge.

Databases know this.

Data pipelines know this.

Applications know this.

Routing systems know this.

Publishers know this.

Yet conventional publishing frequently throws much of that structure away at the final mile and publishes a document designed primarily for human interpretation.

Then we ask machines to reconstruct the structure.


This paper proposes a different approach.

Publish the structure.

If the publisher knows the identity, publish the identity.

If the publisher knows the provenance, publish the provenance.

If the publisher knows the relationship, publish the relationship.

If the publisher knows the applicability, publish the applicability.

If the publisher knows the resolution path, publish the resolution structure.

Do not force every consuming system to rediscover what the publisher already knows.


This is the foundation of the current WebMEM® Protocol.

WebMEM separates two publishing responsibilities:

Human-Facing Publishing
→ documents
→ explanation
→ presentation
→ navigation
→ experience


Machine-Facing Publishing
→ identity
→ assertions
→ provenance
→ relationships
→ applicability
→ resolution structure

They describe the same underlying knowledge.

They serve different interpreters.

This is not a replacement for the human web.

It is the second layer the answer-engine web now requires.


The goal is not to condition machine memory.

The goal is not to manipulate retrieval.

The goal is not to tell machines what they must trust.

The goal is much simpler:

Give machines a representation of the publisher’s knowledge that does not unnecessarily discard the meaning the publisher already possesses.

That means moving:

  • from documents → to documents plus knowledge;
  • from markup → to semantic representation;
  • from isolated facts → to identified assertions;
  • from citations → to provenance;
  • from proximity → to relationships;
  • from retrieval → to resolution;
  • and from one publishing surface → to two.

Search taught publishers how to make documents discoverable.

Answer engines are forcing publishers to learn how to make knowledge resolvable.

The machine’s job changed.

Now the publisher’s must change with it.

Primary Sidebar

Table of Contents

Prologue: What Search Left Behind
  1. Introduction: From Ranking to Machine Resolution
  2. The Machine Knowledge Layer
  3. The WebMEM Protocol
  4. Semantic Data Templates
  5. Retrieval Interfaces and Resolution
  6. Provenance and Knowledge Governance
  7. Measuring Machine Reflection
  8. Cross-Surface Semantic Consistency
  9. Publisher Feedback Loops
  10. Query-to-Resolution Mapping
  11. Representation Optimization
  12. Knowledge Resolution Across Domains
  13. Consumer Independence
  14. Temporal Knowledge Integrity
  15. Glossary Integrity Index
  16. Implementation Architecture
  17. Misinformation Resilience Infrastructure
  18. The Future of AI Visibility
  19. Protocol Interoperability and Machine Knowledge Exchange
Epilogue: A Trust Layer for the Machine Age

Copyright © 2026 · David W Bynon · Log in