WebMEM™

The Protocol for Structuring, Delivering, and Conditioning Trust-Scored AI Memory on the Open Web

Part 2: The Machine Knowledge Layer

Why Human-Readable Documents Are No Longer Enough

The web was built around documents.

Documents remain essential. They provide explanation, narrative, presentation, navigation, context, and the human experience through which published information is understood.

But answer-producing machines increasingly need something the document model was never designed to provide explicitly:

a recoverable representation of the knowledge behind the document.

This distinction creates what we call the Machine Knowledge Layer.

Web Resource
│
├── Human-Facing Document
│   └── designed for human interpretation
│
└── Machine Knowledge Layer
    └── designed to preserve explicit semantic structure

The two layers describe the same underlying information.

They solve different interpretation problems.

The Document Is a Presentation of Knowledge

A conventional web page communicates far more than the literal words it contains.

Meaning is distributed across:

  • headings;
  • paragraphs;
  • tables;
  • labels;
  • citations;
  • navigation;
  • links;
  • visual grouping;
  • page hierarchy;
  • URL structure;
  • and the reader’s existing understanding of the subject.

A human reader can often reconstruct the intended semantics from those signals without requiring the publisher to state every relationship explicitly.

Consider:

2026 Example PPO
Monthly Premium: $18.50
Maximum Out-of-Pocket: $4,900

A human looking at the surrounding page may understand that:

  • $18.50 is the monthly premium;
  • $4,900 is the maximum out-of-pocket amount;
  • both values describe Example PPO;
  • the values apply to the 2026 plan year;
  • the plan is available in the geography represented by the page;
  • and a citation elsewhere on the page identifies the source.

But much of that knowledge may exist only implicitly in the presentation.

The underlying publishing system may know considerably more.

Entity:
plan:H5521-290-0

Plan Year:
2026

monthly_premium:
18.50 USD

maximum_out_of_pocket:
4900 USD

Source:
CMS PBP

Geographic Applicability:
county:04015

The database knows the structure.

The data pipeline knows the structure.

The application knows the structure.

The human page presents the result.

The Machine Knowledge Layer preserves the structure.

Documents Are Not Knowledge Models

A document can contain correct information without explicitly representing the semantic relationships required to interpret that information outside the document’s presentation context.

This distinction becomes important when a machine extracts, combines, compares, or resolves knowledge across resources.

For example:

Page A:
Plan H5521-290
Premium: $18.50

Page B:
Plan H5521-290
Premium: $32.00

The values appear contradictory.

But the underlying knowledge may actually be:

plan:H5521-290
│
├── hasSegment
│   └── segment:H5521-290-001
│       ├── appliesIn → county:X
│       └── monthly_premium → 18.50 USD
│
└── hasSegment
    └── segment:H5521-290-002
        ├── appliesIn → county:Y
        └── monthly_premium → 32.00 USD

The documents contain the values.

The knowledge model explains why both values can be true.

Human-readable content and machine-recoverable knowledge are not the same thing.

Schema Is Not the Knowledge Layer

Structured data already plays an important role on the web.

Schema.org, JSON-LD, Microdata, RDF, and related approaches allow publishers to describe entities, datasets, properties, and relationships using established vocabularies and serialization methods.

WebMEM does not replace those systems.

It addresses a different problem.

Schema.org is especially useful for declaring recognizable resource and entity types:

WebPage
Dataset
Organization
Person
Product
Article
DefinedTerm

But a publisher may need to represent a more detailed domain-specific knowledge structure than an external general-purpose vocabulary conveniently expresses.

For example:

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

Segment
→ monthlyPremium
→ 18.50 USD

Premium Assertion
→ sourcedFrom
→ CMS PBP 2026

The issue is not that Schema.org has failed.

The issue is that resource declaration and publisher-side knowledge representation are different jobs.

The current WebMEM architecture uses that distinction deliberately.

Schema.org Dataset JSON-LD
        ↓
Declares the page-level dataset

WebMEM Semantic Data Template
        ↓
Represents the internal machine-facing knowledge

The two can coexist on the same resource and share a stable identity.

Schema can help declare what the machine-facing dataset is.

WebMEM represents what the publisher knows within it.

From Memory Objects to Knowledge Objects

The original 2025 framework described machine-facing fragments as memory objects.

That terminology reflected an early attempt to explain why discrete, structured, entity-scoped information appeared increasingly important in AI-mediated retrieval.

The underlying observation remains useful.

The mechanism requires correction.

A publisher cannot determine whether a proprietary AI system will store a representation in long-term memory, incorporate it into model parameters, retain it in an external index, retrieve it dynamically, cache it temporarily, or ignore it entirely.

Those are consumer-side implementation decisions.

The publisher can, however, construct a stable machine-facing knowledge object.

That object can explicitly preserve:

  • what kind of knowledge it represents;
  • what entity it describes;
  • what the publisher asserts;
  • where the knowledge came from;
  • whether values were observed or derived;
  • how identified objects relate;
  • what context governs applicability;
  • and how the knowledge participates in a larger information structure.

This is the role now performed by WebMEM Fragments.

2025

Memory Object
→ intended to influence machine memory


2026

Knowledge Object
→ preserves publisher-known semantics
→ made available for machine interpretation

The distinction establishes an important architectural boundary.

WebMEM defines what the publisher publishes. It does not claim to define what the machine remembers.

The Structured Retrieval Surface Evolves

The original framework introduced the Structured Retrieval Surface as a format-independent layer through which machine-readable fragments could be exposed for retrieval.

That observation also survives, but its purpose is broader than retrieval.

A machine may need the represented knowledge for:

  • retrieval;
  • entity interpretation;
  • comparison;
  • attribution;
  • relationship traversal;
  • applicability evaluation;
  • resolution;
  • citation;
  • or synthesis.

The current architecture therefore treats the Structured Retrieval Surface as part of a broader Machine Knowledge Layer.

Its purpose is not to guarantee retrieval.

Its purpose is to expose semantic structure that would otherwise remain implicit or distributed across publisher systems.

The Semantic Data Template

The page-level representation of the Machine Knowledge Layer is the Semantic Data Template (SDT).

An SDT organizes the machine-facing knowledge associated with a web resource.

Conceptually:

Web Resource
│
├── Human-Facing Representation
│
└── Machine Knowledge Layer
    │
    └── Semantic Data Template
        │
        ├── Fragment
        ├── Fragment
        ├── Fragment
        └── Fragment

The SDT is not a second human document.

It is a structured representation of the knowledge the publisher chooses to expose for machine interpretation.

The fragments within it may represent different semantic roles:

IdentityFragment
→ what is this?

DataFragment
→ what source-observed facts are asserted?

DerivedStatsFragment
→ what has the publisher calculated?

IndexFragment
→ what belongs to this collection?

DefinedTermFragment
→ what does this term mean?

PolicyFragment
→ what rule applies?

ProcedureFragment
→ what process is represented?

Other Fragment Classes represent other kinds of knowledge.

The class tells the machine what semantic role the fragment performs.

Atomic Facts Need Context

The 2025 framework correctly recognized the value of exposing individual facts as discrete machine-readable units.

But atomicity alone is insufficient.

Consider:

4900

It becomes more useful as:

maximum_out_of_pocket = 4900 USD

More useful still:

subject:
segment:H5521-290-001

maximum_out_of_pocket:
4900 USD

plan_year:
2026

source:
CMS PBP

And if applicability matters:

segment:H5521-290-001
→ appliesIn
→ county:04015

The fact did not become more accurate as these layers were added.

It became more interpretable.

This distinction is fundamental to the Machine Knowledge Layer.

The objective is not merely to publish machine-readable values. It is to preserve enough semantic context for those values to remain meaningful when separated from the human document.

Provenance Travels With Knowledge

Machine-facing knowledge becomes particularly fragile when factual values survive extraction but their evidentiary context does not.

For example:

maximum_out_of_pocket = 4900 USD

may survive perfectly while the following information disappears:

source:
CMS PBP 2026

publisher:
Example Publisher

subject:
segment:H5521-290-001

applicable_plan_year:
2026

The number survives.

The evidence surrounding the number does not.

The Machine Knowledge Layer therefore treats provenance as part of the knowledge architecture rather than as a decorative citation attached after publication.

Provenance provides the recoverable lineage connecting published knowledge to the sources, transformations, derivations, and responsible actors through which that knowledge came to exist.

Relationships Travel With Knowledge

Facts also become fragile when relationships are left behind.

Consider:

H5521
H5521-290
H5521-290-001
04015

These identifiers become substantially more useful when the publisher exposes what it already knows:

contract:H5521
→ hasPlan
→ plan:H5521-290

plan:H5521-290
→ hasSegment
→ segment:H5521-290-001

segment:H5521-290-001
→ appliesIn
→ county:04015

The machine no longer needs to infer the relationships from naming conventions, shared strings, URL patterns, or document proximity.

The publisher has represented the connections explicitly.

The Machine Knowledge Layer Is a Publishing Target

The 2025 paper concluded that the Memory Layer should become a deliberate design target.

The 2026 revision preserves that conclusion but changes the object of design.

The publisher should not attempt to design the internal memory state of an external AI system.

The publisher should deliberately design the machine-facing representation under its own control.

That representation should be:

  • Identifiable: the subjects and knowledge objects can be distinguished reliably;
  • Typed: different kinds of knowledge retain their semantic roles;
  • Factual: assertions preserve canonical machine values and context;
  • Provenanced: material knowledge retains recoverable lineage;
  • Relational: known connections among objects are represented explicitly;
  • Contextual: geographic, temporal, jurisdictional, and other applicability conditions remain attached where needed;
  • Composable: modular knowledge objects can participate in a coherent page-level representation;
  • Resolvable: the representation preserves distinctions necessary to determine which knowledge applies;
  • Serializable: the conceptual model can be represented in concrete machine-readable syntax;
  • and Conformant: required semantics survive publication.

This produces a very different objective from the original Memory Layer:

Not:

Publisher
→ structures content
→ conditions machine memory
→ persistent recall


But:

Publisher
→ structures known knowledge
→ publishes machine-facing representation
→ consuming system may retrieve,
  interpret, compare, resolve,
  cite, or synthesize it

The New Boundary

The Machine Knowledge Layer ends where the publisher’s control ends.

PUBLISHER CONTROL

Source Data
    ↓
Transformation
    ↓
Knowledge Model
    ↓
Machine Knowledge Layer
    ↓
Serialization
    ↓
Published Resource

────────────────────────────
      WEBMEM BOUNDARY
────────────────────────────

CONSUMER CONTROL

Discovery
Retrieval
Indexing
Storage
Ranking
Reasoning
Trust Evaluation
Citation
Synthesis
Memory

This boundary makes the current framework both narrower and stronger.

WebMEM does not need to know whether a consuming system stores the knowledge in a vector index, a knowledge graph, a retrieval cache, a model context window, model parameters, or nowhere at all.

Those architectures can change.

The publisher-side requirement remains.

Represent the knowledge without unnecessarily discarding the meaning you already know.

From Memory to Knowledge

The first version of this paper asked publishers to design for memory.

The revised framework asks publishers to design for semantic recoverability.

Can the machine recover:

  • what the thing is;
  • what is being asserted about it;
  • where the assertion came from;
  • how the thing relates to other things;
  • where and when the knowledge applies;
  • and what additional structure is required to resolve the information need?

If those semantics exist in the publisher’s systems but disappear when the information reaches the web page, the publishing process has lost knowledge.

The Machine Knowledge Layer exists to prevent that loss.

The goal is no longer to make the machine remember the page.

The goal is to make the publisher’s knowledge recoverable from it.