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

WebMEM™

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

  • Visibility Code
  • WebMEM Protocol v2
  • v1 (depreciated)
    • SDT Specification
    • Entity Dataset Bridge
    • WebMEM SemanticMap
    • WebMEM MapPointer
    • Digest Endpoint Specification
    • ProvenanceMeta Specification
    • AI Retrieval Feedback Loop Specification
    • Semantic Feedback Interface (SFI) Specification
    • Glossary Term Protocol (GTP) Specification
    • Examples
  • RFC
  • Glossary
  • About
    • WebMEM License and Usage Terms
    • Mission
    • Charter

WebMEM Protocol

WebMEM® Protocol
Location: /protocol/
Status: Current Draft
Last Updated: 2026-08-24


What Is the WebMEM Protocol?

The WebMEM Protocol is an open publishing framework for representing the knowledge associated with a web resource in a structured form designed for machine interpretation and resolution.

WebMEM complements the human-facing web with an explicit machine-facing knowledge representation.

A conventional web page communicates through prose, headings, tables, navigation, visual hierarchy, and other presentation structures. Human readers use those signals to infer identity, context, relationships, source, applicability, and meaning.

Machines may encounter the same information without reliably reconstructing those relationships.

WebMEM gives publishers a way to state that knowledge explicitly.

The protocol defines:

  • how the machine-facing knowledge associated with a resource is organized;
  • how different kinds of knowledge are represented through Fragment Classes;
  • how factual assertions preserve the context necessary for correct interpretation;
  • how entities and identifiers maintain stable identity;
  • how provenance preserves source and derivation lineage;
  • how relationships connect knowledge objects;
  • how machines can move from identifiers or contexts toward applicable information objects through resolution;
  • and how the conceptual knowledge model is serialized for publication.

WebMEM is publisher-side knowledge infrastructure for the machine-mediated web.


The Publishing Problem

The web was built primarily as a document system.

Publishers create pages. Pages contain information. Search systems index those pages and traditionally return links that allow people to visit them.

Answer engines change that interaction.

A machine may now need to extract, interpret, combine, compare, and resolve information before the user ever visits the source page.

That creates a different publishing problem.

The question is no longer only:

Can a machine find this page?

It is also:

Can a machine determine what the publisher knows, what each assertion means, what entity it describes, where it came from, when and where it applies, how it relates to other knowledge, and what must be resolved before it can be used safely?

WebMEM addresses that second problem.


Dual Publishing

WebMEM treats a modern web resource as capable of serving two audiences simultaneously.

The first is the human reader.

The second is the machine consuming the publisher’s knowledge.

The relationship is:

Web Resource
│
├── Human-Facing Representation
│   ├── prose
│   ├── headings
│   ├── tables
│   ├── navigation
│   ├── citations
│   └── interactive presentation
│
└── Machine-Facing Representation
    └── Semantic Data Template
        ├── Fragment
        ├── Fragment
        └── Fragment

The two representations describe the same underlying subject matter but are optimized for different consumers.

The human-facing representation remains free to communicate naturally.

The machine-facing representation makes identity, facts, context, relationships, provenance, applicability, and other semantic structures explicit.

One resource. One underlying body of knowledge. Two representations optimized for different consumers.


Protocol Architecture

The core WebMEM architecture can be expressed as:

Web Resource
│
├── Dataset Declaration
│   └── Schema.org Dataset JSON-LD
│
└── Semantic Data Template
    │
    ├── WebMEM Fragment
    │   ├── Assertions
    │   └── Structures
    │
    ├── WebMEM Fragment
    │   ├── Assertions
    │   └── Structures
    │
    └── WebMEM Fragment
        ├── Assertions
        └── Structures

Cross-Cutting Semantics
├── Identity
├── Provenance
├── Relationships
└── Resolution

Publication
└── Serialization
    └── HTML-in-HTML

Each layer has a different responsibility.

The protocol deliberately separates the conceptual knowledge model from the syntax used to publish it.

Read the WebMEM Architecture →


Semantic Data Template

The Semantic Data Template (SDT) is the page-level machine knowledge representation defined by WebMEM.

An SDT organizes the structured knowledge associated with a web resource into a coherent collection of WebMEM fragments.

The SDT is not itself a single fact, fragment, dataset source, or serialization format.

It is the semantic composition boundary for the machine-facing knowledge associated with the resource.

Conceptually:

Web Resource
└── Semantic Data Template
    ├── Fragment
    ├── Fragment
    └── Fragment

An SDT may establish shared resource context while individual fragments preserve their own subjects, provenance, semantic roles, and applicability where necessary.

Read the Semantic Data Template specification →


WebMEM Fragments

A WebMEM fragment is a modular knowledge object within an SDT.

Each fragment declares a Fragment Class that establishes the semantic role of the knowledge represented by that fragment.

The current protocol defines 15 Fragment Classes:

Fragment Class Semantic Role
DataFragment Source-observed factual knowledge.
DerivedStatsFragment Calculated, aggregated, or otherwise derived knowledge.
IndexFragment Membership within a defined collection.
DefinedTermFragment The canonical meaning of an individual term.
FAQFragment Structured question-and-answer knowledge.
MetaFragment Metadata about an information resource or dataset.
ExplainerFragment Structured explanatory knowledge.
DirectoryFragment A structured directory of identifiable entries.
EligibilityFragment Qualification criteria and eligibility logic.
ProcedureFragment Ordered procedural knowledge.
GlossaryFragment An organized glossary or semantic vocabulary.
PersonaFragment A contextual human model, archetype, or scenario.
PolicyFragment Governing policies, rules, conditions, and exceptions.
RecommendationFragment A publisher-defined recommendation and its basis.
IdentityFragment The canonical structured identity of an entity.

These Fragment Classes are not interchangeable containers.

The Fragment Class defines what kind of knowledge the publisher is communicating.

Read the WebMEM Fragments specification →


Facts and Assertions

Within fragments are the actual assertions and structures through which publisher knowledge is communicated.

A machine-readable value is not necessarily a meaningful factual assertion.

For example:

15.26

provides almost no usable meaning by itself.

Its meaning may require:

subject: Medicare Advantage plans
geography: Putnam County, Ohio
plan_year: 2026
predicate: average_monthly_premium
value: 15.26
unit: USD
population: applicable plans
derived: true
source: CMS source data

The value did not change.

The knowledge surrounding the value did.

WebMEM preserves that context without requiring every individual value to become an independent fragment or universal fact object.

The Fragment Class establishes the semantic role of the assertion. The SDT and fragment provide the identity, provenance, temporal, geographic, and other context necessary to interpret it.

Read Facts and Assertions →


SDT Composition

A web resource may require several different kinds of knowledge to represent its subject correctly.

For example:

County Medicare Resource
└── SDT
    ├── IdentityFragment
    │   └── county identity
    │
    ├── IndexFragment
    │   └── available plans
    │
    ├── DataFragment
    │   └── source-observed facts
    │
    ├── DerivedStatsFragment
    │   └── calculated market statistics
    │
    ├── MetaFragment
    │   └── source dataset metadata
    │
    └── DefinedTermFragment
        └── domain terminology

Each fragment performs its own semantic job.

The SDT composes those fragments into one coherent page-level representation.

Fragments organize coherent knowledge. SDTs compose coherent fragments.

Read SDT Composition →


Dataset Declaration

WebMEM may use Schema.org Dataset JSON-LD as the page-level discovery and declaration mechanism for an SDT.

The relationship is:

Web Resource
│
├── Dataset JSON-LD
│   └── declares and describes the machine-facing dataset
│
└── Semantic Data Template
    └── defines the knowledge represented by that dataset

The Dataset declaration and SDT may share a stable identity so that the declaration maps explicitly to the corresponding machine knowledge representation.

Schema.org Dataset does not define the internal semantics of WebMEM fragments.

Likewise, WebMEM does not need to recreate the general-purpose dataset declaration vocabulary already provided by Schema.org.

Schema.org declares the dataset. WebMEM defines its internal knowledge architecture.

Read Dataset Declaration and SDT Mapping →


Identity

Machine knowledge requires stable subjects.

WebMEM identity semantics distinguish among the web resource, Dataset, SDT, fragments, and the real or conceptual entities represented by the knowledge.

Identity also preserves distinctions among related entity levels.

For example:

Carrier
└── Contract
    └── Plan
        └── Segment

These entities may be related, but they are not interchangeable.

An assertion about a contract should not automatically be interpreted as an assertion about every plan. A segment-specific value should not automatically be generalized to the parent plan.

Stable identity provides the anchors necessary to preserve those distinctions.

Read the Identity specification →


Provenance

WebMEM provenance describes where published knowledge came from and how its evidentiary lineage should be understood.

Provenance may apply at different levels:

  • to an external source dataset;
  • to a MetaFragment describing that source;
  • to a fragment;
  • to an individual assertion;
  • to a derived calculation;
  • to a policy, procedure, definition, or recommendation;
  • or to another knowledge object represented within the SDT.

Source-observed knowledge and publisher-derived knowledge should remain distinguishable.

When different assertions originate from different sources, provenance should preserve those distinctions rather than flattening them into a generic page-level source statement.

Read the Provenance specification →


Relationships

Knowledge becomes substantially more useful when the relationships among its objects are explicit.

WebMEM relationships may connect:

  • entities to other entities;
  • fragments to their subjects;
  • facts to defined terms;
  • indexes to their members;
  • directory entries to canonical resources;
  • policies to eligibility requirements;
  • eligibility requirements to procedures;
  • recommendations to supporting knowledge;
  • source data to derived statistics;
  • identifiers to canonical entities;
  • and entities to resolvable resources.

Relationships allow machines to understand not only what objects exist, but how the publisher knows those objects fit together.

Read the Relationships specification →


Machine Resolution

Structured knowledge alone does not guarantee that the correct knowledge will be applied to a request.

Some information becomes usable only after another identity, context, relationship, or applicability condition has been resolved.

For example:

Plan ID
→ Plan Identity
→ Geographic Context
→ Applicable Segment
→ Applicable Benefit

or:

County
→ Available Plan Index
→ Plan
→ Canonical Plan Resource

or:

Program
→ Eligibility Criteria
→ Applicable Procedure
→ Application Resource

WebMEM calls this process resolution.

Resolution is the process of moving from an identifier, entity, context, or information need toward the specific knowledge object or resource required to answer or continue correctly.

The protocol does not require a consuming system to follow a particular reasoning path. It allows publishers to make known resolution structure explicit.

Read the WebMEM Resolution Model →


Resolvers

A resolver is a publisher-defined information structure designed to help machines move from a known entity, identifier, or context toward the applicable option space, related entities, or canonical resources.

Resolvers are especially useful where the initial identifier does not itself provide enough information to reach the correct answer.

Examples may include:

County
→ available Medicare plans

Contract ID
→ carrier
→ contract
→ plans
→ historical context

Formulary ID
→ formulary identity
→ applicable plans
→ formulary resources

A resolver may use IdentityFragments, IndexFragments, DirectoryFragments, DataFragments, relationships, and other WebMEM structures as part of its resolution surface.

The resolver is not a new Fragment Class. It is an architectural pattern for organizing knowledge around resolution.

Read the Resolvers specification →


Serialization

The WebMEM conceptual model is separate from the syntax used to publish it.

The SDT defines the machine knowledge representation.

Fragment Classes define semantic roles.

Identity, provenance, relationships, and resolution define how that knowledge is interpreted and connected.

Serialization defines how the resulting model is encoded.

This distinction allows the conceptual protocol to remain stable even if additional serialization methods are introduced in the future.

The knowledge model defines what the knowledge means. Serialization defines how that knowledge is represented for publication or exchange.

Read the Serialization specification →


HTML-in-HTML

The current WebMEM serialization uses HTML-in-HTML.

WebMEM structures are embedded within inert HTML <template> containers in the same HTML resource as the human-facing document.

A simplified representation may resemble:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem">

  <template
    data-webmem-fragment
    data-fragment-class="IdentityFragment"
    data-fragment-id="identity-example">

    ...

  </template>

  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-fragment-id="data-example">

    ...

  </template>

</template>

The <template> element provides an inert container for the machine-facing representation without requiring that representation to appear as visible page content.

HTML-in-HTML is the current serialization of the WebMEM knowledge model. It does not define the conceptual meaning of the SDT or its Fragment Classes.

Read the HTML-in-HTML Serialization specification →


WebMEM and Schema.org

WebMEM does not replace Schema.org.

The two systems address different layers of machine communication.

Schema.org provides broadly recognized vocabularies for describing web resources and entities.

WebMEM provides a publisher-side architecture for representing the structured knowledge associated with a resource, including distinctions among Fragment Classes, assertions, provenance, identity, relationships, applicability, and resolution.

One important point of interoperability is Schema.org Dataset.

A WebMEM-enabled resource may use Dataset JSON-LD to declare the existence and page-level characteristics of its machine-facing dataset while using the SDT to represent the internal knowledge structure of that dataset.

The relationship is:

Schema.org Dataset
  ↓
Dataset discovery and description

WebMEM SDT
  ↓
Knowledge representation

Fragment Classes
  ↓
Semantic organization

Assertions and Structures
  ↓
Publisher knowledge

Schema.org can describe the dataset. WebMEM describes what the publisher knows inside it.


WebMEM Does Not Require Machines to Behave a Particular Way

WebMEM is a publishing protocol.

It defines how publishers can represent knowledge. It does not prescribe how search engines, answer engines, language models, agents, crawlers, or other consuming systems must use that representation.

Publishing a WebMEM structure does not require a consuming system to:

  • index it;
  • retrieve it;
  • cite it;
  • rank it;
  • store it;
  • reason over it;
  • follow its relationships;
  • execute its logic;
  • follow a resolver path;
  • accept a recommendation;
  • or treat the publisher’s assertions as authoritative.

WebMEM provides explicit publisher-side knowledge structures that consuming systems may inspect and use according to their own capabilities, policies, and evaluation methods.


WebMEM Does Not Replace Source Authority

WebMEM allows a publisher to represent what it knows and where that knowledge came from.

It does not transform a publisher into the authority responsible for an external source.

For example, a publisher may represent knowledge derived from government data while preserving the government agency as the creator of the underlying source dataset.

Likewise, a publisher-derived statistic should remain distinguishable from a value directly published by the source authority.

WebMEM provenance exists in part to preserve these distinctions.

Structured publication does not change evidentiary origin.


WebMEM Does Not Make Truth Claims by Syntax

WebMEM makes publisher assertions explicit.

The presence of an assertion within an SDT does not make that assertion true merely because it is structured.

A consuming system may evaluate:

  • source authority;
  • provenance;
  • recency;
  • internal consistency;
  • corroborating sources;
  • publisher credibility;
  • methodology;
  • and other signals relevant to its own determination.

WebMEM’s role is to make the publisher’s knowledge claims and their context more explicit and inspectable.

It does not create truth through markup.


Core Design Principles

The current WebMEM Protocol is guided by several architectural principles.

1. Preserve Meaning

Machine-readable knowledge should preserve enough identity, context, scope, provenance, and relationships for its intended meaning to survive extraction from the human-facing presentation.

2. Preserve Semantic Differences

Facts, definitions, identities, policies, procedures, eligibility criteria, directories, recommendations, and other forms of knowledge perform different semantic jobs and should not be flattened into one generic object model.

3. Preserve Source Boundaries

Source-observed knowledge, normalized knowledge, publisher-derived knowledge, and editorial knowledge should remain distinguishable when those differences affect interpretation or authority.

4. Avoid Meaningless Atomization

The smallest technically separable value is not always the smallest useful knowledge object.

Related assertions should retain the shared context necessary to interpret them correctly.

5. Compose Rather Than Duplicate

Stable identities, definitions, provenance, and relationships should be reused across the knowledge structure when appropriate rather than redundantly recreated in every fragment.

6. Separate Knowledge From Serialization

The conceptual model defines what the knowledge means. Serialization defines how that model is encoded for publication.

7. Make Resolution Explicit

When correct interpretation depends on resolving another identifier, entity, geography, relationship, or applicability condition, the publisher should preserve that structure rather than publishing a convenient but misleading shortcut.


What WebMEM Is Not

WebMEM is not:

  • a replacement for the human-facing web;
  • a replacement for Schema.org;
  • a keyword or search-engine manipulation system;
  • a requirement to publish every value as an independent object;
  • a universal ontology for every domain;
  • a claim that structured assertions are automatically true;
  • a requirement that consuming systems index or use WebMEM;
  • a model-training interface;
  • a retrieval-feedback system;
  • a trust-scoring algorithm;
  • a semantic-digest endpoint protocol;
  • or a requirement for YAML, JSON-LD, Turtle, or another specific internal data syntax.

WebMEM is a protocol for publishing structured machine knowledge alongside the human-facing web.


Protocol Components

Component Purpose
Architecture Defines the overall WebMEM knowledge and publishing model.
Semantic Data Template Defines the page-level machine knowledge representation.
WebMEM Fragments Defines the modular Fragment Classes used within an SDT.
Provenance Defines source, lineage, derivation, and evidentiary relationships.
Identity Defines entity identity, identifiers, canonical identity, and scope.
Relationships Defines connections among entities, fragments, assertions, collections, and resources.
Resolution Defines how publisher knowledge represents paths from known context toward applicable information objects.
Resolvers Defines publisher-side resolver architecture and resolver profiles.
Serialization Defines how the conceptual WebMEM knowledge model is represented for publication or exchange.
Conformance Defines requirements for conforming WebMEM implementations and representations.

Protocol Hierarchy

/protocol/
│
├── /protocol/architecture/
│
├── /protocol/sdt/
│   ├── /protocol/sdt/anatomy/
│   ├── /protocol/sdt/assertions/
│   ├── /protocol/sdt/composition/
│   └── /protocol/sdt/dataset/
│
├── /protocol/fragments/
│   ├── /protocol/fragments/datafragment/
│   ├── /protocol/fragments/derivedstatsfragment/
│   ├── /protocol/fragments/indexfragment/
│   ├── /protocol/fragments/definedtermfragment/
│   ├── /protocol/fragments/faqfragment/
│   ├── /protocol/fragments/metafragment/
│   ├── /protocol/fragments/explainerfragment/
│   ├── /protocol/fragments/directoryfragment/
│   ├── /protocol/fragments/eligibilityfragment/
│   ├── /protocol/fragments/procedurefragment/
│   ├── /protocol/fragments/glossaryfragment/
│   ├── /protocol/fragments/personafragment/
│   ├── /protocol/fragments/policyfragment/
│   ├── /protocol/fragments/recommendationfragment/
│   └── /protocol/fragments/identityfragment/
│
├── /protocol/provenance/
├── /protocol/identity/
├── /protocol/relationships/
├── /protocol/resolution/
├── /protocol/resolvers/
│
├── /protocol/serialization/
│   └── /protocol/serialization/html/
│
└── /protocol/conformance/

Conformance

A conforming WebMEM representation must preserve the core distinctions established by the protocol.

At minimum, a conforming implementation must:

  • identify the Semantic Data Template associated with the resource;
  • represent one or more WebMEM fragments within that SDT;
  • identify the Fragment Class of each fragment;
  • preserve the semantic role defined by the applicable Fragment Class;
  • preserve enough identity and context to determine what represented knowledge describes;
  • preserve material temporal, geographic, jurisdictional, population, or other applicability context;
  • preserve provenance at the level necessary to distinguish materially different sources and derivations;
  • preserve relationships necessary to interpret how knowledge objects connect;
  • distinguish the conceptual knowledge model from its serialization;
  • and conform to the applicable serialization requirements.

Additional requirements may apply to individual Fragment Classes, resolver profiles, serialization methods, or other protocol components.

Read the Conformance specification →


Relationship to WebMEM 1.x

The current WebMEM Protocol is an architectural evolution of the original WebMEM 1.x specification.

WebMEM 1.x introduced many of the concepts retained by the current protocol, including Semantic Data Templates, Fragment Classes, provenance, glossary alignment, relationships, structured fields, and inert machine-facing publication within HTML.

The earlier architecture also included YAML-in-HTML, semantic digests, retrieval hints, trust scoring, feedback mechanisms, content-negotiated endpoints, multi-format exports, and other mechanisms closely tied to assumptions about machine retrieval and memory behavior.

The current protocol preserves the useful knowledge-modeling concepts while removing those mechanisms from the architectural core.

The principal clarifications are:

  • the SDT is the page-level machine knowledge representation;
  • WebMEM fragments are modular knowledge objects within the SDT;
  • Fragment Classes define the semantic roles of those objects;
  • assertions and structures communicate the actual knowledge within fragments;
  • identity, provenance, relationships, and resolution preserve the context necessary to interpret and traverse that knowledge;
  • Dataset JSON-LD provides a page-level dataset declaration and discovery layer;
  • and HTML-in-HTML is the current serialization rather than the definition of the knowledge model itself.

This separation makes the protocol simpler and more durable.

WebMEM now defines the publisher’s machine knowledge architecture independently from assumptions about how any particular search engine, answer engine, model, agent, or retrieval system will consume it.


Protocol Status

The WebMEM Protocol is a publicly available technical specification maintained by WebMEM. The current specification is published as a public draft and may be revised as the protocol continues to develop.

Development may include controlled implementation, validation, interoperability testing, technical research, and evaluation across real-world publishing environments.

Public availability of the specification is intended to support technical understanding, review, research, and interoperability evaluation. Publication does not, by itself, grant commercial implementation, patent, trademark, certification, conformance, software, or other rights beyond those expressly provided under the applicable WebMEM licensing terms.

Read the WebMEM License and Usage Terms →

Changes to serialization, conformance requirements, Fragment Classes, resolver profiles, or other protocol components should preserve the architectural distinction between:

Knowledge
→ Semantic Organization
→ Identity and Context
→ Relationships and Resolution
→ Serialization

The protocol is designed so that implementation methods can evolve while the underlying knowledge model remains stable.

Primary Sidebar

WebMEM® Protocol

  1. WebMEM Protocol
  2. WebMEM Architecture
  3. Semantic Data Template (SDT)
    • Anatomy of an SDT
    • Facts and Assertions
    • SDT Composition
    • Dataset Declaration and SDT Mapping
  4. WebMEM Fragments
    • DataFragment
    • DerivedStatsFragment
    • IndexFragment
    • DefinedTermFragment
    • FAQFragment
    • MetaFragment
    • ExplainerFragment
    • DirectoryFragment
    • EligibilityFragment
    • ProcedureFragment
    • GlossaryFragment
    • PersonaFragment
    • PolicyFragment
    • RecommendationFragment
    • IdentityFragment
  5. Provenance
  6. Identity
  7. Relationships
  8. WebMEM Resolution Model
  9. Resolvers
  10. Serialization
    • HTML-in-HTML Serialization
  11. Conformance

Copyright © 2026 · David W Bynon · Log in