Part 3: The WebMEM Protocol

A Publisher-Side Architecture for Machine-Readable Knowledge

The Machine Knowledge Layer establishes the publishing requirement.

The WebMEM® Protocol defines an architecture for implementing it.

WebMEM is a publisher-side knowledge representation protocol designed to allow the semantic structure associated with a web resource to be published alongside its human-facing representation.

Its purpose is not to control how machines retrieve, rank, remember, trust, or reason over information.

Its purpose is to preserve knowledge that publishers already possess but conventional document publishing frequently leaves implicit.

That knowledge may include:

• what entities are being described;
• what the publisher asserts about them;
• what kind of knowledge each assertion represents;
• where the knowledge came from;
• which values were observed and which were derived;
• how identifiable objects relate;
• what geographic, temporal, jurisdictional, or other context governs applicability;
• which objects belong to a collection or option space;
• and where resolution can continue.

WebMEM organizes those concerns into a layered architecture rather than attempting to encode all of them within one universal object.

Web Resource
│
├── Human-Facing Representation
│
└── Machine-Facing Representation
    │
    ├── Dataset Declaration
    │
    └── Semantic Data Template
        │
        ├── Fragment
        ├── Fragment
        ├── Fragment
        └── Fragment

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

Publication Layer
├── Serialization
└── Conformance

This architecture is the current WebMEM Protocol.

3.1 From Semantic Digests to Semantic Data Templates

The original 2025 WebMEM framework centered on a structure called the Semantic Digest.

A Semantic Digest attempted to package several machine-facing concerns into a single entity-scoped object:

• identity;
• structured factual fields;
• defined terminology;
• provenance;
• related knowledge;
• canonical resource references;
• and multiple machine-readable serializations.

The concept proved useful because it exposed a real publishing need: machines benefit when knowledge is represented in discrete, identifiable, provenance-bearing structures rather than left entirely inside human-facing documents.

Production implementation also exposed a weakness in the Digest model.

The Semantic Digest was doing too many jobs.

It simultaneously acted as:

page-level dataset
+
entity container
+
knowledge fragment
+
provenance package
+
glossary container
+
retrieval object
+
serialization bundle
+
endpoint

Those concerns do not always share the same scope.

A single web resource may describe multiple entities.

Different facts may come from different datasets.

Derived values may have different provenance from source-observed values.

Several fragments may describe the same entity while performing different semantic roles.

Relationships may connect entities represented in different fragments or different resources.

And the machine-facing representation does not need to be identical to its transport or serialization format.

The current WebMEM architecture separates those responsibilities.

The page-level machine representation is now the Semantic Data Template (SDT).

The modular knowledge objects inside it are WebMEM Fragments.

Semantic Data Template
│
├── Fragment
├── Fragment
├── Fragment
└── Fragment

The SDT provides composition.

The fragments provide semantic modularity.

Identity, provenance, relationships, assertions, and resolution provide the cross-cutting semantics required to interpret them correctly.

3.2 The Semantic Data Template

A Semantic Data Template is the page-level machine-facing representation of the knowledge associated with a web resource.

The SDT answers:

What machine-readable knowledge is this resource publishing?

It does not require all of the knowledge on the page to describe one entity.

Instead, it provides a coherent boundary within which multiple related knowledge objects can participate.

For example:

County Resource
│
└── SDT
    │
    ├── IdentityFragment
    │   └── County Identity
    │
    ├── IndexFragment
    │   └── Available Plans
    │
    ├── DataFragment
    │   └── Source-Observed Market Data
    │
    ├── DerivedStatsFragment
    │   └── Publisher-Derived Statistics
    │
    └── MetaFragment
        └── Source Dataset Metadata

The SDT is therefore not simply a block of structured fields.

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

3.3 Fragment Classes

Knowledge objects do not all perform the same semantic job.

A factual observation is not the same kind of knowledge as a definition.

A definition is not a policy.

A policy is not a procedure.

A calculated statistic is not a source-observed fact.

A collection index is not an identity declaration.

WebMEM therefore defines Fragment Classes.

A Fragment Class declares the semantic role of the knowledge represented by a fragment.

The current protocol defines 15 Fragment Classes:

• DataFragment — source-observed factual data;
• DerivedStatsFragment — calculated or derived statistics;
• IndexFragment — identifiable collection membership;
• DefinedTermFragment — canonical definition of a term;
• FAQFragment — question-and-answer knowledge;
• MetaFragment — metadata describing sources, datasets, resources, or other knowledge objects;
• ExplainerFragment — explanatory knowledge;
• DirectoryFragment — structured directory membership and entries;
• EligibilityFragment — eligibility criteria and conditional applicability;
• ProcedureFragment — ordered procedural knowledge;
• GlossaryFragment — contextual glossary knowledge;
• PersonaFragment — structured illustrative or research-derived persona context;
• PolicyFragment — policy rules, conditions, and exceptions;
• RecommendationFragment — publisher-defined recommendations and their basis;
• and IdentityFragment — explicit structural identity knowledge.

The classes are not presentation templates.

They describe what kind of knowledge the fragment contains.

Fragment
        ↓
Fragment Class
        ↓
Semantic Role

This distinction allows machines to encounter modular knowledge without being forced to infer its role solely from prose or field names.

3.4 Facts and Assertions

At the factual layer, WebMEM distinguishes between a value and an assertion.

Consider:

4900

This is a value.

Now consider:

maximum_out_of_pocket = 4900 USD

This is closer to a fact representation.

But WebMEM must still answer:

Who or what is this about?

Where did the value come from?

When does it apply?

Was it observed or derived?

The machine-facing assertion therefore exists within a larger semantic context:

Subject:
segment:H5521-290-001

Predicate:
maximum_out_of_pocket

Value:
4900

Unit:
USD

Plan Year:
2026

Provenance:
CMS PBP 2026

Derived:
false

The assertion is not merely a value encoded for a parser.

It is a publisher statement about an identifiable subject within applicable context.

WebMEM publishes assertions, not orphaned values.

3.5 Identity

Machine-readable knowledge becomes unreliable when the subject of that knowledge is ambiguous.

For example:

H5521
H5521-290
H5521-290-0
H5521-290-001

may identify different structural objects within the same domain.

A value attached to the wrong identity may remain numerically correct while becoming semantically wrong.

WebMEM therefore treats identity as a first-class protocol concern.

Identity answers:

What identifiable object does this knowledge describe?

Identity may apply at several levels:

Web Resource Identity

Dataset / SDT Identity

Fragment Identity

Entity Identity

Sub-Entity Identity

Source Identity

These identities must not be collapsed merely because they participate in the same resource.

Correct knowledge begins with the correct subject.

3.6 Provenance

Factual values often survive extraction more easily than their evidentiary context.

A machine may recover:

maximum_out_of_pocket = 4900 USD

while losing:

Source:
CMS PBP 2026

Applicable Entity:
segment:H5521-290-001

Transformation:
normalized currency value

Publisher:
Example Publisher

WebMEM treats provenance as the lineage relationship connecting published knowledge to the sources, transformations, derivations, and responsible actors through which that knowledge came to exist.

Provenance answers:

Where did this knowledge come from, and how did it become the assertion being published?

This is broader than attaching a citation.

For source-observed knowledge:

Assertion
→ sourcedFrom
→ Dataset

For derived knowledge:

Derived Assertion
→ derivedFrom
→ Source Data
→ generatedBy
→ Method / Transformation

Provenance does not tell a consuming machine what it must trust.

It gives the machine access to the lineage required to evaluate the assertion.

3.7 Relationships

Knowledge objects rarely exist in isolation.

The publisher may know:

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

Plan
→ usesFormulary
→ Formulary

Conventional documents may imply these connections through tables, links, names, URLs, or navigation.

WebMEM allows the publisher to represent the relationships explicitly.

A relationship preserves:

Source
→ Predicate
→ Target

For example:

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

Relationship meaning matters.

hasSegment is not equivalent to sameAs.

availableIn is not equivalent to operatedBy.

derivedFrom is not equivalent to memberOf.

Machines should not be forced to infer a relationship the publisher already knows.

3.8 Resolution

Identity, provenance, and relationships establish the structure of knowledge.

They do not always determine which knowledge applies to a particular information need.

Consider:

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

Both premium assertions may be correct.

If the information need concerns County X, only one is applicable.

WebMEM calls the process of moving from known identity and context through relationships and applicability constraints to the appropriate knowledge object or resource resolution.

Known Entity / Context
        ↓
Candidate Knowledge
        ↓
Relationships
        ↓
Applicability
        ↓
Resolved Knowledge

This establishes one of the most important distinctions in the current protocol:

A fact can be true and still be inapplicable.

Resolution preserves the difference between available knowledge and applicable knowledge.

3.9 Resolvers

Production implementation revealed that some identifiers and contexts repeatedly require the same resolution work.

For example:

County
→ What options are available here?

or:

Contract ID
→ What does this identify?
→ Who operates it?
→ What plans belong to it?

or:

Formulary ID
→ What formulary is this?
→ Which plans use it?
→ Where can resolution continue?

These observations produced the WebMEM Resolver architecture.

A Resolver is a publisher-defined information resource organized around a known identifier, entity, or context that exposes the identities, relationships, option space, applicability structure, and canonical resources necessary to continue or complete machine resolution.

Conceptually:

Known Identifier / Context
        ↓
Resolver
        ↓
Published Resolution Structure
        ↓
Entity / Collection / Option Space / Resource

The Resolver does not create relationships the publisher does not know.

It publishes resolution structure the publisher already possesses.

3.10 Dataset Declaration

The current architecture distinguishes between declaring the page-level dataset and serializing the internal WebMEM knowledge model.

Schema.org Dataset JSON-LD can be used to declare the machine-facing dataset associated with the resource.

The Semantic Data Template represents the WebMEM knowledge inside that dataset.

Schema.org Dataset JSON-LD
        ↓
Declares the Dataset

Semantic Data Template
        ↓
Represents WebMEM Knowledge

The two may share a stable identity:

Dataset @id
=
SDT identity

This allows WebMEM to use an established web vocabulary for dataset declaration without forcing the internal WebMEM knowledge model into Schema.org.

3.11 Serialization

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

This creates a serialization boundary:

WebMEM Knowledge Model
        ↓
Serialization
        ↓
Concrete Representation

A conforming serialization may change syntax.

It must not change semantics.

The current normative WebMEM serialization is HTML-in-HTML.

It uses inert HTML <template> containers, semantic HTML structures, and structured data-* attributes.

Conceptually:

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

  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-fragment-id="plan-benefits"
    data-entity-id="plan:H5521-290-0">

    <data
      data-webmem-assertion
      data-webmem-assertion
      data-field="monthly_premium"
      value="18.50"
      data-type="currency"
      data-unit="USD">
      $18.50
    </data>

  </template>

</template>

The outer <template> represents the page-level SDT.

The nested <template> represents a WebMEM Fragment.

The <data> element represents a scalar assertion within that fragment.

The HTML syntax is not the knowledge model itself.

It is the current serialization of that model.

This distinction allows the WebMEM architecture to remain stable even if additional serializations are defined in the future.

3.12 Why HTML-in-HTML

The original WebMEM design used inert HTML containers and structured data-* attributes to expose machine-readable knowledge directly within ordinary web resources.

WebMEM 1.x later introduced YAML inside those containers as an intermediate representation.

That produced a processing path resembling:

HTML Document
        ↓
Locate Template
        ↓
Extract YAML
        ↓
Parse YAML
        ↓
Interpret WebMEM

The current serialization removes the intermediate YAML layer:

HTML Document
        ↓
Parse DOM
        ↓
Interpret WebMEM

The result returns WebMEM to its original native-HTML design principle while preserving the more mature conceptual architecture developed through subsequent implementation.

The HTML <template> element provides an inert container. Its contents exist declaratively in the HTML document without rendering as ordinary page content.

This supports the two-tier publishing model:

HTML Resource
│
├── Human-Facing HTML
│   └── rendered for people
│
└── WebMEM HTML-in-HTML
    └── structured for machine interpretation

No JavaScript execution is required to establish the machine-facing knowledge structure.

3.13 Conformance

A machine-readable structure does not become WebMEM merely because it uses WebMEM names or markup.

For example:

<template
  data-webmem-sdt>

  ...

</template>

may be valid HTML.

That does not establish WebMEM conformance.

Conformance requires the representation to preserve the semantic distinctions required by the protocol.

These include, where applicable:

• the correct Fragment Class;
• the correct subject identity;
• the distinction between source-observed and derived knowledge;
• material provenance;
• material relationships;
• applicability context;
• collection membership;
• semantic ordering;
• resolution-relevant distinctions;
• and unresolved ambiguity.

WebMEM therefore distinguishes among:

Semantic Conformance
→ Did the meaning survive?

Structural Conformance
→ Are the knowledge objects organized correctly?

Serialization Conformance
→ Does the concrete representation satisfy
  the applicable serialization requirements?

A representation may satisfy serialization syntax while failing semantic conformance.

Valid WebMEM syntax does not rescue invalid WebMEM semantics.

3.14 WebMEM Does Not Require Every Capability Everywhere

The protocol defines a broad knowledge architecture, but individual resources use only the components appropriate to the knowledge they publish.

A county-level resource might contain:

IdentityFragment
IndexFragment
DataFragment
DerivedStatsFragment
MetaFragment

A policy resource might contain:

IdentityFragment
PolicyFragment
DefinedTermFragment
ProcedureFragment
MetaFragment

A glossary resource might contain:

GlossaryFragment
DefinedTermFragment
MetaFragment

Conformance does not require every SDT to contain every Fragment Class.

Likewise:

• knowledge that is not derived does not require invented derivation metadata;
• knowledge without material cross-object relationships does not require invented relationships;
• unambiguous knowledge does not require an artificial unresolved state;
• and a resource that does not solve a recurring resolution problem does not need to become a Resolver.

WebMEM requires the semantics that matter to the knowledge being published—not ceremonial use of every protocol feature.

3.15 From Multi-Format Output to Serialization Independence

The original Semantic Digest architecture required multiple representations of the same knowledge:

• JSON-LD;
• Turtle;
• Markdown;
• W3C PROV;
• XML;
• and CSV.

The objective was broad retrieval compatibility.

The current protocol takes a different approach.

WebMEM separates the conceptual knowledge model from its serialization.

WebMEM Knowledge Model
        ↓
Serialization Contract
        ↓
Concrete Serialization

The current normative serialization is HTML-in-HTML.

Additional serializations may be defined in the future if implementation requirements justify them and they can preserve the semantic distinctions required by the WebMEM knowledge model.

The protocol does not require publishers to generate multiple representations merely in the hope that one will be preferred by a particular consuming system.

This replaces format proliferation with a stronger requirement:

Whatever serialization is used must preserve the meaning of the WebMEM knowledge model.

3.16 From Canonical Digest Endpoints to Canonical Resources

The original Semantic Digest architecture also required dedicated machine endpoints such as:

/semantic/json/{fragment_id}
/semantic/ttl/{fragment_id}
/semantic/md/{fragment_id}

Those endpoints were intended to allow consuming systems to retrieve machine-specific representations without processing the human-facing page.

The current WebMEM architecture does not require separate semantic endpoints.

The machine-facing representation may be published directly within the canonical web resource using HTML-in-HTML.

Conceptually:

Canonical Web Resource
│
├── Human-Facing Representation
│
├── Dataset Declaration
│
└── WebMEM SDT

This reduces the risk of creating parallel information surfaces whose identity, version, or content may drift apart.

Separate endpoints may still exist where an implementation has a legitimate operational reason for them.

They are not required by the core WebMEM Protocol.

The more important requirement is preservation of canonical identity and explicit relationships among entities and resources.

3.17 Example: Medicare Plan Knowledge Representation

The original paper illustrated a Medicare Advantage plan as a single Semantic Digest.

The current model separates the concerns that the Digest previously combined.

Conceptually:

Plan Resource
│
├── Dataset Declaration
│
└── SDT
    │
    ├── IdentityFragment
    │   └── plan:H0321-002-0
    │
    ├── DataFragment
    │   ├── plan_type
    │   ├── premium
    │   ├── maximum_out_of_pocket
    │   └── other source-observed facts
    │
    ├── DefinedTermFragment
    │   └── applicable domain terminology
    │
    ├── MetaFragment
    │   └── CMS source dataset
    │
    └── Relationships
        ├── belongsToContract
        ├── hasSegment
        ├── offeredBy
        └── canonicalResource

If the plan has geographic segments, the model can preserve those identities separately:

plan:H0321-002
│
├── hasSegment
│   └── segment:H0321-002-001
│       └── appliesIn
│           └── county:04013
│
└── hasSegment
    └── segment:H0321-002-002
        └── appliesIn
            └── county:04015

If premiums differ by segment, the assertions remain attached to the applicable segment rather than being flattened onto the parent plan.

This demonstrates why the current architecture requires more than an entity-scoped bundle of fields.

The machine-facing representation must preserve the identities and relationships necessary to interpret the knowledge correctly.

3.18 Generating WebMEM from Structured Inputs

The original framework correctly recognized that machine-facing knowledge can be generated through several publishing workflows.

That remains true.

WebMEM representations may be created:

• Programmatically — from databases, public datasets, APIs, data warehouses, content management systems, or publisher pipelines;
• Retrospectively — by structuring knowledge already present in legacy resources and associated metadata;
• Editorially — through structured authoring workflows;
• Semi-Automatically — through extraction, transformation, and editorial review;
• or through combinations of these methods.

The generation method does not determine conformance.

The resulting representation does.

A fully automated pipeline can produce non-conforming WebMEM.

A manually authored fragment can conform perfectly.

The relevant question is whether the published representation preserves the applicable WebMEM semantics.

3.19 WebMEM Is Not Merely Markup

The original paper stated:

Semantic Digests are not markup.

The underlying point remains important.

WebMEM is not defined by a collection of HTML attributes.

HTML-in-HTML is the current serialization of a conceptual knowledge model.

That model includes:

SDT
Fragments
Assertions
Identity
Provenance
Relationships
Resolution

The markup exists to carry those semantics into the published resource.

Without the semantic model, the attributes are merely syntax.

Without serialization, the conceptual model remains unpublished.

WebMEM requires both.

3.20 The Protocol Boundary

The current WebMEM Protocol deliberately stops at the publisher-consumer boundary.

It defines:

• how machine-facing knowledge is organized;
• how different kinds of knowledge are distinguished;
• how assertions retain identity and context;
• how provenance is preserved;
• how relationships are represented;
• how resolution structure can be exposed;
• how the conceptual model is serialized;
• and what is required for a representation to claim conformance.

It does not define:

• how a search engine must index WebMEM;
• how a language model must store it;
• how an answer engine must retrieve it;
• how a machine must score authority;
• how a model must rank competing evidence;
• how an agent must reason over the representation;
• or whether a consuming system must use WebMEM at all.

This boundary is intentional.

Consumer architectures will continue to change.

The publisher-side problem remains remarkably stable:

How do we publish what we know without unnecessarily discarding its meaning?

3.21 The Current WebMEM Model

The 2025 Semantic Digest attempted to make knowledge retrievable by packaging it for machines.

The 2026 WebMEM Protocol asks a more fundamental question:

What must survive when knowledge leaves the publisher’s internal systems and becomes a public machine-readable representation?

The answer is not one universal object.

It is an architecture:

Knowledge
        ↓
Semantic Organization
        ↓
Identity and Context
        ↓
Provenance
        ↓
Relationships
        ↓
Resolution
        ↓
Serialization
        ↓
Conforming Publication

This is the transition from the original Semantic Digest model to the current WebMEM Protocol.

The goal is no longer to package information in every format a machine might ingest.

The goal is to preserve the publisher’s knowledge well enough that the machine does not have to reconstruct what the publisher already knew.

WebMEM is not a memory container.

It is a knowledge representation protocol for the answer-engine web.