WebMEM Architecture

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

Overview

WebMEM is a publisher-side architecture for representing the knowledge associated with a web resource in a form designed for machine interpretation and resolution.

The architecture begins with a simple distinction:

A document and the knowledge contained by that document are not the same thing.

A human reader can interpret a conventional web page using prose, headings, tables, navigation, visual hierarchy, citations, surrounding context, and prior knowledge.

A machine may need to identify and use the underlying knowledge without relying on those same presentation cues.

WebMEM therefore allows a publisher to maintain the human-facing document while publishing a complementary machine-facing representation of the knowledge associated with that resource.

The architecture separates:

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

These layers define what the publisher knows, how that knowledge is organized, what its objects mean, how they connect, when they apply, and how the resulting representation is published.

The Architectural Model

The WebMEM architecture can be represented at a high level as:

Web Resource
│
├── Human-Facing Representation
│   ├── prose
│   ├── headings
│   ├── tables
│   ├── navigation
│   ├── citations
│   └── interactive presentation
│
├── Dataset Declaration
│   └── Schema.org Dataset JSON-LD
│
└── Machine-Facing Representation
    └── Semantic Data Template
        │
        ├── WebMEM Fragment
        │   ├── Assertions
        │   └── Structures
        │
        ├── WebMEM Fragment
        │   ├── Assertions
        │   └── Structures
        │
        └── WebMEM Fragment
            ├── Assertions
            └── Structures

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

Resolution Surfaces
└── Resolvers

Serialization
└── HTML-in-HTML

Governance
└── Conformance

The architecture is deliberately layered.

No single component is expected to perform every semantic function.

The Web Resource Is the Publication Surface

WebMEM begins with an ordinary web resource.

The resource may describe:

a person or organization;
a product or service;
a geographic market;
a directory;
a dataset;
a policy;
a procedure;
a public program;
a glossary;
a resolver;
or another body of publisher knowledge.

WebMEM does not require the publisher to replace the human-facing document with a machine-oriented presentation.

The existing page remains the publication surface.

The machine-facing representation is associated with that same resource.

Dual Publishing

WebMEM treats human communication and machine communication as related but distinct publishing requirements.

The human-facing representation may optimize for:

readability;
editorial flow;
visual hierarchy;
persuasion;
navigation;
accessibility;
interaction;
and human comprehension.

The machine-facing representation may optimize for:

explicit identity;
semantic classification;
factual interpretation;
source lineage;
temporal and geographic applicability;
relationships;
collection membership;
resolution;
and canonical resource discovery.

The two representations should remain aligned to the same underlying knowledge.

They do not need to use the same structure.

Dual publishing means communicating the same underlying knowledge in forms appropriate to human and machine consumers.

The Semantic Data Template Is the Machine Knowledge Boundary

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

It establishes the composition boundary within which the publisher organizes the machine-facing knowledge associated with the resource.

Conceptually:

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

The SDT may contain knowledge about one entity or multiple related entities.

It may represent one source or combine knowledge from several sources.

It may contain source-observed facts, derived statistics, definitions, identity structures, policies, procedures, directories, explanations, or other forms of knowledge appropriate to the resource.

The SDT is not a universal record schema.

It is the structure through which different semantic objects participate in one coherent page-level knowledge representation.

Read the Semantic Data Template specification →

Fragments Provide Semantic Organization

An SDT is composed of WebMEM fragments.

Each fragment declares a Fragment Class.

The Fragment Class defines the semantic role of the knowledge represented by that fragment.

This prevents fundamentally different kinds of knowledge from being flattened into one generic data structure.

For example:

DataFragment
→ source-observed factual knowledge

DerivedStatsFragment
→ calculated or aggregated knowledge

IdentityFragment
→ canonical entity identity

IndexFragment
→ collection membership

DefinedTermFragment
→ canonical meaning

PolicyFragment
→ governing rule

EligibilityFragment
→ qualification logic

ProcedureFragment
→ ordered process

RecommendationFragment
→ publisher-defined recommendation

The current protocol defines 15 Fragment Classes, each preserving a different semantic purpose.

The Fragment Class answers: What kind of knowledge is this?

Read the WebMEM Fragments specification →

Assertions and Structures Carry the Knowledge

Inside fragments are the assertions and structures through which the publisher communicates actual knowledge.

Within a DataFragment, those contents may be factual assertions:

monthly_premium = 0 USD
plan_type = PPO
maximum_out_of_pocket = 4900 USD

Within a DerivedStatsFragment:

plan_count = 42
average_premium = 27.42 USD
zero_premium_percentage = 61.9 percent

Other Fragment Classes contain other forms of semantic structure:

PolicyFragments contain rules and exceptions;
ProcedureFragments contain ordered steps;
EligibilityFragments contain qualification criteria;
DirectoryFragments contain directory entries;
GlossaryFragments contain vocabulary membership;
and IdentityFragments contain identifiers and structural identity.

WebMEM therefore does not impose a universal Machine Fact Object beneath every Fragment Class.

The Fragment Class determines the semantic nature of the assertions and structures it contains.

Read Facts and Assertions →

Meaning Is More Than the Value

A central architectural principle of WebMEM is that a machine-readable value is not necessarily a machine-usable assertion.

Consider:

15.26

The value may require additional knowledge before it can be interpreted correctly:

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

The numerical value did not change.

The architecture preserved the meaning around it.

This is why identity, context, provenance, and applicability are architectural concerns rather than optional decoration around structured values.

Context Can Be Shared

WebMEM does not require every assertion to repeat every piece of information necessary to interpret it.

Context may be established at the SDT, fragment, or assertion level.

For example:

SDT
  geography: Mohave County, Arizona
  plan_year: 2026

  DataFragment
    entity: plan:H5521-290-0
    source: CMS PBP

    monthly_premium = 0 USD
    primary_care_copay = 0 USD
    specialist_copay = 35 USD
    maximum_out_of_pocket = 4900 USD

The individual assertions inherit applicable context from the structures containing them.

This avoids meaningless duplication while preserving interpretability.

When a particular assertion differs in source, time, geography, entity scope, or another material dimension, that difference must remain explicit.

Shared context may be inherited. Material differences must not be hidden by inheritance.

Identity Is a Cross-Cutting Semantic Layer

Identity establishes what the knowledge describes.

This is not merely a fragment-level concern.

Identity may be required throughout the SDT to distinguish among:

the web resource;
the page-level Dataset;
the SDT;
individual fragments;
real-world entities;
conceptual entities;
collection members;
and canonical resources.

Identity becomes especially important when entities form hierarchies:

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

These objects may share relationships and identifiers, but they represent different semantic subjects.

WebMEM identity semantics prevent assertions from drifting across those boundaries.

Read the Identity specification →

Provenance Is a Cross-Cutting Semantic Layer

Provenance establishes the source and lineage of published knowledge.

Different fragments within one SDT may depend on different sources:

SDT
│
├── DataFragment
│   └── CMS Landscape
│
├── DataFragment
│   └── CMS Monthly Enrollment
│
├── DataFragment
│   └── CMS PBP
│
└── DerivedStatsFragment
    └── publisher derivation from multiple sources

The SDT composes these objects without pretending that their evidentiary origins are identical.

Provenance may therefore operate at the dataset, fragment, assertion, or derivation level depending on where the meaningful source distinction occurs.

Composition combines knowledge. Provenance preserves where that knowledge came from.

Read the Provenance specification →

Relationships Connect the Knowledge Graph

Structured objects become more useful when their relationships are explicit.

WebMEM relationships may express:

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

IndexFragment
→ contains
→ Plan

PolicyFragment
→ governs
→ EligibilityFragment

ProcedureFragment
→ appliesTo
→ Program

DataFragment
→ derivedInto
→ DerivedStatsFragment

Relationships allow machines to understand how publisher knowledge connects without requiring those connections to be reconstructed from prose, URLs, or visual page structure.

Relationships may connect objects within one SDT or connect the resource to other identifiable objects and canonical resources.

Read the Relationships specification →

Resolution Extends Beyond Representation

Representing knowledge correctly does not always make that knowledge immediately applicable.

Sometimes another identity, context, relationship, or condition must be resolved first.

For example:

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

If a benefit varies by segment, the parent Plan ID alone may not be sufficient to determine the correct value.

Likewise:

County
→ Available Plans
→ Plan Identity
→ Canonical Plan Resource

or:

Program
→ Eligibility Requirements
→ Applicable Procedure
→ Application Resource

Resolution is therefore a distinct architectural concern.

It represents what must be known, distinguished, or traversed before a machine can safely reach the applicable knowledge object or resource.

Representation answers what the publisher knows. Resolution helps establish which knowledge applies.

Read the WebMEM Resolution Model →

Resolvers Are Resolution Surfaces

A resolver is a publisher-defined information architecture organized around a known entity, identifier, or context from which additional knowledge must be resolved.

Examples include:

County
→ available Medicare plans

Contract ID
→ carrier
→ contract
→ plans
→ historical information

Formulary ID
→ formulary
→ related plans
→ applicable resources

A resolver may compose multiple WebMEM structures:

IdentityFragments;
IndexFragments;
DirectoryFragments;
DataFragments;
DerivedStatsFragments;
relationships;
and canonical resource references.

A resolver is not a Fragment Class.

It is a resolution-oriented publishing architecture that may use several Fragment Classes to expose the option space or path associated with an entity or context.

Read the Resolvers specification →

Dataset Declaration Provides the Discovery Layer

The SDT defines the page-level machine knowledge representation, but WebMEM can also expose that representation through an established dataset declaration vocabulary.

Schema.org Dataset JSON-LD provides that discovery and description layer.

The relationship is:

Schema.org Dataset
  ↓
declares the machine-facing dataset

Semantic Data Template
  ↓
organizes the dataset's knowledge

Fragment Classes
  ↓
define semantic roles

Assertions and Structures
  ↓
communicate publisher knowledge

The Dataset declaration and SDT may share a stable identity.

This gives machines a conventional page-level declaration that a dataset exists while allowing WebMEM to represent the richer internal knowledge architecture.

Schema.org Dataset does not replace WebMEM.

WebMEM does not replace Schema.org Dataset.

Dataset provides declaration. SDT provides representation.

Read Dataset Declaration and SDT Mapping →

Composition Creates the Page-Level Knowledge Representation

An SDT may contain multiple Fragment Classes because a useful resource often contains several kinds of knowledge.

For example:

Medicare County Resource
└── SDT
    ├── IdentityFragment
    │   └── county identity
    │
    ├── MetaFragment
    │   └── CMS source metadata
    │
    ├── IndexFragment
    │   └── available plans
    │
    ├── DataFragment
    │   └── source-observed market knowledge
    │
    ├── DerivedStatsFragment
    │   └── publisher-derived statistics
    │
    └── GlossaryFragment
        └── applicable terminology

Composition does not erase the semantic differences among those objects.

It establishes that they participate together in the knowledge representation of the same resource.

Identity, provenance, context, and relationships preserve how those objects fit together.

Read SDT Composition →

Serialization Is a Separate Layer

The WebMEM knowledge model does not depend conceptually on a particular serialization syntax.

The architecture separates:

Knowledge Model
      ↓
Serialization
      ↓
Published Representation

The SDT defines the page-level knowledge representation.

Fragment Classes define the semantic roles of the knowledge objects within that representation.

Identity, provenance, relationships, context, and resolution define how those objects are interpreted and connected.

Serialization defines how the resulting knowledge model is encoded for publication or exchange.

This separation is important because a serialization method can change without requiring the underlying knowledge architecture to change.

The knowledge model defines what the knowledge means. Serialization defines how that knowledge travels.

Read the Serialization specification →

HTML-in-HTML Is the Current Serialization

The current WebMEM serialization uses HTML-in-HTML.

The SDT and its fragments are represented within inert HTML <template> containers published in the same HTML resource as the human-facing document.

Conceptually:

<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 HTML elements and data-* attributes serialize the WebMEM knowledge structure.

They do not define the conceptual meaning of the SDT, Fragment Classes, identity, provenance, relationships, or resolution model.

This distinction allows WebMEM to evolve its serialization independently from its underlying knowledge architecture.

Read the HTML-in-HTML Serialization specification →

Architecture Is Not Serialization

This distinction deserves emphasis because earlier structured publishing systems often allow the syntax of the representation to become the architecture itself.

WebMEM separates the two deliberately.

For example:

Semantic Data Template
≠ <template>

DataFragment
≠ a particular HTML element

Identity
≠ data-entity-id

Provenance
≠ data-provenance-ref

Relationship
≠ a particular attribute

Resolution
≠ a particular link structure

The concepts on the left belong to the WebMEM knowledge architecture.

The syntax on the right is one way those concepts may be serialized.

A future serialization could represent the same conceptual objects differently without changing what those objects mean.

Architecture Is Not an Ontology

WebMEM does not attempt to define a universal ontology for every domain of knowledge.

The protocol defines architectural roles such as:

SDT;
Fragment Class;
identity;
provenance;
relationship;
assertion;
composition;
resolution;
and serialization.

Individual domains remain responsible for the entities, identifiers, vocabularies, policies, classifications, and relationships appropriate to their subject matter.

For example, WebMEM does not redefine what a Medicare contract, pharmaceutical formulary, legal jurisdiction, product SKU, or geographic county is.

It provides an architecture through which the publisher can identify those objects and represent knowledge about them coherently.

Architecture Is Not a Retrieval System

WebMEM does not define how a search engine, answer engine, language model, agent, crawler, or retrieval system must discover or use published knowledge.

The protocol operates on the publisher side.

It allows the publisher to make machine-facing knowledge explicit before a consuming system decides whether or how to use it.

The architecture therefore does not require:

retrieval hints;
memory scores;
agent reinforcement;
feedback loops;
retrieval logging;
model-specific instructions;
or search-engine-specific directives.

A consuming system may index, retrieve, ignore, transform, validate, compare, or reason over WebMEM according to its own architecture and policies.

WebMEM defines what the publisher makes explicit, not what the consuming machine must do with it.

Architecture Is Not a Truth System

Structured knowledge does not become true merely because it is represented through WebMEM.

WebMEM can make explicit:

what the publisher asserts;
what entity the assertion describes;
where the assertion came from;
whether it was observed or derived;
when and where it applies;
how it relates to other knowledge;
and what conditions affect its applicability.

Those structures make the assertion more inspectable.

They do not require a consuming system to accept the assertion as true or authoritative.

A consuming system remains free to evaluate source authority, provenance, corroboration, recency, methodology, consistency, or any other signals it considers relevant.

Architectural Separation of Concerns

The WebMEM architecture can be understood as a sequence of distinct concerns.

Layer	Architectural Question
Knowledge	What does the publisher know or assert?
Semantic Organization	What kind of knowledge is it, and how should related knowledge be grouped?
Identity and Context	What does the knowledge describe, and under what scope does it apply?
Provenance	Where did the knowledge come from, and how was it produced?
Relationships	How do the represented objects connect?
Resolution	What must be known or traversed before the applicable object or value can be reached?
Serialization	How is the knowledge representation encoded for publication or exchange?
Conformance	What requirements must an implementation satisfy to conform to the protocol?

Keeping these concerns separate allows each layer to evolve without forcing unrelated parts of the architecture to be redesigned.

Architectural Example: County-Level Resource

Consider a resource describing Medicare options within a county.

The human-facing page may contain explanatory prose, plan tables, links, citations, and calls to action.

The machine-facing architecture may resemble:

Web Resource
│
├── Dataset JSON-LD
│   └── identifies county-level WebMEM dataset
│
└── SDT
    │
    ├── IdentityFragment
    │   └── county identity
    │
    ├── MetaFragment
    │   └── CMS Landscape source
    │
    ├── MetaFragment
    │   └── CMS Enrollment source
    │
    ├── IndexFragment
    │   └── plans available in county
    │
    ├── DataFragment
    │   └── source-observed market facts
    │
    └── DerivedStatsFragment
        └── publisher-derived county statistics

Relationships
├── county → contains available plans
├── facts → apply to county/year
└── derived statistics → derived from source knowledge

Resolution
└── county → plan index → plan → canonical resource

No single object performs all of these jobs.

The architecture works because each object has a defined semantic responsibility and the relationships among those objects are preserved.

Architectural Example: Entity-Key Resolver

Consider a resource organized around a known identifier such as a Medicare Contract ID.

The architecture may resemble:

Contract ID
↓
IdentityFragment
↓
Contract Entity
│
├── carrier relationship
├── current contract facts
├── historical facts
└── plan membership
      ↓
    IndexFragment
      ↓
    Plan Entities
      ↓
    Canonical Resources

The Contract ID provides the entry point.

Identity establishes what the identifier represents.

DataFragments may publish contract-level facts.

An IndexFragment may identify the plans belonging to the contract.

Relationships connect the contract to its carrier and plans.

Resolution connects the known identifier to the broader option space and canonical resources.

This is the architectural distinction between publishing a page about an identifier and publishing a resolver for that identifier.

Architectural Example: Policy and Procedure

Consider a resource explaining access to a public program.

The SDT may compose:

PolicyFragment
  ↓
governing rule

EligibilityFragment
  ↓
qualification criteria

ProcedureFragment
  ↓
application steps

DefinedTermFragment
  ↓
canonical policy terminology

ExplainerFragment
  ↓
human-oriented conceptual explanation

The fragments describe related knowledge, but each performs a different semantic role.

Relationships preserve how the rule governs eligibility, how eligibility affects the procedure, and how terminology and explanations support interpretation.

The SDT composes those objects into one machine-facing representation without collapsing them into a generic data record.

Why the Layers Matter

The layered architecture prevents several common failure modes.

Identity Collapse

Related entities are treated as though they were the same entity.

Contract ≠ Plan ≠ Segment

Context Loss

A value is extracted without the geography, time period, population, or condition that determines where it applies.

Provenance Collapse

Knowledge from several sources is presented as though it came from one undifferentiated source.

Derivation Collapse

A publisher-calculated value is represented as though the original source published it directly.

Semantic Collapse

Facts, policies, definitions, procedures, recommendations, and identities are forced into one generic object model.

Resolution Collapse

A machine is given a convenient value before the entity or context required to determine the applicable value has been resolved.

Serialization Collapse

The syntax used to publish the knowledge becomes inseparable from the conceptual knowledge model.

WebMEM separates these concerns so that each can remain explicit.

Architectural Principle: Preserve Meaning

The first responsibility of the architecture is to preserve meaning.

A machine-facing representation should preserve enough information to answer:

What is this object?
What is being asserted?
What does the assertion mean?
What entity does it describe?
Where does it apply?
When does it apply?
Where did it come from?
Was it observed or derived?
How does it relate to other objects?
and what must be resolved before it can be applied correctly?

Not every answer must be repeated on every assertion.

The architecture allows meaning to be established through coherent composition and inherited context.

Architectural Principle: Avoid Meaningless Atomization

WebMEM does not assume that maximum granularity produces maximum machine usefulness.

Consider:

0
35
4900

These values can be independently extracted.

But separating them from their predicates, entity, time period, source, and shared context makes them less useful rather than more useful.

A coherent DataFragment may instead preserve:

entity: plan:H5521-290-0
plan_year: 2026
source: CMS PBP

monthly_premium = 0 USD
specialist_copay = 35 USD
maximum_out_of_pocket = 4900 USD

The assertions remain distinguishable without forcing the consuming system to reconstruct their shared context.

The goal is not the smallest possible object. The goal is the smallest useful unit of knowledge that preserves meaning.

Architectural Principle: Compose Rather Than Flatten

A resource may contain several kinds of knowledge.

WebMEM composes those kinds of knowledge through Fragment Classes rather than flattening them into one universal structure.

For example:

Identity
+ Facts
+ Derived Statistics
+ Definitions
+ Relationships
+ Provenance
+ Policies
+ Procedures
+ Resolution

= coherent machine knowledge representation

The SDT provides the composition boundary.

The Fragment Classes preserve semantic differences.

Relationships connect the resulting objects.

Architectural Principle: Resolve Before Generalizing

A correct value may become incorrect when applied at the wrong level of identity or context.

For example:

Parent Plan
├── Segment A → premium = 0 USD
├── Segment B → premium = 18.50 USD
└── Segment C → premium = 32.00 USD

The question:

What is the premium?

cannot safely resolve to one value until the applicable segment is known.

The architecture should preserve that dependency rather than publishing one convenient parent-level value that obscures the actual variation.

When applicability depends on resolution, resolution is part of the knowledge architecture.

Architectural Principle: Preserve Evidentiary Boundaries

Composition should not erase source lineage.

For example:

CMS Landscape
      ↓
source-observed plan availability

CMS Monthly Enrollment
      ↓
source-observed enrollment

Publisher Calculation
      ↓
derived market-share statistic

All three may participate in one SDT.

They do not have the same evidentiary origin.

WebMEM provenance preserves those boundaries.

Architectural Principle: Separate Representation From Consumption

WebMEM defines publisher-side representation.

It does not define consumer-side behavior.

The publisher can explicitly represent:

identity;
facts;
context;
provenance;
relationships;
definitions;
policies;
procedures;
recommendations;
and resolution paths.

A consuming system remains responsible for deciding whether and how to use that knowledge.

This separation prevents the protocol from depending on undocumented assumptions about model memory, crawler behavior, retrieval weighting, or agent execution.

Conformance as Architectural Governance

Conformance defines what it means for a representation or implementation to follow the WebMEM Protocol.

Conformance protects the semantic distinctions established by the architecture.

For example, a conforming implementation should not:

treat an SDT as though it were an individual fragment;
omit Fragment Class identity where the semantic role depends on it;
collapse materially different entities into one identity;
represent derived knowledge as source-observed knowledge;
discard applicability context necessary to interpret an assertion;
flatten materially different provenance into one source statement;
or claim that serialization syntax defines the conceptual model.

Specific conformance requirements are defined separately so that the architecture can describe the model while the conformance specification defines testable requirements.

Read the Conformance specification →

Relationship to WebMEM 1.x

The current WebMEM architecture evolved from the original WebMEM 1.x specification.

WebMEM 1.x established several concepts that remain foundational:

Semantic Data Templates;
modular Fragment Classes;
structured factual fields;
provenance;
defined terminology;
cross-fragment relationships;
and inert machine-facing publication within HTML.

The 1.x architecture also coupled those concepts to mechanisms such as:

YAML-in-HTML serialization;
Semantic Data Atoms;
semantic digests;
fragment scopes;
retrieval hints;
trust scoring;
memory-oriented optimization;
content-negotiated endpoints;
multi-format exports;
agent feedback;
and other assumptions about how consuming systems might retrieve, retain, or act upon published knowledge.

The current architecture separates the durable knowledge-modeling concepts from those earlier implementation and consumption assumptions.

The principal architectural changes are:

the SDT is now explicitly defined as the page-level machine knowledge representation;
WebMEM fragments are modular knowledge objects within the SDT rather than SDTs themselves;
the 15 Fragment Classes are preserved as semantic roles within the knowledge model;
assertions and structures represent the actual knowledge contained within those fragments;
the earlier Semantic Data Atom concept is retained conceptually through distinguishable factual assertions without requiring a separate universal fact-object layer;
identity, provenance, relationships, and resolution operate as cross-cutting semantic concerns;
composition defines how multiple Fragment Classes participate in one coherent page-level representation;
resolvers are treated as resolution-oriented publishing architectures rather than Fragment Classes;
Schema.org Dataset JSON-LD provides a page-level discovery and declaration mechanism for the machine-facing dataset;
and HTML-in-HTML is the current serialization of the knowledge model rather than the definition of the model itself.

This separation produces a simpler architectural hierarchy:

Web Resource
↓
Semantic Data Template
↓
Fragment Classes
↓
Assertions and Structures

with:

Identity
Provenance
Relationships
Resolution

and published through:

Serialization

The current architecture therefore preserves what proved durable in WebMEM 1.x while removing mechanisms that depended on assumptions about retrieval, memory, feedback, or a particular serialization format.

WebMEM has evolved from a fragment-oriented publishing format into a page-level machine knowledge architecture.

Architecture and Protocol Evolution

The WebMEM architecture is designed so that individual implementation methods can evolve without requiring the underlying knowledge model to be repeatedly reinvented.

For example, the protocol may evolve in areas such as:

serialization;
validation;
conformance profiles;
resolver profiles;
domain-specific implementation guidance;
Dataset declaration practices;
and interoperability mechanisms.

Those changes should preserve the architectural separation among:

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

This separation allows WebMEM to adapt to changes in web publishing and machine consumption while retaining a stable conceptual foundation.

Architecture Status

The WebMEM architecture is part of the publicly available WebMEM Protocol specification maintained by WebMEM.

The current architecture is published as a public draft and may be revised through controlled implementation, validation, interoperability testing, technical research, and continued development.

Public availability of the architecture 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 →

WebMEM Architecture

Overview

The Architectural Model

The Web Resource Is the Publication Surface

Dual Publishing

The Semantic Data Template Is the Machine Knowledge Boundary

Fragments Provide Semantic Organization

Assertions and Structures Carry the Knowledge

Meaning Is More Than the Value

Context Can Be Shared

Identity Is a Cross-Cutting Semantic Layer

Provenance Is a Cross-Cutting Semantic Layer

Relationships Connect the Knowledge Graph

Resolution Extends Beyond Representation

Resolvers Are Resolution Surfaces

Dataset Declaration Provides the Discovery Layer

Composition Creates the Page-Level Knowledge Representation

Serialization Is a Separate Layer

HTML-in-HTML Is the Current Serialization

Architecture Is Not Serialization

Architecture Is Not an Ontology

Architecture Is Not a Retrieval System

Architecture Is Not a Truth System

Architectural Separation of Concerns

Architectural Example: County-Level Resource

Architectural Example: Entity-Key Resolver

Architectural Example: Policy and Procedure

Why the Layers Matter

Identity Collapse

Context Loss

Provenance Collapse

Derivation Collapse

Semantic Collapse

Resolution Collapse

Serialization Collapse

Architectural Principle: Preserve Meaning

Architectural Principle: Avoid Meaningless Atomization

Architectural Principle: Compose Rather Than Flatten

Architectural Principle: Resolve Before Generalizing

Architectural Principle: Preserve Evidentiary Boundaries

Architectural Principle: Separate Representation From Consumption

Conformance as Architectural Governance

Relationship to WebMEM 1.x

Architecture and Protocol Evolution

Architecture Status

Related SDT Documents

Related Protocol Documents