WebMEM Implementation Architecture: Inline Machine Knowledge

From Publisher Data to Inline Machine Knowledge

The original Memory-First framework imagined a substantial new publishing infrastructure.

It proposed:

Semantic Digest endpoints;
multiple serializations;
HTTP content negotiation;
Markdown and Turtle representations;
GitHub repositories;
structured syndication;
retrieval-monitoring systems;
and reinforcement infrastructure.

That architecture reflected an early assumption:

machine-readable knowledge needed to be published somewhere separate from the human-facing web resource.

Implementation experience changed that assumption.

The current WebMEM architecture is considerably simpler.

The machine representation can travel inside the same HTML document as the human representation.

Canonical Web Resource
│
├── Human-Facing HTML
│
└── Machine Knowledge Layer
    └── WebMEM SDT
        └── HTML-in-HTML

This eliminates the requirement for a parallel semantic publishing infrastructure.

The publisher may still operate APIs, feeds, repositories, knowledge graphs, or other machine interfaces where those systems serve legitimate purposes.

But WebMEM does not require them.

The implementation problem is no longer how to build a second machine web.

It is how to preserve publisher knowledge inside the web that already exists.

16.1 The Implementation Boundary

Most publishers already possess structured knowledge before WebMEM enters the system.

That knowledge may exist in:

relational databases;
content-management systems;
APIs;
data warehouses;
CSV or spreadsheet workflows;
government datasets;
knowledge graphs;
editorial systems;
application logic;
or combinations of these systems.

The WebMEM implementation boundary occurs between:

Publisher Knowledge
        ↓
Public Representation

The publisher does not need to rebuild the upstream information system merely to implement WebMEM.

The task is to determine which publisher-known semantics should survive the transition into the public resource.

16.2 The Implementation Pipeline

A generalized implementation pipeline may look like:

Source Data
        ↓
Ingestion
        ↓
Normalization
        ↓
Publisher Knowledge Model
        ↓
Identity Resolution
        ↓
Provenance Assignment
        ↓
Relationship Construction
        ↓
Applicability Modeling
        ↓
Resolution Modeling
        ↓
SDT Composition
        ↓
HTML-in-HTML Serialization
        ↓
Conformance Validation
        ↓
Canonical Web Resource

Not every publisher requires a distinct technical component for every stage.

Some systems may already perform several of these operations.

The architecture describes semantic responsibilities rather than prescribing one software stack.

16.3 Begin With Existing Publisher Knowledge

Implementation should begin by inventorying what the publisher already knows.

For example, a Medicare publisher may already possess:

CMS Contract IDs
Plan IDs
Segment IDs
County FIPS Codes
Plan Benefits
Premiums
Star Ratings
Enrollment
Formulary IDs
Source Files
Plan Years
Carrier Relationships

The first WebMEM question is not:

How do we mark this up?

It is:

What does each object mean?

What does each identifier identify?

Which assertions belong to which entity?

Where did each assertion come from?

Which relationships already exist?

Where does each assertion apply?

What information needs can be resolved?

Serialization comes later.

16.4 Data Normalization

Source data frequently arrives in forms designed for data exchange rather than public semantic publishing.

For example:

CNTRCT_ID
PLAN_ID
SEGMENT_ID
PREMIUM
MOOP_AMT
FIPS

The publisher may normalize these into a stable internal knowledge vocabulary:

contract_id
plan_id
segment_id
monthly_premium
maximum_out_of_pocket
county_fips

Normalization may also include:

datatype normalization;
unit normalization;
enumeration normalization;
identifier normalization;
geographic normalization;
date normalization;
term normalization;
and missing-value handling.

The objective is to create a stable publisher knowledge model before generating the public representation.

16.5 Identity Resolution

Structured source data does not automatically provide sufficient public identity.

For example:

H5521
290
001

may need to become:

contract:H5521

plan:H5521-290

segment:H5521-290-001

The implementation layer should establish stable identity according to the publisher’s domain model.

This is especially important where source identifiers are:

composite;
locally scoped;
reused across entity types;
ambiguous without parent identity;
or different from public canonical-resource URIs.

Entity identity should be resolved before assertions and relationships are serialized around it.

16.6 Provenance Assignment

The implementation pipeline should preserve source lineage as knowledge moves through transformation.

For source-observed knowledge:

CMS PBP
        ↓
Source Record
        ↓
Publisher Normalization
        ↓
DataFragment Assertion

For derived knowledge:

CMS Landscape Records
        ↓
Publisher Selection
        ↓
Publisher Calculation
        ↓
DerivedStatsFragment Assertion

The implementation should not flatten both into:

source = CMS

because the publisher performed materially different roles.

Provenance should be constructed as part of the data pipeline rather than added decoratively after the content has been generated.

16.7 Relationship Construction

Many important relationships already exist in publisher systems as database joins or application logic.

For example:

contracts.id
        ↓
plans.contract_id

plans.id
        ↓
segments.plan_id

segments.county_fips
        ↓
counties.fips

The application already knows:

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

WebMEM implementation converts those operational relationships into explicit published semantics where appropriate.

The database join is evidence that the publisher knows the relationship. It is not itself the public representation of that relationship.

16.8 Applicability Modeling

Implementation must identify context that changes whether an assertion applies.

For example:

monthly_premium = 18.50 USD

may depend on:

plan_year = 2026
segment = H5521-290-001
county = 04015

The pipeline should preserve those conditions rather than allowing them to disappear during page generation.

Applicability may be inherited from:

resource context;
SDT context;
Fragment context;
entity relationships;
or assertion-specific context.

The implementation should place context at the broadest semantic level where it remains true.

16.9 Resolution Modeling

Resolvers require another implementation step: determining the resolution structure appropriate to the resource.

For example, a County Medicare Resolver may compose:

County Identity
        ↓
Coverage Option Space
        ↓
Applicable Plan Collections
        ↓
Canonical Continuation Resources

A Contract Resolver may compose:

Contract Identity
        ↓
Carrier
        ↓
Plans
        ↓
Performance
        ↓
Canonical Plan Resources

The Resolver does not require a new underlying database if those relationships already exist.

It requires a publisher-side composition layer capable of exposing them coherently.

16.10 Semantic Data Template Composition

Once the underlying knowledge has been normalized and modeled, it can be composed into an SDT.

Conceptually:

Publisher Knowledge
        ↓
Select Resource-Relevant Knowledge
        ↓
Assign Fragment Classes
        ↓
Bind Entity Identity
        ↓
Add Assertions
        ↓
Add Provenance
        ↓
Add Relationships
        ↓
Add Context
        ↓
Compose SDT

The SDT is therefore not the source of the knowledge.

It is the resource-scoped machine representation of publisher knowledge.

16.11 Inline Datasets Changed the Architecture

One of the most consequential implementation developments was recognizing that the machine-facing dataset did not need to live at a separate endpoint.

The dataset could be published inline with the resource it describes.

Conceptually:

Web Page
│
├── Human Representation
│
└── Inline Dataset
    │
    └── WebMEM SDT

This has several architectural advantages.

The machine representation:

travels with the canonical resource;
inherits the resource’s publication lifecycle;
can be generated from the same source data;
can be cached with the same document;
does not require endpoint discovery;
does not require content negotiation;
does not require a parallel routing system;
and reduces the risk of human and machine resources drifting independently.

The machine dataset becomes part of the page rather than a satellite around it.

16.12 Inline Does Not Mean Visible

The WebMEM representation is published inside the HTML document without becoming part of the normal visual interface.

Using inert HTML structures allows the publisher to maintain:

One Document
        ↓
Two Representations

Human Representation
        +
Machine Representation

The machine representation does not need to distort page layout, duplicate visible tables, or force machine syntax into human prose.

This is the practical implementation of two-tier publishing.

16.13 HTML-in-HTML Removes a Parsing Layer

The original implementation used YAML embedded inside HTML.

Conceptually:

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

The current HTML-in-HTML serialization simplifies the path:

HTML Document
        ↓
Parse DOM
        ↓
Locate WebMEM SDT
        ↓
Interpret WebMEM Structure

The representation remains inert to the human interface while using the native structural language of the document itself.

This reduces implementation complexity and removes the need for a second embedded syntax parser.

16.14 A Minimal HTML-in-HTML Structure

Conceptually, an implementation 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="resource-identity"
    data-entity-id="example:entity">

    ...

  </template>

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

    ...

  </template>

</template>

The exact serialization requirements are defined by the WebMEM HTML serialization specification.

The important implementation principle is that the SDT exists as structured HTML within the canonical document.

16.15 Inline Dataset Generation Can Be Dynamic

WebMEM does not require publishers to hand-author SDTs.

For data-rich resources, generation should often be programmatic.

For example:

CMS Source Data
        ↓
Python Pipeline
        ↓
Normalized Publisher Data
        ↓
Database
        ↓
Page Request
        ↓
SDT Serializer
        ↓
Inline WebMEM

or:

CMS Source Data
        ↓
Build Pipeline
        ↓
Precomputed Resource Data
        ↓
Static Page Generation
        ↓
Inline WebMEM

Both are valid architectural patterns.

The protocol defines the representation.

It does not require one generation method.

16.16 Inline Dataset Generation Can Be Static

A static publishing system may generate the complete human and machine representations during a build.

Source Files
        ↓
Build Process
        ↓
Knowledge Transformation
        ↓
Human HTML
        +
WebMEM SDT
        ↓
Static HTML Resource

This may be appropriate for:

documentation;
research publications;
public datasets;
glossaries;
low-volatility directories;
and archival resources.

16.17 Inline Dataset Generation Can Be CMS-Driven

A content-management system can generate WebMEM at render time or publication time.

For example:

WordPress
│
├── Post / Page Content
├── Custom Fields
├── Custom Database Tables
├── Global Options
├── External Data Pipeline
└── WebMEM Serializer
        ↓
Canonical HTML Response

The serializer may be implemented through:

a plugin;
a theme component;
a rendering service;
a middleware layer;
or another publisher-controlled mechanism.

The implementation detail is secondary to semantic correctness.

16.18 Inline Dataset Generation Can Be Application-Driven

Modern web applications may generate the same representation from application state.

For example:

Application Data Layer
        ↓
Knowledge Mapper
        ↓
Human Component Tree
        +
WebMEM Component Tree
        ↓
Rendered HTML

The framework does not depend on WordPress, PHP, Python, JavaScript, or any particular runtime.

WebMEM is an output contract, not an application stack.

16.19 FactSmith Demonstrates a Different Implementation Path

Implementation experience also revealed that machine-facing knowledge does not always begin with a clean structured database.

Many publishers begin with existing human-facing content.

That creates a different problem:

Existing Document
        ↓
Contains Knowledge
        ↓
Knowledge Structure Is Implicit
        ↓
Publisher Needs Machine Representation

A knowledge-engineering system can assist by identifying candidate:

entities;
assertions;
definitions;
provenance;
relationships;
applicability;
and Fragment Classes;

and transforming those candidates into a structured representation for publisher review.

This is the implementation problem addressed by systems such as FactSmith.

Conceptually:

Existing Human Content
        ↓
Knowledge Extraction
        ↓
Candidate Semantic Structure
        ↓
Publisher Review / Validation
        ↓
WebMEM Composition
        ↓
HTML-in-HTML Serialization
        ↓
Existing Canonical Resource

This path is fundamentally different from generating WebMEM directly from an authoritative structured data pipeline.

In one case:

Structured Publisher Knowledge
→ WebMEM

In the other:

Human Representation
→ Recover Publisher Knowledge
→ WebMEM

Both may produce a conforming SDT.

But their evidentiary paths are different.

16.20 Fact Extraction Is Not Fact Creation

A retrospective knowledge-engineering system should distinguish between extracting knowledge already supported by the resource and inventing knowledge that merely appears plausible.

For example, a document may state:

“The plan has a $4,900 maximum out-of-pocket limit for covered in-network services.”

A candidate extraction might produce:

Subject:
plan:X

Field:
maximum_out_of_pocket

Value:
4900

Unit:
USD

Scope:
covered in-network services

That is an attempt to structure knowledge present in the source.

By contrast, generating:

Source:
CMS PBP 2026

when the document provides no evidence for that lineage would add unsupported provenance.

Knowledge extraction may make implicit structure explicit. It must not manufacture evidence.

16.21 Retrospective Structuring Requires Review

Existing prose was written for human interpretation.

It may contain:

pronouns;
implied subjects;
ambiguous scope;
rounded values;
editorial shorthand;
unstated relationships;
and contextual assumptions supplied by surrounding layout.

Automated extraction may therefore produce candidate knowledge that requires validation.

For example:

Text:
"The premium is $18.50."

Candidate:
monthly_premium = 18.50 USD

Before publication, the system may still need to determine:

Whose premium?

Which Plan?

Which Segment?

Which year?

Which geography?

What source?

What premium type?

Human-readable certainty does not always equal machine-level semantic completeness.

16.22 Structured-Data Generation and Content Extraction Should Not Be Confused

A data-driven WebMEM pipeline may possess stronger source semantics than a retrospective extraction system.

For example:

CMS Record
        ↓
Known Contract ID
Known Plan ID
Known Segment ID
Known County
Known Field
Known Source
        ↓
WebMEM

requires relatively little semantic reconstruction.

By contrast:

Published Article
        ↓
Natural Language
        ↓
Entity Recognition
        ↓
Assertion Extraction
        ↓
Context Recovery
        ↓
Provenance Recovery
        ↓
WebMEM

contains more interpretive steps.

The implementation architecture should preserve that distinction because confidence and validation requirements differ.

16.23 Three Primary Implementation Paths

The current framework therefore recognizes at least three broad implementation paths.

Path A: Structured-Data Native

Authoritative / Publisher Data
        ↓
Normalization
        ↓
Knowledge Model
        ↓
WebMEM Generation
        ↓
Inline Publication

This is appropriate where the publisher already possesses structured data with stable identity, provenance, and relationships.

Path B: Content-Derived

Existing Human Content
        ↓
Knowledge Extraction
        ↓
Semantic Review
        ↓
WebMEM Generation
        ↓
Inline Publication

This is appropriate for large existing content libraries where rebuilding the underlying editorial system is impractical.

Path C: Hybrid

Structured Data
        +
Editorial Content
        ↓
Knowledge Reconciliation
        ↓
WebMEM Generation
        ↓
Inline Publication

This is often the most realistic architecture.

The structured system may provide identity and factual assertions.

The editorial system may provide:

definitions;
policy explanations;
procedures;
recommendations;
citations;
and contextual knowledge.

The implementation layer combines them without pretending they share the same provenance.

16.24 Hybrid Publishing Reflects Real Publisher Systems

Many production resources are already assembled from several knowledge sources.

For example:

County Medicare Resource
│
├── CMS Landscape
├── CMS PBP
├── CMS Performance
├── CMS Enrollment
├── Publisher-Derived Statistics
├── Editorial Explanations
└── Publisher Routing / Relationships

The human page combines those sources into one experience.

The SDT can preserve their different semantic responsibilities:

IdentityFragment
→ County Identity

IndexFragment
→ Applicable Plans

DataFragment
→ Source-Observed Facts

DerivedStatsFragment
→ Publisher Calculations

DefinedTermFragment
→ Domain Terminology

MetaFragment
→ Source Metadata

Composition allows one resource to expose a coherent knowledge representation without flattening all of its knowledge into one provenance model.

16.25 Inline Datasets Can Be Built From the Same Data as the Human Page

Where practical, the human and machine representations should draw from the same normalized publisher knowledge.

Conceptually:

Normalized Publisher Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      WebMEM
Renderer   Serializer
   ↓         ↓
Human      Machine
HTML       HTML
   └────┬────┘
        ↓
Canonical Document

This architecture substantially reduces the risk of factual drift between the two publishing tiers.

If the premium changes in the source knowledge, both representations can change from the same underlying value.

If the Plan-to-Segment relationship changes, both representations can receive the same updated relationship.

Two-tier publishing should not mean two independent sources of truth.

16.26 Inline Datasets Should Not Be Scraped Back From the Human Page When Better Data Exist

A publisher that already possesses structured source knowledge should generally avoid reconstructing the SDT by scraping its own rendered page.

For example:

Database
→ Human Table
→ Parse Human Table
→ Reconstruct Data
→ WebMEM

introduces unnecessary loss and interpretation.

A stronger architecture is:

Database
        ↓
Normalized Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      WebMEM
Table      SDT

Retrospective extraction is valuable when structured knowledge is unavailable.

It should not replace better upstream knowledge when that knowledge already exists.

16.27 Inline Dataset Scope Should Follow Resource Scope

The SDT should represent the knowledge appropriate to the canonical resource.

A county resource does not need to contain every fact known about every Plan it references.

A Contract Resolver does not need to reproduce every Plan benefit.

A glossary resource does not need to contain the entire domain ontology.

Conceptually:

Publisher Knowledge Universe
        ↓
Resource Scope
        ↓
Relevant Knowledge Projection
        ↓
SDT

This prevents inline datasets from becoming uncontrolled database dumps.

16.28 Inline Dataset Size Is an Architectural Concern

Because WebMEM travels inside the canonical HTML document, publishers should consider representation size.

The objective is not to minimize machine knowledge arbitrarily.

But unnecessary duplication can increase:

document size;
generation cost;
cache size;
parsing cost;
validation complexity;
and synchronization risk.

Resource-scoped composition, canonical references, and relationship-based continuation help control size without sacrificing semantic integrity.

Publish enough knowledge to make the resource semantically sufficient—not every record the publisher owns.

16.29 Canonical Continuation Reduces Duplication

Suppose a County Resolver identifies 42 Plans.

The Resolver may need:

Plan Identity
Plan Name
Plan Type
Applicable Relationship
Selected Comparison Fields
Canonical Resource

It may not need:

Every Benefit
Every Formulary Field
Every Provider Relationship
Every Historical Record

Instead:

County Resolver
        ↓
Plan Identity
        ↓
canonicalResource
        ↓
Plan Resource

allows resolution to continue where deeper Plan knowledge belongs.

16.30 Implementation Should Preserve Determinism Where Possible

For structured-data-native publishing, equivalent source knowledge should produce equivalent machine representations.

Conceptually:

Same Normalized Input
        +
Same Template / Serializer Version
        ↓
Same Material WebMEM Semantics

This makes implementations easier to:

test;
debug;
version;
compare;
audit;
and regenerate.

Generative systems may assist with knowledge engineering, but deterministic serialization is generally preferable once the knowledge structure is known.

16.31 Separate Knowledge Engineering From Serialization

This distinction became increasingly important through implementation.

Knowledge engineering answers:

What is the entity?

What are the assertions?

What is the provenance?

What relationships exist?

Where does the knowledge apply?

What should resolve?

Serialization answers:

How are those semantics represented
in conforming HTML-in-HTML?

These should not be treated as the same problem.

A serializer should not invent the knowledge model while emitting markup.

Ideally:

Knowledge Model
        ↓
Validated Intermediate Representation
        ↓
Serializer
        ↓
WebMEM HTML

This makes serialization replaceable without forcing the publisher to reinvent its knowledge.

16.32 An Intermediate Representation Can Simplify Implementation

A publisher may choose to maintain an internal WebMEM-neutral or WebMEM-oriented representation before serialization.

Conceptually:

Publisher Knowledge
        ↓
Intermediate Semantic Object
        ↓
WebMEM Serializer
        ↓
HTML-in-HTML

The intermediate object might contain:

SDT Identity
Resource Identity
Fragments
Entity Identities
Assertions
Provenance
Relationships
Applicability
Canonical Resources

The protocol does not require one internal format.

The architectural advantage is separation of concerns.

16.33 Template-Driven Generation

Repeated resource types are strong candidates for template-driven SDT generation.

For example:

County Resource Template
        ↓
IdentityFragment Template
IndexFragment Template
Metadata Template
DerivedStats Template
        ↓
Resource Data
        ↓
Rendered SDT

The templates define semantic structure.

The data supplies resource-specific values.

This makes large-scale publication possible without hand-authoring thousands of machine representations.

16.34 Templates Should Encode Semantic Roles, Not Merely Layout

A machine template should not simply mirror the visual sections of a page.

For example:

Human Page:

Hero
Table
Sidebar
FAQ
Footer

does not necessarily imply:

Fragment 1:
HeroFragment

Fragment 2:
TableFragment

Fragment 3:
SidebarFragment

WebMEM Fragment Classes describe knowledge responsibility, not visual layout.

The appropriate machine composition may instead be:

IdentityFragment
IndexFragment
DataFragment
DefinedTermFragment
DerivedStatsFragment
MetaFragment

Machine templates should follow semantics, not CSS.

16.35 Template Versioning

Large-scale implementations should version semantic templates when material structure changes.

For example:

County Resolver Template v1

        ↓

Added explicit Segment relationships

        ↓

County Resolver Template v2

This allows the publisher to determine:

which resources use which template version;
when a semantic change was introduced;
whether regeneration is required;
and which observations correspond to which representation state.

Template versioning therefore supports Temporal Knowledge Integrity and the Publisher Feedback Loop.

16.36 Data Versioning and Template Versioning Are Different

A representation can change because the underlying knowledge changed or because the representation architecture changed.

For example:

DATA CHANGE

premium:
18.50 → 22.00


TEMPLATE CHANGE

Plan → Premium

becomes

Plan → Segment → Premium

The first changes the assertion value.

The second changes the semantic structure through which the assertion is represented.

Both matter.

They should not be conflated into one generic “page updated” event.

16.37 Conformance Validation Belongs in the Build Pipeline

Conformance should not be treated solely as a manual post-publication audit.

Where practical, validation should occur before deployment.

Knowledge Model
        ↓
SDT Generation
        ↓
Serialization
        ↓
Conformance Validation
        ↓
PASS
        ↓
Publish

or:

Conformance Validation
        ↓
FAIL
        ↓
Block / Flag Publication

The appropriate enforcement level depends on domain risk and publisher operations.

16.38 Validation Can Operate at Several Layers

A mature implementation may validate:

Structural Validation

Required SDT identity?
Valid Fragment Class?
Required fragment identity?
Valid nesting?

Datatype Validation

Numeric field contains number?
Date uses expected format?
Boolean is valid?
Unit compatible with field?

Semantic Validation

Assertion attached to correct entity type?
Derived knowledge identified as derived?
Required applicability present?
Relationship semantically valid?

Reference Validation

Referenced entity exists?
Canonical resource valid?
Relationship target resolvable?

Cross-Surface Validation

Same entity identity reused?
Equivalent assertions agree?
Inverse relationships compatible?
Temporal states aligned?

These layers turn WebMEM deployment into a testable publishing process.

16.39 Validation Should Produce Actionable Errors

A validator should ideally report semantic defects in terms the publisher can act upon.

For example:

FAIL

Fragment:
plan-benefits

Assertion:
monthly_premium

Problem:
Assertion attached to Plan identity,
but source record is Segment-scoped.

Expected:
Segment identity or explicit
applicability relationship.

This is more useful than:

Invalid markup.

The goal is not merely syntactic compliance.

It is semantic integrity.

16.40 Publisher Preview and Inspection Tools

Because the WebMEM representation is intentionally non-visual, publishers benefit from inspection tools that make the machine layer visible to humans.

An inspection interface might display:

SDT
│
├── IdentityFragment
│   └── county:04015
│
├── IndexFragment
│   ├── plan:A
│   ├── plan:B
│   └── plan:C
│
├── DataFragment
│   ├── source-observed assertions
│   └── applicable context
│
├── DerivedStatsFragment
│   ├── calculated assertions
│   └── derivation lineage
│
└── MetaFragment
    └── source metadata

The same tool might allow a publisher to inspect an individual assertion:

Assertion:
average_monthly_premium

Value:
15.26 USD

Subject:
county:04015

Fragment Class:
DerivedStatsFragment

Derived:
true

Source:
CMS Landscape

Generated By:
Publisher Calculation

Applicable Period:
2026

This makes the machine-facing representation reviewable without requiring editors, compliance teams, researchers, or developers to inspect raw HTML manually.

16.41 The Machine Layer Needs a Human View

This creates an important implementation principle.

The WebMEM representation is designed for machines.

But the people responsible for publishing it need a way to see it.

Conceptually:

Canonical Resource
        ↓
WebMEM SDT
        ↓
Inspection Layer
        ↓
Human-Readable Knowledge View

The inspection layer does not become another source of truth.

It is a view of the published machine representation.

This allows humans to ask:

What entity did we publish?
What assertions did we make?
What Fragment Classes were used?
What sources support the assertions?
Which values are derived?
What relationships were published?
What applicability context is present?
Where does resolution continue?
and does the machine representation agree with the human resource?

16.42 Inspection Is Different From Generation

The system that displays WebMEM does not need to be the system that generated it.

For example:

Publisher Pipeline
        ↓
Generate WebMEM
        ↓
Publish HTML
        ↓
Independent Inspector
        ↓
Parse DOM
        ↓
Display SDT

This separation has an important advantage.

The inspector can evaluate what was actually published rather than what the generation system intended to publish.

Inspect the artifact at the public boundary.

16.43 Inspection Can Support Conformance

An inspection tool may combine visualization with validation.

For example:

IdentityFragment
        PASS

IndexFragment
        PASS

DataFragment
        PASS

DerivedStatsFragment
        WARNING

Problem:
derived assertion lacks
explicit generation method

Relationship Integrity
        PASS

Applicability
        PASS

This allows the machine layer to become inspectable as both:

Knowledge

and

Implementation

A publisher can see not only whether markup exists, but whether the represented semantics are complete enough for the intended use.

16.44 Inspection Can Support Human/Machine Comparison

A more advanced inspection interface may place the human and machine representations side by side.

For example:

HUMAN PAGE

Average Monthly Premium:
$15.26


WEBMEM

average_monthly_premium:
15.26 USD

derived:
true

source:
CMS Landscape

generatedBy:
Publisher Calculation

The comparison can reveal:

missing machine assertions;
values that disagree;
different entity scope;
missing provenance;
missing applicability;
and knowledge present in one representation but absent from the other.

This directly supports two-tier publishing governance.

16.45 Inspection Tools Can Support Editorial Workflows

Machine-facing publishing should not remain exclusively a developer concern.

Different stakeholders may need different views.

For example:

EDITOR

What definitions are published?
What factual claims are represented?


DATA ENGINEER

Which source fields produced
these assertions?


COMPLIANCE REVIEWER

What source supports this claim?
Is it derived?
Where does it apply?


DEVELOPER

Is the SDT conforming?
Are references valid?


KNOWLEDGE ARCHITECT

Are identities, relationships,
and Fragment Classes correct?

The same underlying SDT can support each review perspective.

16.46 FactSmith as a Knowledge Engineering Layer

A system such as FactSmith can sit between human content, publisher data, and the WebMEM representation.

Its role is not merely to generate markup.

Its more important role is to assist with the transformation:

Information
        ↓
Knowledge
        ↓
Explicit Semantic Structure
        ↓
WebMEM

Depending on the implementation, such a system may assist with:

entity identification;
fact extraction;
term identification;
Fragment Class selection;
relationship discovery;
provenance capture;
applicability detection;
SDT composition;
validation;
and publisher review.

The distinction between assistance and authority remains important.

The knowledge-engineering tool can propose structure. The publisher remains responsible for what it publishes.

16.47 FactSmith and Structured Publisher Data

FactSmith-style knowledge engineering is not limited to extracting facts from prose.

Structured inputs can also require semantic interpretation.

For example:

Input Table:

CNTRCT_ID
PLAN_ID
SEGMENT_ID
PREMIUM
FIPS

contains structure.

But the WebMEM knowledge model still needs to understand:

CNTRCT_ID
→ identifies Contract

PLAN_ID
→ participates in Plan identity

SEGMENT_ID
→ participates in Segment identity

FIPS
→ identifies Geography

PREMIUM
→ assertion attached to
  applicable subject

Structured data reduces extraction work.

It does not eliminate knowledge engineering.

16.48 The Source Schema Is Not Automatically the Knowledge Model

This distinction is especially important when implementing WebMEM from external datasets.

A source schema describes how the source publisher organized its data.

That organization may reflect:

database constraints;
legacy systems;
file-transfer requirements;
administrative processes;
reporting conventions;
or historical implementation decisions.

The public knowledge model may need to interpret those fields differently.

For example:

Source Columns
        ↓
Domain Interpretation
        ↓
Entity Model
        ↓
Relationship Model
        ↓
WebMEM Representation

Do not confuse the shape of a source file with the shape of the knowledge.

16.49 FactSmith and the Publisher Feedback Loop

The knowledge-engineering layer can also participate in the Publisher Feedback Loop.

For example:

Observed Reflection:
Plan-level premium generalized
across geography

        ↓

Diagnosis:
Segment applicability insufficiently
represented

        ↓

Knowledge Engineering Review:
identify Segment relationships

        ↓

Revised SDT:
Plan
→ hasSegment
→ Segment
→ appliesIn
→ County

        ↓

Validate
        ↓
Publish
        ↓
Observe Again

The system does not retrain the external machine.

It helps the publisher improve the reference.

16.50 Implementation Can Begin Small

A publisher does not need to convert an entire domain at once.

A minimal implementation might begin with one resource type and a small number of Fragment Classes.

For example:

One Resource Type
        ↓
IdentityFragment
        ↓
DataFragment
        ↓
MetaFragment
        ↓
HTML-in-HTML
        ↓
Validation

Once that representation is stable, the publisher may add:

Relationships
        ↓
Applicability
        ↓
Defined Terms
        ↓
Derived Knowledge
        ↓
Resolver Composition
        ↓
Cross-Surface Validation

This allows implementation maturity to grow with the publisher’s knowledge-engineering capability.

16.51 A Minimal Viable WebMEM Deployment

The original framework defined a minimal deployment around multi-format digests, glossary endpoints, prompt emission, retrieval logging, and reinforcement publishing.

The current minimal deployment is much smaller.

A minimal WebMEM implementation requires:

a canonical human-facing web resource;
an inline Semantic Data Template;
stable SDT identity;
one or more semantically appropriate Fragments;
explicit entity identity where applicable;
structured assertions;
material provenance;
applicable context;
HTML-in-HTML serialization;
and conformance with the applicable protocol requirements.

It does not require:

a separate semantic subdomain;
JSON-LD digests;
Turtle;
Markdown mirrors;
content negotiation;
GitHub syndication;
podcast reinforcement;
prompt injection;
or model-specific publishing.

The minimum viable implementation is a correctly represented machine knowledge layer inside the canonical resource.

16.52 A Mature WebMEM Deployment

A mature implementation may add substantially more publisher infrastructure.

For example:

Source Management
        ↓
Normalized Knowledge Store
        ↓
Canonical Identity Registry
        ↓
Provenance Model
        ↓
Relationship Model
        ↓
Terminology System
        ↓
Resolver Architecture
        ↓
SDT Template Library
        ↓
Serializer
        ↓
Conformance Validator
        ↓
Cross-Surface Validator
        ↓
Inspection Tools
        ↓
Temporal Versioning
        ↓
Observation Framework

These systems improve scale, governance, auditability, and consistency.

They are implementation capabilities, not prerequisites for publishing one conforming WebMEM resource.

16.53 Implementation Maturity Can Be Staged

A publisher may think of WebMEM adoption in stages.

Stage 1: Representation

One Resource
→ One SDT
→ Correct Fragments
→ Conforming Serialization

Stage 2: Repeatability

Templates
→ Shared Data
→ Automated Generation
→ Validation

Stage 3: Integration

Canonical Identity
→ Provenance
→ Relationships
→ Terminology
→ Applicability

Stage 4: Resolution

Query-to-Resolution Mapping
→ Resolver Resources
→ Canonical Continuation
→ Resolution Coverage

Stage 5: Governance

Cross-Surface Validation
→ Temporal Integrity
→ Change Management
→ Inspection
→ Conformance Enforcement

Stage 6: Observability

Reference
→ Consumer Observation
→ Fidelity Measurement
→ Publisher Feedback Loop

This staged model allows organizations to adopt the architecture without pretending that full knowledge infrastructure must exist on day one.

16.54 WebMEM Can Be Added to Legacy Systems

One of the practical strengths of inline publication is that WebMEM does not require a modern application architecture.

A legacy CMS can implement it.

A static site can implement it.

A server-rendered application can implement it.

A modern JavaScript application can implement it.

A hand-authored HTML resource can implement it.

The requirement is not:

Use modern infrastructure.

It is:

Produce a conforming public representation.

This significantly lowers the adoption barrier.

16.55 WordPress Implementation

A WordPress implementation might use:

WordPress Resource
        ↓
Custom Plugin
        ↓
Publisher Database / APIs
        ↓
Semantic Templates
        ↓
WebMEM Serializer
        ↓
Inline SDT

The plugin may:

retrieve resource-specific data;
construct entity identities;
apply semantic templates;
serialize Fragments;
inject the SDT into the document;
and validate output.

The visible page template can remain independently optimized for human readers.

16.56 Static-Site Implementation

A static-site workflow might use:

Structured Files / Content
        ↓
Build Script
        ↓
Knowledge Model
        ↓
Human Template
        +
WebMEM Template
        ↓
Static HTML

Because the machine representation is contained in the generated document, no runtime semantic endpoint is required.

16.57 Headless Implementation

A headless architecture may use:

CMS / Data Services
        ↓
Application Layer
        ↓
Knowledge Mapper
        ↓
Human Components
        +
WebMEM Components
        ↓
Rendered HTML

The headless CMS does not need native knowledge of WebMEM if the rendering layer can construct the representation from available data.

16.58 Enterprise Knowledge-System Implementation

An organization with an existing knowledge graph or semantic layer may use that system as the upstream source.

Enterprise Knowledge Graph
        ↓
Resource Query / Projection
        ↓
WebMEM Intermediate Representation
        ↓
HTML Serializer
        ↓
Canonical Resource

WebMEM then becomes a publication surface for selected knowledge rather than the organization’s master knowledge repository.

16.59 The Protocol Does Not Require a Central WebMEM Server

The original endpoint architecture implied a centralized semantic service capable of resolving entities and returning multiple formats.

The current protocol does not require such a server.

Each canonical resource may carry its own machine-facing representation.

/resource-a/
→ Human + WebMEM

/resource-b/
→ Human + WebMEM

/resource-c/
→ Human + WebMEM

Relationships and canonical-resource references connect those distributed representations.

The public web itself becomes the distribution layer.

16.60 The Protocol Does Not Require Syndication

The original implementation model treated syndication as part of semantic reinforcement.

The current framework does not require publishers to mirror WebMEM knowledge across external platforms.

A publisher may legitimately syndicate human content, datasets, research, feeds, or other resources for ordinary publishing reasons.

But WebMEM conformance does not depend on:

Substack
Medium
GitHub
Newswire Distribution
Podcast Transcripts
External Mirrors

The canonical resource is sufficient as the WebMEM publication surface.

16.61 The Protocol Does Not Require Multiple Serializations

The original implementation architecture required several representations such as:

JSON-LD
Turtle
Markdown
XML
CSV
HTML

The current WebMEM Protocol defines HTML-in-HTML as the current normative serialization.

Future serializations may be defined.

But publishers should not generate additional formats merely to increase exposure.

Additional serializations should exist because a legitimate interoperability requirement justifies them.

16.62 The Protocol Does Not Require Content Negotiation

Because the machine representation is available inside the canonical HTML resource, HTTP content negotiation is not required for basic WebMEM publication.

The consuming system can retrieve:

GET /canonical-resource/

and receive:

Human HTML
+
WebMEM SDT

This substantially simplifies deployment.

16.63 The Protocol Does Not Require AI APIs

Publishing WebMEM does not require a publisher to call an external language-model API.

A completely deterministic system may generate WebMEM from structured publisher data.

AI-assisted knowledge engineering is optional.

For example:

STRUCTURED-DATA PATH

Source Data
        ↓
Deterministic Transformation
        ↓
Validated Knowledge Model
        ↓
Deterministic Serializer
        ↓
WebMEM

may require no generative AI at all.

By contrast:

CONTENT-DERIVED PATH

Human Content
        ↓
AI-Assisted Knowledge Extraction
        ↓
Candidate Knowledge
        ↓
Validation / Review
        ↓
Deterministic Serializer
        ↓
WebMEM

may benefit substantially from language-model capabilities.

The AI assists with interpretation.

It does not become the authority for the published knowledge.

16.64 AI Assistance and Deterministic Publication Can Coexist

This separation produces a useful architecture.

Generative systems are well suited to tasks such as:

identifying candidate entities in prose;
extracting candidate assertions;
recognizing definitions;
suggesting Fragment Classes;
identifying possible relationships;
detecting contextual qualifiers;
and proposing structured interpretations of existing content.

Deterministic systems are better suited to tasks such as:

constructing stable identifiers;
normalizing datatypes;
applying known source mappings;
serializing validated knowledge;
running conformance checks;
and reproducing equivalent output from equivalent inputs.

A mature implementation can therefore use:

Probabilistic Assistance
        ↓
Semantic Review
        ↓
Validated Knowledge
        ↓
Deterministic Publication

AI can help discover structure without making the final representation probabilistic.

16.65 Confidence Belongs to the Extraction Process, Not the Fact

AI-assisted extraction may produce confidence signals.

For example:

Candidate Assertion:

monthly_premium = 18.50 USD

Extraction Confidence:
0.93

That score describes the extraction system’s confidence in its interpretation.

It does not mean:

Fact Confidence:
93%

The factual assertion may be completely correct, completely incorrect, or impossible to verify from the available evidence.

Implementation systems should therefore distinguish:

Extraction Confidence
        ≠
Factual Confidence
        ≠
Source Authority

This distinction is especially important when generative systems participate in retrospective knowledge engineering.

16.66 Publisher Approval Can Be Risk-Based

Not every implementation requires human review of every generated assertion.

The appropriate review model depends on:

source quality;
transformation determinism;
domain risk;
semantic complexity;
and whether the knowledge was extracted or directly mapped.

For example:

Authoritative Structured Source
+
Known Deterministic Mapping
+
Validated Output

        ↓

Automated Publication
may be appropriate

while:

Ambiguous Human Prose
+
AI-Extracted Relationship
+
High-Stakes Domain

        ↓

Human Review
may be required

The protocol does not prescribe one approval workflow for every publisher.

The implementation should reflect the evidentiary risk of the transformation.

16.67 FactSmith Can Preserve Evidence Alongside Extraction

A retrospective knowledge-engineering system becomes substantially more useful when candidate knowledge remains connected to the evidence from which it was extracted.

Conceptually:

Source Document
        ↓
Source Passage
        ↓
Candidate Assertion
        ↓
Candidate Entity
        ↓
Candidate Relationship
        ↓
Publisher Review

This allows a reviewer to inspect:

What did the source actually say?

What structure did the system infer?

What evidence supports the inference?

What remains ambiguous?

The review process can then accept, modify, reject, or defer the candidate representation.

Evidence-preserving extraction is stronger than structure generation without traceability.

16.68 FactSmith Can Operate Before WebMEM

FactSmith and WebMEM should not be treated as the same layer.

Conceptually:

FactSmith
→ Knowledge Engineering

WebMEM
→ Knowledge Publication

A FactSmith-style system may produce structured knowledge that is later:

stored in a database;
reviewed by an editor;
used by an application;
published through WebMEM;
or consumed by another publisher system.

Likewise, WebMEM can be implemented without FactSmith when the publisher already possesses sufficiently structured knowledge.

The systems complement one another without creating a dependency.

16.69 The Knowledge Pipeline Can Become a Reusable Publisher Asset

Once a publisher has normalized identity, terminology, provenance, relationships, and applicability, those structures can serve more than one output.

For example:

Publisher Knowledge Model
        │
        ├── Human Web Pages
        ├── WebMEM
        ├── Internal Applications
        ├── APIs
        ├── Data Exports
        ├── Research
        └── Quality Assurance

This means WebMEM implementation can expose weaknesses in the publisher’s existing information architecture while also creating reusable infrastructure.

The value is not limited to the final HTML serialization.

16.70 WebMEM Should Be Generated as Close to the Source of Truth as Practical

The more transformations between publisher knowledge and WebMEM, the more opportunities exist for semantic drift.

For example:

Database
→ API
→ JavaScript State
→ Human Table
→ HTML Scraper
→ WebMEM

contains several avoidable transformations if the original database already provides the required knowledge.

A stronger architecture may be:

Normalized Publisher Knowledge
        ↓
WebMEM Serializer

or:

Normalized Publisher Knowledge
        ↓
Shared Intermediate Representation
        ↓
Human Renderer
        +
WebMEM Serializer

Generate from knowledge, not from presentation, whenever the knowledge is available.

16.71 Publication-Time Generation Versus Request-Time Generation

Publishers may generate WebMEM at different points in the publishing lifecycle.

For example:

Publication-Time

Content / Data Updated
        ↓
Generate SDT
        ↓
Validate
        ↓
Store / Publish HTML

Request-Time

HTTP Request
        ↓
Load Current Knowledge
        ↓
Generate SDT
        ↓
Render HTML Response

Build-Time

Build Trigger
        ↓
Load Knowledge
        ↓
Generate Resources
        ↓
Validate
        ↓
Deploy Static HTML

Each model has operational tradeoffs.

WebMEM does not require one.

The important requirement is that the public representation accurately reflects the applicable publisher knowledge.

16.72 Caching Must Include the Machine Layer

If a page is cached, the WebMEM representation is cached with it.

This is normally an advantage of inline publication.

But cache invalidation must account for changes to machine-facing knowledge.

For example:

Source Updated
        ↓
Database Updated
        ↓
SDT Regenerated
        ↓
Page Cache NOT Cleared

        ↓

Public WebMEM:
STALE

The publisher should treat machine-layer changes as publication changes for caching purposes.

This connects implementation directly to Temporal Knowledge Integrity.

16.73 Partial Cache Invalidation May Be Possible

Large publishing systems may know which resources depend on a changed source record.

For example:

Changed Plan:
H5521-290

Affected:
├── Plan Resource
├── County Resolver A
├── County Resolver B
├── Contract Resolver
└── Comparison Resource

Dependency-aware cache invalidation can update only the affected resources.

This becomes increasingly valuable at scale.

16.74 Scale Changes the Engineering Problem, Not the Protocol

A single glossary resource and a national directory containing millions of assertions may use the same WebMEM concepts.

What changes is the implementation infrastructure.

At small scale:

Human Author
        ↓
Semantic Template
        ↓
WebMEM

At large scale:

Multiple Source Systems
        ↓
ETL / Normalization
        ↓
Knowledge Store
        ↓
Identity Registry
        ↓
Template Engine
        ↓
Serializer
        ↓
Validator
        ↓
Cache / CDN
        ↓
Millions of Published Resources

The protocol should not require enterprise infrastructure merely because enterprise implementations may need it.

16.75 Scale Makes Validation More Important

A semantic error in one manually authored resource affects one resource.

A semantic error in a template may affect thousands or millions.

For example:

Template Defect:

monthly_premium
attached to Plan
instead of Segment

        ↓

Generated Across:
3,000+ geographic resources

Automation magnifies both correctness and error.

Large-scale generation therefore increases the importance of:

template validation;
sample inspection;
automated semantic tests;
cross-surface checks;
version control;
and rollback capability.

16.76 Deployment Should Support Rollback

A publisher may discover after deployment that a new semantic template contains a material defect.

A mature implementation should be able to identify:

What changed?

Which template version changed?

Which resources were affected?

Which data version was used?

Can the previous representation
be restored?

Rollback capability is particularly important in high-stakes domains.

16.77 Observability Begins With Publisher Logs

Before observing external machines, the publisher should be able to observe its own WebMEM system.

Operational logging may include:

generation success and failure;
template version;
data version;
validation results;
publication time;
cache state;
resource identity;
and regeneration reason.

For example:

Resource:
https://example.org/resource/

SDT:
resource/#webmem

Generated:
2026-08-25T10:14:00

Data Version:
2026-08

Template Version:
county-resolver-2.1

Validation:
PASS

Reason:
source_update

This gives the Publisher Feedback Loop a reliable internal reference history.

16.78 External Observation Is a Separate System

Consumer observation should remain separate from WebMEM generation.

Conceptually:

PUBLISHING SYSTEM

Knowledge
→ WebMEM
→ Validation
→ Publication


OBSERVATION SYSTEM

Published Reference
→ Query Set
→ Consumer Reflection
→ Fidelity Measurement

The publisher does not need an observation system to publish conforming WebMEM.

Likewise, failure of an external consumer to reflect the representation does not make the WebMEM serialization itself non-conforming.

16.79 Implementation Should Preserve the Publisher-Consumer Boundary

The complete architecture can therefore be divided clearly:

PUBLISHER CONTROL

Source Data
        ↓
Knowledge Engineering
        ↓
Publisher Knowledge Model
        ↓
SDT Composition
        ↓
Serialization
        ↓
Validation
        ↓
Publication

────────────────────────────
      PUBLISHER BOUNDARY
────────────────────────────

EXTERNAL CONSUMERS

Discovery
Retrieval
Parsing
Interpretation
Resolution
Synthesis
Citation
Action

Observation crosses the boundary only in the sense that the publisher can inspect outputs produced on the other side.

Control does not.

16.80 Implementation Should Fail Safely

If the publisher cannot establish a material semantic fact reliably, the system should not manufacture it merely to complete the SDT.

For example:

Entity Identity:
known

Premium:
known

Geographic Applicability:
unknown

should not automatically become:

Premium:
applies everywhere

Likewise:

Source:
unknown

should not become:

Source:
CMS

because CMS is the likely source.

Depending on the applicable conformance requirements, the implementation may:

omit unsupported optional knowledge;
mark a resolution state as unresolved;
flag the representation for review;
or block publication.

Incomplete knowledge is preferable to fabricated certainty.

16.81 Implementation Should Preserve Null, Unknown, and Not Applicable

Data systems often collapse several distinct states into an empty field.

For example:

null

might mean:

Unknown

Not Reported

Not Applicable

Not Yet Available

Suppressed

Missing Due to Error

Where those distinctions materially affect interpretation, the publisher should preserve them.

A machine should not be forced to interpret absence as zero, false, or not applicable.

16.82 Zero Is Data

This is particularly important for numeric fields.

monthly_premium = 0 USD

is not equivalent to:

monthly_premium = null

or:

monthly_premium = unknown

Likewise:

plan_count = 0

is semantically different from a missing Plan count.

Implementation pipelines should preserve these distinctions through normalization, storage, template rendering, and serialization.

16.83 Derived Zero Is Still Derived

A calculated value of zero should retain its derivation lineage just like any other derived value.

For example:

Plans With Feature:
0

Total Applicable Plans:
42

Derived Share:
0%

The value being zero does not make provenance unnecessary.

16.84 Implementation Should Preserve Ordering Only When Ordering Has Meaning

Some collections are unordered:

Plans available in County X

Others may have meaningful order:

Procedure Steps

Ranked Results

Chronological Events

The serializer should not imply semantic order merely because HTML elements appear sequentially.

Where order matters, the knowledge model should represent it explicitly according to the applicable Fragment Class or profile.

16.85 Implementation Should Preserve Collection Semantics

A collection may represent:

Complete Set

Selected Examples

Top Results

Applicable Members

Historical Members

Recommended Members

These are not equivalent.

If an IndexFragment claims to represent all applicable Plans in a County, omission of members is materially different from an editorial list of selected Plans.

The implementation should preserve the collection’s semantic scope.

16.86 Implementation Should Distinguish Observation From Recommendation

A source-observed collection might state:

Applicable Plans:
A
B
C

A publisher recommendation might state:

Recommended Plans:
A
C

Both may be legitimate.

They should not be represented as the same collection.

The first describes the information space.

The second applies publisher judgment.

This distinction should exist before serialization.

16.87 Testing Should Include Semantic Edge Cases

Happy-path examples are not sufficient for validating a machine-facing knowledge system.

Implementations should deliberately test cases where semantic distinctions are easiest to lose.

Examples include:

zero versus null;
unknown versus not applicable;
parent versus child identity;
source-observed versus derived knowledge;
current versus historical values;
one entity with multiple applicable contexts;
one identifier type resembling another;
empty collections versus unavailable collections;
complete collections versus selected examples;
ambiguous resolution requiring additional context;
and conflicting source records requiring publisher review.

For example:

TEST:
Plan has two Segments

Segment A:
county = 04015
premium = 18.50 USD

Segment B:
county = 04013
premium = 32.00 USD

EXPECTED:
Premium remains Segment-scoped

FAIL:
Either premium generalized
to parent Plan

Edge-case testing helps determine whether the implementation preserves the knowledge model when simple assumptions stop working.

16.88 Testing Should Include Negative Cases

A validator should test not only what a representation should contain, but what it must not imply.

For example:

Source:
CMS Landscape

Derived Statistic:
average_monthly_premium

EXPECTED:

CMS
→ source of input records

Publisher
→ generator of average


MUST NOT IMPLY:

CMS
→ directly asserted average

Likewise:

Plan
→ hasSegment
→ Segment

MUST NOT IMPLY:

Segment assertion
→ universally applies to Plan

Negative tests are particularly valuable because many semantic failures produce syntactically valid output.

16.89 Testing Should Include Resolution Cases

Query-to-Resolution Mapping can supply implementation tests.

For example:

INFORMATION NEED:
"What is H5521?"

EXPECTED PATH:
H5521
→ CMS Contract ID
→ contract:H5521

or:

INFORMATION NEED:
"What plans belong to H5521?"

EXPECTED PATH:
contract:H5521
→ hasPlan
→ Plan Collection

or:

INFORMATION NEED:
"What is Plan X's premium
in Mohave County?"

EXPECTED PATH:
Plan
→ Segment
→ County
→ Applicable Segment
→ Premium

The implementation does not need to contain the natural-language query.

The test asks whether the published knowledge supports the required resolution.

16.90 Testing Should Include Unresolved Cases

Some of the most important tests verify that the system does not resolve knowledge prematurely.

For example:

Plan:
H5521-290

Segments:
001 → premium = 18.50 USD
002 → premium = 32.00 USD

Known Geography:
none

EXPECTED:
UNRESOLVED

Required Context:
geography

A failing implementation might produce:

premium = 18.50 USD

simply because Segment 001 appeared first.

A correct implementation must be capable of preserving uncertainty when the knowledge does not support one applicable answer.

16.91 Testing Should Include Human/Machine Alignment

Two-tier publishing creates another class of test.

The human and machine representations should be compared for material semantic agreement.

For example:

HUMAN:
Average premium = $15.26

MACHINE:
average_monthly_premium = 15.26 USD

RESULT:
PASS

versus:

HUMAN:
42 plans available

MACHINE:
plan_count = 39

RESULT:
FAIL

Alignment tests may compare:

factual values;
entity scope;
collection membership;
temporal context;
geographic context;
definitions;
and provenance disclosures.

Not every sentence on the human page needs a machine equivalent.

The test concerns material knowledge represented in both layers.

16.92 Testing Should Include Cross-Surface Integrity

Once multiple resources participate in the same knowledge environment, tests should cross resource boundaries.

For example:

Contract Resolver:

contract:H5521
→ hasPlan
→ plan:H5521-290


Plan Resource:

plan:H5521-290
→ belongsToContract
→ contract:H5521

RESULT:
PASS

or:

County Resolver:

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


Plan Resource:

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

RESULT:
FAIL

These tests help ensure that distributed inline datasets behave as parts of one coherent publisher knowledge environment.

16.93 Testing Should Include Temporal Integrity

Temporal tests may verify:

Current source version?
Applicable period present?
Historical values preserved correctly?
Superseded relationships identified?
Derived values regenerated after input change?
Cache exposes current representation?

For example:

Source Version:
2026-08

Generated SDT:
2026-08

Public Cache:
2026-07

RESULT:
FAIL — stale public representation

This extends validation beyond the serializer into the publication pipeline.

16.94 Testing Should Include Template Regression

Template-driven systems should maintain regression tests around known semantic cases.

For example, before deploying a new County Resolver template:

TEST SET

County with zero plans
County with one plan
County with many plans
Plan with one Segment
Plan with multiple Segments
Zero-dollar premium
Unknown premium
Derived statistic
Missing optional source
Historical source period
Canonical continuation

The new template should preserve the expected semantics across the complete test set.

This is particularly important because one template change may affect thousands of resources.

16.95 Testing Should Include Real Production Samples

Synthetic fixtures are useful but cannot represent every irregularity in real publisher data.

A mature deployment should also inspect representative production resources.

Samples may include:

high-volume resource types;
known edge cases;
resources with complex relationships;
resources containing derived knowledge;
resources with multiple source datasets;
and resources previously associated with semantic defects.

Automated validation and human inspection complement one another.

16.96 Testing the Published Artifact Matters

A generation pipeline may pass every internal test while the public artifact is still wrong.

For example:

Generator:
PASS

Serializer:
PASS

Validator:
PASS

        ↓

CMS Plugin Conflict
or
HTML Filter
or
Cache Layer

        ↓

Published Artifact:
BROKEN

Therefore, a complete implementation should periodically validate the HTML actually served at the canonical resource.

This closes the gap between:

What the publisher intended to publish

and

What the machine can actually retrieve.

16.97 Deployment Architecture Can Remain Simple

Despite the engineering depth described in this Part, a basic WebMEM deployment can remain operationally simple.

For example:

Database
        ↓
PHP Serializer
        ↓
WordPress Page
        ↓
Inline SDT

or:

CSV
        ↓
Python Script
        ↓
Static HTML
        ↓
Inline SDT

or:

Editorial Page
        ↓
FactSmith
        ↓
Reviewed Semantic Structure
        ↓
Inline SDT

The surrounding architecture becomes more sophisticated only as scale, risk, data complexity, and governance requirements increase.

16.98 The Implementation Architecture Is Intentionally Decentralized

WebMEM does not require publishers to send knowledge to a central WebMEM registry.

It does not require a WebMEM API gateway.

It does not require a shared database.

It does not require a central knowledge graph.

The publication model is decentralized:

Publisher A
→ its canonical resources
→ its WebMEM representations

Publisher B
→ its canonical resources
→ its WebMEM representations

Publisher C
→ its canonical resources
→ its WebMEM representations

Each publisher remains responsible for its own knowledge.

Consumers encounter the representation at the resource where that knowledge is published.

16.99 Decentralization Makes Provenance More Important

A decentralized knowledge environment does not have one central authority deciding which assertion is true.

Different publishers may legitimately publish:

different observations
different methodologies
different derived statistics
different recommendations
different interpretations

WebMEM does not eliminate those differences.

It makes their lineage more recoverable.

For example:

Publisher A
→ derived statistic
→ Method A
→ Source X


Publisher B
→ derived statistic
→ Method B
→ Source X

The values may differ without either representation necessarily being malformed.

Provenance allows the consumer to understand why.

16.100 Inline Publication Changes the Deployment Economics

The original framework implied that publishers might need to build and operate:

semantic endpoint infrastructure;
content-negotiation services;
multiple serialization pipelines;
external repositories;
syndication systems;
and reinforcement infrastructure.

Inline WebMEM removes those requirements from the core deployment.

A publisher that can generate HTML can, in principle, publish WebMEM.

The additional engineering burden moves toward:

Knowledge Modeling
Validation
Governance

rather than:

New Distribution Infrastructure

This is an important architectural and economic change.

16.101 The Hard Part Is No Longer Distribution

Once the machine representation travels inside the canonical document, distribution becomes ordinary web publishing.

The difficult questions become:

What is the entity?

Which assertions belong to it?

Where did they come from?

Which are derived?

How do the entities relate?

Where does the knowledge apply?

What remains ambiguous?

What can be resolved?

How should the resource be composed?

Those are knowledge-engineering questions.

The infrastructure became simpler because the intellectual problem became clearer.

16.102 Implementation Is Now a Final-Mile Knowledge Problem

Part 12 described WebMEM as addressing a final-mile knowledge problem.

The implementation architecture makes that concrete.

Publisher Already Has:

Data
Identity
Relationships
Sources
Rules
Context

        ↓

Traditional Final Mile:

Render Human Page

        ↓

WebMEM Final Mile:

Render Human Page
+
Preserve Machine Knowledge

The publisher is not creating an entirely new knowledge system at the edge.

It is preventing known semantics from disappearing at the final publication step.

16.103 The Implementation Principle

The complete implementation strategy can be reduced to one principle:

Generate the machine representation from the best publisher knowledge available, validate it, and publish it inline with the canonical human resource.

If structured knowledge exists, use it.

If only human content exists, recover knowledge carefully.

If both exist, reconcile them.

If provenance is known, preserve it.

If a relationship is known, represent it.

If applicability is known, retain it.

If resolution requires additional context, preserve the unresolved state.

If the knowledge cannot be established, do not invent it.

16.104 From Endpoint Architecture to Inline Knowledge Architecture

The evolution from the original implementation model can now be stated directly.

IMPLEMENTATION MODEL — 2025

Human Web Resource
        ↓
Separate Semantic Digests
        ↓
JSON-LD
TTL
Markdown
XML
CSV
        ↓
Content Negotiation
        ↓
External Repositories
        ↓
Syndication
        ↓
Reinforcement
        ↓
AI Retrieval


IMPLEMENTATION MODEL — 2026

Publisher Knowledge
        ↓
Knowledge Engineering
        ↓
Semantic Data Template
        ↓
HTML-in-HTML
        ↓
Canonical Web Resource
│
├── Human Representation
└── Machine Representation
        ↓
Validation
        ↓
Ordinary Web Publication

The first model built infrastructure around the machine.

The second extends the publisher’s existing infrastructure to preserve machine-readable meaning.

16.105 What FactSmith Changed

FactSmith adds another important lesson to this evolution.

WebMEM initially assumed that publishers would deliberately construct structured knowledge before publication.

In reality, much of the world’s valuable knowledge already exists inside human documents.

That creates two implementation directions:

FORWARD

Structured Knowledge
→ WebMEM


REVERSE

Human Document
→ Knowledge Engineering
→ WebMEM

FactSmith demonstrates the reverse path.

The two paths can meet at the same publisher knowledge layer:

Structured Data ──────┐
                      │
Human Content ────────┼→ Publisher Knowledge
                      │
Editorial Input ──────┘
                              ↓
                         WebMEM SDT

This significantly expands the practical applicability of the protocol.

16.106 What Inline Datasets Changed

Inline datasets changed the other side of the architecture.

The original problem was:

Where should machine knowledge live?

The current answer is:

With the resource whose knowledge
it represents.

This creates a compact publishing architecture:

Knowledge Source
        ↓
Knowledge Engineering
        ↓
Human Representation
        +
Machine Representation
        ↓
One Canonical Resource

The machine layer no longer needs a separate destination merely because it has a different interpreter.

16.107 Implementation and Two-Tier Publishing

Two-tier publishing can therefore be implemented from one underlying knowledge system:

UNDERLYING KNOWLEDGE
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
Renderer   Serializer
   ↓         ↓
Human      WebMEM
Content    SDT
   └────┬────┘
        ↓
Canonical HTML Document

This may be the simplest complete expression of the current architecture.

Humans receive explanation.

Machines receive explicit semantic structure.

Both receive representations of the same underlying publisher knowledge.

16.108 Implementation Is a Publisher Capability

The original framework imagined Memory-First infrastructure partly as a specialized optimization service.

The current architecture points toward something more fundamental.

Machine-facing knowledge publication becomes a publisher capability.

Just as mature publishers developed capabilities for:

content management;
structured data;
accessibility;
analytics;
search optimization;
and data governance;

they may increasingly require capabilities for:

knowledge modeling;
semantic templating;
machine serialization;
provenance preservation;
relationship modeling;
resolution architecture;
conformance validation;
and semantic observability.

This is not merely another distribution channel.

It is an extension of publishing itself.

16.109 A Minimal Implementation Checklist

For a publisher implementing one resource type, the practical sequence may be:

Identify the resource scope.
Identify the underlying entities.
Establish stable entity identity.
Identify material assertions.
Preserve source and derivation provenance.
Represent material relationships.
Preserve applicability context.
Identify relevant defined terminology.
Determine the intended resolution target or resolution space.
Select appropriate Fragment Classes.
Compose the Semantic Data Template.
Serialize the SDT using conforming HTML-in-HTML.
Validate structural and semantic conformance.
Compare the machine representation with the human representation.
Publish both representations in the canonical HTML resource.
Inspect the publicly served artifact.

At scale, automation may perform most of these operations.

But the semantic sequence remains the same.

Know
        ↓
Model
        ↓
Represent
        ↓
Serialize
        ↓
Validate
        ↓
Publish

External observation can follow publication.

It is not a prerequisite for implementation.

16.110 A Data-Native Implementation Example

Consider a publisher generating county-level Medicare resources from structured CMS data.

The upstream system may contain:

County Table
Plan Table
Segment Table
Landscape Data
Performance Data
Enrollment Data
Publisher-Derived Statistics

The implementation may normalize these into:

County Identity
        ↓
Applicable Plans
        ↓
Plan / Segment Relationships
        ↓
Source-Observed Assertions
        ↓
Derived Assertions
        ↓
Source Metadata

The SDT composer can then construct:

Semantic Data Template
│
├── IdentityFragment
│   └── County
│
├── IndexFragment
│   └── Applicable Plans
│
├── DataFragment
│   └── Source-Observed Knowledge
│
├── DerivedStatsFragment
│   └── Publisher-Derived Knowledge
│
└── MetaFragment
    └── Source Metadata

The human renderer may independently produce:

headings;
explanatory prose;
comparison tables;
citations;
navigation;
and calls to action.

Both representations are then published together:

County Resource
│
├── Human Medicare Resource
└── WebMEM SDT

No separate semantic endpoint is required.

16.111 A Content-Derived Implementation Example

Now consider an organization with thousands of existing policy or educational pages but no structured knowledge system behind them.

The implementation path may begin with the documents themselves:

Existing HTML
        ↓
FactSmith / Knowledge Extraction
        ↓
Candidate Entities
Candidate Assertions
Candidate Terms
Candidate Relationships
Candidate Provenance
Candidate Applicability
        ↓
Publisher Review
        ↓
Validated Knowledge
        ↓
SDT Composition
        ↓
HTML-in-HTML
        ↓
Existing Resource

This allows a legacy publisher to create a machine-facing knowledge layer without rewriting its entire content-management architecture.

The extraction system should preserve evidence and ambiguity so that uncertain interpretations do not silently become published facts.

16.112 A Hybrid Implementation Example

Many real resources require both structured data and editorial knowledge.

For example:

STRUCTURED INPUTS

Plan Data
Enrollment Data
Performance Data
Geographic Data


EDITORIAL INPUTS

Definitions
Explanations
Policies
Procedures
Source Notes


        ↓

KNOWLEDGE RECONCILIATION

        ↓

WEBMEM SDT

The structured data may generate DataFragments and IndexFragments deterministically.

Editorial content may contribute DefinedTermFragments, PolicyFragments, ProcedureFragments, or other knowledge structures.

Each retains appropriate provenance.

The SDT becomes the composition layer where those different knowledge sources participate in one resource without being falsely collapsed into one source or semantic role.

16.113 Implementation Should Preserve the Difference Between Source and Publisher Knowledge

A production publishing system frequently adds knowledge that does not exist directly in the upstream dataset.

For example:

CMS Provides:
Individual Plan Records


Publisher Knows:
Which records apply to County X


Publisher Calculates:
Average Premium


Publisher Constructs:
County Option Space


Publisher Defines:
Canonical Resource Relationships

These are different forms of knowledge.

The implementation should preserve those distinctions.

The fact that all of them ultimately appear on one web page does not give them identical provenance.

16.114 The Publisher’s Application Logic May Be Knowledge

One of the more important implementation discoveries is that useful semantic knowledge may already exist in application logic rather than in a database field.

For example:

if segment.county_fips == page.county_fips:
    include_plan()

Operationally, the code is selecting records.

Semantically, the publisher knows:

Segment
→ appliesIn
→ County

Likewise:

route contract_id
to contract resource

may reveal:

Contract
→ canonicalResource
→ Contract Resource

Knowledge engineering therefore requires looking beyond database columns.

Publisher knowledge can live in data, code, editorial rules, routing, and human expertise.

16.115 Implementation Can Expose Hidden Knowledge Debt

Attempting to construct WebMEM may reveal that a publisher cannot answer seemingly simple semantic questions about its own systems.

For example:

What does this identifier identify?

Which source owns this value?

Is this statistic observed or derived?

Does this benefit apply to the Plan
or to the Segment?

What does "current" mean here?

Is this collection complete?

Where does this relationship come from?

If the organization cannot answer those questions reliably, the problem exists upstream of WebMEM.

The implementation process has exposed knowledge debt.

This can be valuable even before a single SDT is published.

16.116 WebMEM Implementation Can Improve Publisher Systems

Once hidden knowledge debt becomes visible, publishers may improve their internal architecture.

For example:

Before:

premium
source
plan


After:

premium
subject_entity
applicable_geography
applicable_period
source_record
source_version
derivation_state

WebMEM does not require the publisher to redesign its internal database this way.

But the semantic questions raised by publication may reveal where internal systems would benefit from stronger modeling.

The machine-facing layer can therefore create upstream information-quality benefits.

16.117 Implementation Should Not Duplicate Business Logic Unnecessarily

If the publisher already has authoritative logic for determining applicability, collection membership, or identity, the WebMEM pipeline should reuse that logic where practical.

For example:

Production Application:
determines applicable Plans

WebMEM Pipeline:
independently reimplements
applicability logic

creates two systems that may eventually disagree.

A stronger architecture is:

Shared Applicability Logic
        ↓
   ┌────┴────┐
   ↓         ↓
Human      WebMEM
Output     Output

Reuse the publisher’s authoritative semantics instead of recreating them for the machine layer.

16.118 One Source of Truth, Multiple Representations

The implementation goal can therefore be expressed as:

ONE PUBLISHER KNOWLEDGE STATE
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
View       View

not:

Human Database
        ↓
Human Page


Separate Machine Database
        ↓
Machine Page

Separate systems may be operationally necessary in some organizations.

But they should reconcile to the same underlying publisher knowledge.

16.119 Inline Publication Makes Atomic Updating Possible

When human and machine representations are generated together, a publisher can update them as one publication unit.

Conceptually:

Knowledge Version N
        ↓
Generate Human View N
        +
Generate WebMEM N
        ↓
Publish Document N

When the knowledge changes:

Knowledge Version N+1
        ↓
Generate Human View N+1
        +
Generate WebMEM N+1
        ↓
Publish Document N+1

This reduces the window in which the human page and machine representation expose different knowledge states.

16.120 Inline Publication Simplifies Canonicality

The original endpoint model created several potentially canonical representations:

/resource/

/semantic/json/resource

/semantic/ttl/resource

/semantic/md/resource

The publisher then needed to maintain relationships among them.

Inline publication simplifies the model:

Canonical Resource:
https://example.org/resource/

        ↓

Contains:
Human Representation
+
WebMEM Representation

The SDT can have its own identity while remaining part of the canonical resource.

This reduces ambiguity about where the publisher’s public representation lives.

16.121 Inline Publication Simplifies Provenance

When the SDT travels with the resource, the publisher can align:

Resource Identity

SDT Identity

Publisher Identity

Source References

Generation State

without requiring a separate semantic service to remain synchronized with the page.

This does not eliminate provenance complexity.

It eliminates one unnecessary source of provenance drift.

16.122 Inline Publication Simplifies Version Coordination

Likewise, one document can carry one coherent representation state.

For example:

Canonical Resource Version:
2026-08-25

Human Knowledge:
Version A

WebMEM:
Version A

rather than:

Human Resource:
Version A

JSON Endpoint:
Version B

TTL Endpoint:
Version A

Markdown Mirror:
Version C

Multiple serializations can be maintained correctly.

But every additional representation creates another synchronization obligation.

The current architecture avoids that obligation unless interoperability justifies it.

16.123 Implementation Architecture Should Follow Risk

A low-risk glossary implementation and a national healthcare data system do not require identical operational controls.

For example:

LOWER-RISK IMPLEMENTATION

Manual authoring
Basic validation
Periodic inspection


HIGHER-RISK IMPLEMENTATION

Authoritative source mapping
Automated generation
Semantic validation
Cross-surface validation
Version control
Dependency tracking
Audit logs
Rollback
Human review for exceptions

The protocol provides a common semantic contract.

Operational governance should scale with consequence.

16.124 Implementation Architecture Should Follow Volatility

Knowledge that changes once every several years does not require the same update infrastructure as knowledge that changes monthly or daily.

For example:

Stable Glossary Definition
→ publication-time generation may suffice


Monthly Enrollment Data
→ scheduled pipeline may be appropriate


Real-Time Inventory
→ request-time or event-driven generation
  may be necessary

Temporal Knowledge Integrity should inform the implementation architecture.

16.125 Implementation Architecture Should Follow Semantic Complexity

A resource containing one stable entity and several direct facts may require little modeling.

A resource containing:

Multiple Entity Levels
+
Multiple Sources
+
Derived Statistics
+
Temporal Variation
+
Geographic Applicability
+
Cross-Resource Relationships
+
Option Spaces

requires stronger knowledge engineering.

The complexity of the implementation should reflect the complexity of the knowledge rather than the prestige of the technology stack.

16.126 Implementation Does Not End at Publication

Once the resource is public, the publisher should maintain the representation as part of the resource lifecycle.

This may include:

source updates;
data regeneration;
template changes;
terminology changes;
relationship changes;
conformance updates;
cache invalidation;
cross-surface validation;
and correction of discovered semantic defects.

WebMEM becomes part of publishing operations rather than a one-time markup project.

16.127 Observation Can Be Added After Deployment

A publisher may deploy WebMEM before building sophisticated consumer-observation infrastructure.

The sequence can be:

Phase 1:
Represent

Phase 2:
Validate

Phase 3:
Publish

Phase 4:
Observe

Phase 5:
Measure

Phase 6:
Improve

This is important because observability should not become an adoption barrier.

The first responsibility is to improve the representation.

16.128 Implementation Success Should Be Defined Publisher-Side First

The original framework defined deployment success partly through external outcomes such as retrievability, reinforcement, and AI visibility.

The current framework begins with publisher-controlled success criteria.

For example:

Resource Scope:
defined

Identity:
correct

Assertions:
correct

Provenance:
recoverable

Relationships:
explicit

Applicability:
preserved

Resolution Coverage:
appropriate

Serialization:
conforming

Human/Machine Alignment:
validated

Public Artifact:
verified

If those conditions are satisfied, the publisher has successfully implemented the machine-facing representation.

External machine outcomes can then be observed separately.

16.129 Consumer Retrieval Is Not a Conformance Requirement

A consuming system may fail to discover, retrieve, parse, or use a perfectly conforming WebMEM representation.

That does not make the publisher representation non-conforming.

Likewise, a non-conforming representation may happen to be interpreted correctly by a consumer.

That does not make it conforming.

The distinction is:

Protocol Conformance
→ property of publisher representation


Consumer Retrieval
→ behavior of external system

This boundary protects the protocol from becoming dependent on undocumented external behavior.

16.130 The Deployment Milestone Has Changed

The original minimum deployment milestone was:

Glossary
+
Multi-Format Digests
+
Prompt Emission
+
Retrieval Logging
+
Reinforcement Publishing

The current milestone is:

Publisher Knowledge
        ↓
Conforming SDT
        ↓
Inline HTML-in-HTML
        ↓
Canonical Resource
        ↓
Verified Public Artifact

Everything beyond that belongs to scale, governance, interoperability, or observability.

16.131 The Infrastructure Burden Moved Upstream

The current architecture is simpler at the publication layer.

But that does not mean the problem became trivial.

The burden moved from distribution infrastructure to knowledge infrastructure.

The publisher no longer needs to ask:

How many formats should we syndicate?

Which endpoint should serve Turtle?

Which platform should mirror Markdown?

The publisher now has to answer harder questions:

What is this?

What do we know about it?

Where did that knowledge come from?

What did we derive?

How does it relate?

Where does it apply?

What does this term mean?

What can be resolved?

What should remain unresolved?

Those questions are harder because they require understanding the publisher’s knowledge rather than merely distributing content.

16.132 From Semantic Deployment to Knowledge Publication

The original Part 16 described implementation as AI semantic deployment.

The current architecture is better described as machine knowledge publication.

The distinction is meaningful.

Semantic Deployment
→ suggests infrastructure delivered
  toward machine systems


Knowledge Publication
→ describes publisher knowledge made
  explicit at the public boundary

The publisher publishes.

The consumer decides how to use what was published.

16.133 The Current Implementation Model

The complete implementation model can now be summarized as:

                    SOURCE SYSTEMS
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     Structured       Editorial     Application
       Data            Content        Logic
          └──────────────┼──────────────┘
                         ↓
                 KNOWLEDGE ENGINEERING
                         ↓
                 Publisher Knowledge
                         ↓
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
       Identity       Assertions    Relationships
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                    Provenance
                         ↓
                   Applicability
                         ↓
                     Resolution
                         ↓
                  SDT COMPOSITION
                         ↓
                 Fragment Classes
                         ↓
              HTML-IN-HTML SERIALIZATION
                         ↓
              CONFORMANCE VALIDATION
                         ↓
                 CANONICAL RESOURCE
                         │
             ┌───────────┴───────────┐
             ↓                       ↓
          Human View             WebMEM SDT
             │                       │
             └───────────┬───────────┘
                         ↓
                  PUBLIC WEB RESOURCE
                         ↓
                 External Consumers

This model does not require the publisher’s internal systems to resemble WebMEM.

It requires the publisher to perform the semantic work necessary to transform its knowledge into a conforming public representation.

16.134 FactSmith Fits Before the Publication Contract

The current architecture also clarifies where FactSmith belongs.

FactSmith operates primarily in the knowledge-engineering portion of the pipeline:

Source Systems
        ↓
FactSmith
        ↓
Candidate / Structured
Publisher Knowledge
        ↓
Validation / Review
        ↓
WebMEM

Its job may include helping the publisher answer:

What facts are present?

What entities do they concern?

What definitions are material?

What relationships are expressed?

What provenance can be recovered?

What context affects applicability?

Which semantic responsibility
does each knowledge object perform?

WebMEM begins after those questions have sufficiently stable answers.

FactSmith helps construct or recover knowledge.

WebMEM publishes that knowledge.

16.135 The Inline Dataset Fits at the Public Boundary

The inline SDT occupies the other end of the architecture.

It is the machine-facing representation delivered at the public boundary:

INTERNAL

Publisher Knowledge
        ↓
Knowledge Engineering
        ↓
SDT Composition
        ↓
Serialization


────────────────────────────
     PUBLICATION BOUNDARY
────────────────────────────


PUBLIC

Canonical HTML Resource
│
├── Human Representation
└── Inline WebMEM Dataset

This makes the role of the inline dataset precise.

It is not the publisher’s master database.

It is not necessarily the complete knowledge graph.

It is not an API response hidden inside a page.

It is a resource-scoped publication of machine-facing knowledge.

16.136 The Resource Becomes the Unit of Dual Publication

This gives two-tier publishing a concrete technical unit:

the canonical resource.

Instead of:

Human Web
        +
Separate Machine Web

the architecture becomes:

Canonical Resource
        ↓
Two Representations
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
View       View

The two representations may differ dramatically in form.

They should remain grounded in compatible underlying knowledge.

16.137 Inline Datasets Make the Web Page a Knowledge Container

A conventional web page is primarily understood as a document.

With an inline machine knowledge layer, the same resource can also function as a knowledge container.

Web Resource

Human Interpretation:
Document

Machine Interpretation:
Document
+
Structured Knowledge Surface

This does not require abandoning the document model.

It extends it.

The publisher can continue producing excellent human pages while exposing additional semantic structure that would otherwise be lost during publication.

16.138 The Inline Dataset Is Not Hidden Truth

Because the machine representation is not normally rendered visually, publishers should be careful not to treat it as a place to make materially different claims from the human resource.

For example:

Human:
42 applicable plans

Machine:
57 applicable plans

requires an explainable scope distinction or represents a publishing inconsistency.

Likewise:

Human:
CMS reports the underlying records

Machine:
CMS generated publisher-derived statistic

is not acceptable merely because most human readers will never inspect the SDT.

The machine layer is non-visual. It is not exempt from publisher accountability.

16.139 Inline Knowledge Should Be Inspectable

This reinforces the importance of inspection tooling.

A publisher should be able to move from:

View Page

to:

View WebMEM

and inspect the machine representation associated with the same resource.

Conceptually:

Canonical Page
        ↓
Inspect WebMEM
        ↓
SDT
├── Fragments
├── Entities
├── Assertions
├── Provenance
├── Relationships
├── Applicability
└── Resolution Structure

This can make two-tier publishing tangible to developers, editors, researchers, auditors, and compliance reviewers.

16.140 Inspection Can Become Part of Browser Tooling

Because the representation exists in the DOM, inspection does not necessarily require access to the publisher’s backend.

A browser-based inspector can conceptually:

Load Public Resource
        ↓
Parse DOM
        ↓
Locate data-webmem-sdt
        ↓
Parse Fragments
        ↓
Validate Structure
        ↓
Render Human-Readable View

This creates the possibility of independent WebMEM inspection using the same public artifact available to machine consumers.

The inspector need not trust the publisher’s generation system.

It can inspect what was actually served.

16.141 Public Inspection Supports Protocol Adoption

A machine-facing protocol is difficult for humans to understand when its implementation remains invisible.

Inspection tooling can make concepts such as:

Identity
Provenance
Fragment Classes
Relationships
Applicability
Resolution

visible and concrete.

This can support:

developer education;
implementation debugging;
conformance review;
publisher demonstrations;
research;
and independent protocol evaluation.

16.142 Implementation Does Not Require Consumers to Understand Everything

A consumer may use only part of the published representation.

For example, one system may recover:

Entity Identity
+
Assertions

while another may also use:

Provenance
+
Relationships
+
Applicability

and another may ignore WebMEM entirely.

The publisher does not need to create progressively simpler semantic variants for each consumer.

The publisher publishes the coherent representation.

Consumer capability remains a consumer concern.

16.143 Graceful Partial Interpretation

A well-designed representation should avoid making one optional semantic feature necessary to understand every other feature where that dependency is not inherent.

For example:

Entity Identity
        ↓
Assertion

may remain useful even if a consumer does not interpret a related canonical-resource relationship.

Likewise:

Assertion
+
Unit
+
Applicable Period

may remain interpretable even if a consumer does not use an optional broader relationship graph.

This does not mean flattening the knowledge.

It means composing it so semantic responsibilities remain modular where the knowledge permits.

16.144 Implementation Should Avoid Unnecessary Cleverness

Once the knowledge model is correct, the serialization layer should be boring.

It should not require:

JavaScript execution to reconstruct basic assertions;
obscure encoding;
consumer-specific workarounds;
unnecessary format nesting;
or multiple indirection layers where direct representation is sufficient.

The objective is recoverability.

A machine representation should be easier to interpret than the human page, not harder.

16.145 Implementation Should Prefer Explicitness Over Compression

Publishers may be tempted to minimize representation size by relying heavily on implied context.

Compression is useful only until it begins to remove material semantics.

For example:

premium = 18.50

is compact.

But:

monthly_premium = 18.50 USD

is more explicit.

And where applicability matters:

Subject:
segment:H5521-290-001

monthly_premium:
18.50 USD

plan_year:
2026

may be necessary.

Optimize representation size after semantic sufficiency, not before it.

16.146 Implementation Should Prefer Shared Context Over Repetition

Explicitness does not require repeating identical context on every assertion.

Where a context is truly shared, inheritance can reduce duplication.

For example:

SDT:
plan_year = 2026

Fragment:
geography = county:04015

Assertions:
premium
moop
plan_count

The implementation should balance:

Explicit Meaning
        ↕
Efficient Composition

by declaring context at the broadest level where it remains valid.

16.147 Implementation Should Preserve Explainability

A publisher should be able to explain how a material machine assertion was produced.

For example:

Assertion:
average_monthly_premium = 15.26 USD

        ↓

Why?

        ↓

Source:
CMS Landscape

Records:
Applicable County Plans

Method:
Arithmetic Mean

Generated By:
Publisher Pipeline

Template:
DerivedStats v2

This level of traceability may not be necessary for every trivial assertion.

But the architecture should make it possible where provenance, compliance, or debugging requires it.

16.148 Implementation Should Support Reproducibility

Where a representation is generated from structured inputs, the publisher should ideally be able to reproduce it.

For example:

Source Version
+
Transformation Version
+
Template Version
+
Resource Context
        ↓
Equivalent WebMEM Representation

Reproducibility supports:

auditing;
debugging;
historical reconstruction;
rollback;
and validation.

This is particularly valuable for derived knowledge.

16.149 Implementation Should Preserve Change Reasons

A resource may change for several reasons:

Source Update
Data Correction
Relationship Change
Definition Change
Template Revision
Protocol Revision
Publisher Editorial Change

These changes are not equivalent.

Where operationally useful, the publisher may preserve the reason for regeneration or semantic revision.

This helps distinguish:

Knowledge Changed

from

Representation Changed

which is essential to Temporal Knowledge Integrity.

16.150 Implementation Can Support Semantic Diffing

Once WebMEM representations are structured, publishers can compare versions semantically rather than only textually.

For example:

SDT v1
        ↓
Semantic Diff
        ↑
SDT v2

Changes:

+ plan:H5521-291
- plan:H5521-287

monthly_premium:
18.50 → 22.00 USD

relationship:
segment:001
appliesIn
county:04015
UNCHANGED

This is more informative than a raw HTML diff because it describes changes in knowledge rather than changes in markup formatting.

16.151 Semantic Diffing Can Drive Deployment

A semantic diff can help determine which downstream resources require regeneration.

For example:

Changed:
Plan Premium

        ↓

Affected:
Plan Resource
County Derived Statistics
Comparison Resource


Unaffected:
Contract Identity
Glossary
Carrier Resource

This creates a path toward dependency-aware publishing at scale.

16.152 Implementation Can Support Semantic Testing Before Deployment

A deployment system may compare the proposed representation against the currently published representation.

For example:

PROPOSED CHANGE

Plan Count:
42 → 0

Source Update:
none

Expected:
no major collection change

        ↓

FLAG FOR REVIEW

or:

Derived Average:
15.26 → 1526.00

Unit:
USD

        ↓

OUTLIER
FLAG FOR REVIEW

These are publisher quality controls rather than WebMEM protocol requirements.

But structured knowledge makes them easier to implement.

16.153 Implementation Can Improve Compliance Review

In regulated environments, reviewers often need to answer:

What exactly are we claiming?

Where did it come from?

Did we calculate it?

What population does it apply to?

What period does it describe?

What resource exposes it?

A structured machine representation can make those questions easier to answer.

The same artifact intended to improve machine recoverability can also improve human governance.

16.154 Implementation Can Improve Data Quality

Machine-facing publication can expose inconsistencies that ordinary page rendering hides.

For example:

Plan Table:
contract_id = H5521

Carrier Table:
contract_id = H5521
carrier = Organization A

Legacy Metadata:
contract_id = H5521
carrier = Organization B

A human page may use only one of those sources and conceal the contradiction.

Knowledge composition and cross-surface validation force the publisher to confront it.

WebMEM therefore can become a downstream consumer that improves upstream data discipline.

16.155 Implementation Can Reveal Missing Provenance

A publisher may discover that it knows a value but no longer knows where the value came from.

For example:

Database:
average_cost = 27.41

Source:
unknown

Method:
unknown

Generated:
unknown

The value may have been used safely for years.

But attempting to publish it as explicit machine knowledge exposes the provenance gap.

The correct response may be to:

recover the lineage;
recalculate from known sources;
label the knowledge appropriately;
or omit it until provenance is established.

16.156 Implementation Can Reveal Missing Identity

Likewise, a publisher may discover that internal systems use identifiers without a clear entity model.

For example:

ID:
12345

Used By:
three databases

Meaning:
unclear

WebMEM implementation forces the question:

What does 12345 identify?

If the publisher cannot answer, assigning a public entity identity would be premature.

16.157 Implementation Can Reveal Missing Relationships

A human page may visually imply relationships through grouping.

For example:

Carrier Name

Plan A
Plan B
Plan C

A human reader may infer:

Carrier
→ offers
→ Plans

But the publisher should determine the precise domain relationship before encoding it.

The relationship may actually be:

Carrier
→ operatesContract
→ Contract

Contract
→ hasPlan
→ Plans

The machine layer makes the distinction unavoidable.

16.158 Implementation Can Reveal Missing Applicability

Similarly, a value may have been displayed for years under a page heading that supplied implicit context.

For example:

Page:
2026 Medicare Plans in Mohave County

Table:
Premium = 18.50

A human understands the surrounding context.

When the assertion becomes an independent machine object, the publisher must decide whether the applicable context is:

2026

Mohave County

Plan

Segment

or some combination

Implementation therefore exposes semantic assumptions previously carried by layout.

16.159 Implementation Is Knowledge Engineering at the Publication Boundary

All of these discoveries point to a more precise description of the implementation problem.

WebMEM implementation is not primarily:

Adding attributes to HTML.

It is:

Knowledge Engineering
        ↓
at the
Publication Boundary

The publisher begins with knowledge distributed across:

Data
Content
Code
Rules
Relationships
Terminology
Human Expertise

and asks:

What meaning must survive
when this becomes a public
machine-readable resource?

The HTML serialization is the final expression of that work.

It is not the work itself.

The markup is implementation. The knowledge model is architecture.

16.160 The Publication Boundary Is Where Meaning Is Commonly Lost

Before publication, the publisher may know:

H5521
→ Contract

H5521-290
→ Plan

H5521-290-001
→ Segment

Segment
→ appliesIn
→ Mohave County

Segment
→ monthlyPremium
→ 18.50 USD

After conventional publication, a machine may encounter:

Heading
Paragraph
Table Row
$18.50
Link
County Name

The information remains visible.

Much of the structure does not.

The implementation problem is therefore not primarily one of making data machine-readable.

The data were already machine-readable inside the publisher’s systems.

The problem is preserving the publisher’s knowledge when that data crosses into the public web.

16.161 Inline WebMEM Closes the Final-Mile Gap

The inline SDT creates a second path through the publication boundary:

Publisher Knowledge
        ↓
        ├─────────────────────┐
        ↓                     ↓
Human Presentation      Machine Representation
        ↓                     ↓
Prose                   Identity
Tables                  Assertions
Navigation              Provenance
Visual Hierarchy        Relationships
Explanations            Applicability
                        Resolution
        └──────────┬──────────┘
                   ↓
          Canonical Resource

The human representation can continue doing what human publishing does well.

The machine representation preserves semantic structure that presentation would otherwise make implicit.

This is the implementation consequence of two-tier publishing.

16.162 The SDT Is a Projection, Not a Duplicate Database

The inline dataset should not be understood as a serialized copy of the publisher’s backend.

It is a resource-scoped semantic projection.

Conceptually:

Publisher Knowledge Universe
        ↓
Resource Scope
        ↓
Semantic Selection
        ↓
SDT

The publisher may know thousands of facts about a Plan.

A County Resolver may need only those facts material to the county-level resolution problem.

The Plan resource may expose a different projection.

The Contract Resolver may expose another.

Stable identity and relationships allow those projections to remain connected without requiring each resource to reproduce the complete knowledge universe.

16.163 Resource Scope Becomes an Implementation Decision

Before constructing an SDT, the publisher should be able to state what the resource represents.

For example:

Resource:
Medicare Options — Mohave County

Primary Context:
county:04015

Resolution Purpose:
represent the applicable Medicare
coverage option space for the county

That scope helps determine:

which entities belong in the SDT;
which assertions are material;
which relationships should be represented;
which provenance belongs locally;
which applicability context can be inherited;
and where canonical continuation should replace duplication.

Resource scope is the filter between everything the publisher knows and what this resource should publish.

16.164 Fragment Boundaries Become Implementation Decisions

Once resource scope is established, the publisher must decide how the knowledge should be divided by semantic responsibility.

For example:

SDT
│
├── IdentityFragment
│   └── What resource context is this about?
│
├── IndexFragment
│   └── What collection is applicable?
│
├── DataFragment
│   └── What source-observed facts are asserted?
│
├── DerivedStatsFragment
│   └── What did the publisher calculate?
│
└── MetaFragment
    └── What source metadata supports interpretation?

This division should reflect the knowledge architecture rather than arbitrary file organization or visual page sections.

16.165 Fragment Boundaries Also Create Provenance Boundaries

Fragment composition can help prevent unrelated provenance models from being flattened together.

For example:

DataFragment
Source:
CMS Landscape

Assertions:
source-observed Plan facts


DerivedStatsFragment
Derived From:
CMS Landscape

Generated By:
Publisher

Assertions:
county-level calculated statistics

The source may be related.

The epistemic role is different.

Separating the fragments makes that distinction easier to preserve and validate.

16.166 Fragment Boundaries Also Create Validation Boundaries

Different Fragment Classes may require different validation rules.

For example:

IdentityFragment:
validate entity identity


DataFragment:
validate assertion types,
units, and source lineage


DerivedStatsFragment:
validate source inputs,
derivation status, and method


IndexFragment:
validate collection scope
and membership semantics

This makes Fragment Classes operationally useful rather than merely descriptive.

16.167 Serialization Should Be the Last Transformation

Once the SDT composition is valid, serialization should be comparatively mechanical.

The preferred sequence is:

Publisher Knowledge
        ↓
Semantic Model
        ↓
SDT Composition
        ↓
Validation
        ↓
HTML Serialization

not:

Start Writing HTML
        ↓
Decide What the Knowledge Means
While Writing Attributes

The more semantic decisions occur inside the serializer, the harder the system becomes to test and maintain.

16.168 The Serializer Should Be Semantically Boring

A serializer should primarily translate known semantic objects into the applicable WebMEM HTML contract.

Conceptually:

Input:

Entity
Assertion
Provenance
Relationship
Applicability


        ↓


Output:

Conforming HTML-in-HTML

It should not normally decide:

Which entity is correct?

Whether two entities are equivalent?

Whether a value is derived?

Whether a relationship exists?

Whether a fact applies geographically?

Those are knowledge-engineering decisions and should be resolved upstream.

16.169 The Implementation Stack Can Be Thin

Once the responsibilities are separated correctly, the actual WebMEM-specific implementation layer can be surprisingly small.

For a structured-data publisher:

Existing Data Pipeline
        ↓
Semantic Mapping
        ↓
Fragment Templates
        ↓
Serializer
        ↓
Validator
        ↓
Inline SDT

The publisher does not need to replace:

its CMS;
its database;
its human templates;
its CDN;
its analytics;
or its existing search infrastructure.

WebMEM can be added at the publication boundary.

16.170 The Implementation Stack Can Also Be Deep

At enterprise scale, the same semantic contract may sit above substantial infrastructure:

Source Registry
        ↓
ETL
        ↓
Normalized Data Warehouse
        ↓
Entity Resolution
        ↓
Knowledge Graph
        ↓
Terminology Service
        ↓
Provenance Service
        ↓
Policy / Applicability Engine
        ↓
WebMEM Projection
        ↓
Serializer
        ↓
Validator
        ↓
Canonical Resource

The protocol does not care whether the upstream system is simple or sophisticated.

It cares about the semantics exposed at the public boundary.

16.171 WebMEM Is an Output Contract

This leads to one of the most important implementation principles in the current framework:

WebMEM is an output contract.

It does not prescribe:

the publisher’s database schema;
programming language;
CMS;
data warehouse;
knowledge graph;
AI provider;
editorial workflow;
or internal semantic representation.

Different publishers may reach the same conforming public representation through entirely different systems.

Publisher A:
MySQL → PHP → WebMEM

Publisher B:
Knowledge Graph → Java → WebMEM

Publisher C:
CSV → Python → Static HTML → WebMEM

Publisher D:
Editorial Content → FactSmith → WebMEM

The public semantic contract is the common layer.

16.172 Conformance Creates Interoperability Without Internal Standardization

This is why conformance matters operationally.

Publishers do not need identical internal systems.

They need compatible public representations.

Conceptually:

Different Internal Architectures
        ↓
Conforming WebMEM
        ↓
Common Public Interpretation Surface

This allows the protocol to standardize the publication boundary without attempting to standardize the entire publisher technology stack.

16.173 Implementation Profiles May Reduce Repeated Work

Organizations publishing the same class of knowledge repeatedly may define implementation profiles.

For example:

Medicare County Resolver Profile

Contract Resolver Profile

Plan Resource Profile

Glossary Profile

A profile may define:

expected Fragment Classes;
identity conventions;
required relationships;
applicability expectations;
required provenance;
and resource-specific conformance tests.

Profiles reduce repeated architectural decisions while leaving the core protocol domain-independent.

16.174 Profiles Should Not Become Domain Truth

An implementation profile can describe how a particular publisher or domain maps knowledge into WebMEM.

It should not silently redefine the domain itself.

For example:

Medicare Profile:
Plan → hasSegment → Segment

should exist because the underlying domain supports that relationship, not because the WebMEM profile invented it.

The direction remains:

Domain Knowledge
        ↓
Implementation Profile
        ↓
WebMEM

not:

WebMEM Profile
        ↓
Invent Domain Model

16.175 Profiles Can Become Reusable Engineering Assets

Once a resource type has been modeled correctly, the publisher can reuse:

Identity Rules
Relationship Rules
Fragment Composition
Provenance Mapping
Applicability Rules
Validation Tests
Serialization Templates

across every resource of that type.

This is where large-scale WebMEM deployment becomes economically practical.

The expensive work is understanding the semantic model once.

The inexpensive work is applying the validated model repeatedly.

16.176 Implementation Economics Favor Reusable Semantics

Consider a publisher with 3,000 county resources.

The wrong implementation model is:

3,000 Pages
×
Manual Semantic Authoring

The scalable model is:

1 County Knowledge Model
+
1 Validated Profile
+
3,000 Resource Data Contexts
        ↓
3,000 Generated SDTs

This is the same principle publishers already use for human templates.

The difference is that the reusable template now represents semantic responsibilities rather than merely presentation.

16.177 Semantic Templates Become Infrastructure

Human publishing has long treated templates as presentation infrastructure.

WebMEM introduces a second kind of template:

Human Template
→ controls presentation


Semantic Template
→ controls machine representation

The two may be generated by the same application.

They perform different jobs.

A change to a human template might affect:

Heading order
Layout
CTA placement
Table presentation

A change to a semantic template might affect:

Entity scope
Provenance
Relationship structure
Applicability
Resolution

The latter can have substantially different consequences and should be governed accordingly.

16.178 Semantic Template Changes Require Semantic Review

A developer may make a syntactically small change with a large semantic effect.

For example:

Before:

data-entity-id =
segment:H5521-290-001


After:

data-entity-id =
plan:H5521-290

The HTML change is trivial.

The assertion subject changed.

Likewise:

Move source context
from assertion level
to SDT level

may accidentally imply that the source applies to knowledge it did not produce.

Semantic templates therefore require review according to meaning, not merely code quality.

16.179 Deployment Pipelines Can Treat Semantic Changes as First-Class Changes

A mature deployment process may classify changes such as:

PRESENTATION CHANGE

SEMANTIC TEMPLATE CHANGE

SOURCE DATA CHANGE

PROVENANCE CHANGE

RELATIONSHIP CHANGE

APPLICABILITY CHANGE

PROTOCOL VERSION CHANGE

Different classes may trigger different tests and approvals.

This is especially useful in regulated or high-risk environments.

16.180 FactSmith Can Assist With Semantic Diff Review

A knowledge-engineering system can also help reviewers understand the meaning of a proposed change.

Instead of presenting only:

47 lines added
32 lines removed

it may summarize:

Semantic Changes:

+ Added Segment identity

+ Added Segment → County relationships

~ Moved premium assertions
  from Plan scope to Segment scope

+ Added source-version provenance

No factual values changed

This is substantially more useful for semantic governance than a raw source-code diff.

16.181 Implementation Can Support Protocol Migration

As WebMEM evolves, publishers may need to migrate existing representations.

A well-separated architecture makes that easier:

Publisher Knowledge Model
        ↓
Old Serializer
        ↓
WebMEM Version A


Publisher Knowledge Model
        ↓
New Serializer
        ↓
WebMEM Version B

If the knowledge model remains stable, protocol migration does not require reconstructing the underlying knowledge from scratch.

This is another reason to separate knowledge engineering from serialization.

16.182 Serialization Migration Should Preserve Material Semantics

A protocol or serialization update may change syntax without changing meaning.

For example:

Serialization A
        ↓
Migration
        ↓
Serialization B

should preserve:

entity identity;
assertion meaning;
provenance;
relationships;
applicability;
and resolution structure.

Semantic regression tests can verify that the migration did not alter the knowledge accidentally.

16.183 Legacy WebMEM Can Be Migrated

The same principle applies to earlier WebMEM implementations.

For example:

Legacy:

HTML
→ embedded YAML
→ WebMEM structure


Current:

HTML
→ HTML-in-HTML
→ WebMEM structure

If the underlying semantic model remains valid, the publisher can migrate serialization without redesigning every knowledge object.

Where the semantic model itself has evolved—as with provenance, identity, relationships, and resolution—the migration may require deeper knowledge review.

16.184 Implementation History Can Preserve Protocol Evolution

Versioned representations can also document how the publisher’s knowledge architecture matured.

For example:

Version 1:
Facts only

Version 2:
+ Identity

Version 3:
+ Provenance

Version 4:
+ Relationships

Version 5:
+ Applicability

Version 6:
+ Resolution

This history can be useful for:

research;
auditing;
migration;
benchmarking;
and understanding changes in observed machine fidelity.

16.185 Implementation Should Remain Compatible With Ordinary Web Operations

WebMEM should not require publishers to abandon ordinary web infrastructure.

A conforming implementation should be capable of participating in the same operational environment as the human-facing resource.

That may include:

HTTP caching;
CDNs;
reverse proxies;
server-side rendering;
static generation;
content-management systems;
load balancing;
compression;
security controls;
monitoring;
and ordinary deployment pipelines.

The machine layer is part of the web resource.

It should not require an entirely separate operational model merely because its intended interpreter is different.

16.186 Ordinary HTML Processing Must Preserve the SDT

Web infrastructure frequently transforms HTML before it reaches the consumer.

For example:

Application
        ↓
HTML Generation
        ↓
Optimization Plugin
        ↓
Cache
        ↓
CDN
        ↓
Public Response

Any layer in that chain may:

minify markup;
rewrite attributes;
remove elements;
reorder content;
inject markup;
or serve a stale representation.

Implementation testing should therefore verify that ordinary web processing does not materially alter the WebMEM semantics.

The generation artifact is not sufficient evidence.

The public response is the publication artifact.

16.187 HTML Minification Should Preserve Semantics

Whitespace and formatting changes may be harmless.

Semantic changes are not.

For example:

Before Minification:

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

After Minification:

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

may preserve equivalent meaning.

But:

Before:

data-entity-id="segment:H5521-290-001"

After:

attribute removed

does not.

Publishers should test transformations according to semantic effect rather than textual difference.

16.188 Client-Side Rendering Requires Special Care

A publisher may generate some or all of the document through client-side JavaScript.

The protocol does not require one rendering architecture.

But the publisher should understand what is actually present in the publicly retrievable representation.

Conceptually:

Initial HTML
        ↓
JavaScript Execution
        ↓
Final DOM

If the WebMEM SDT exists only after client-side execution, consumers that do not execute the application may encounter a different representation from consumers that do.

Where broad machine accessibility is an implementation goal, server-rendered or statically present WebMEM may reduce that dependency.

This is an implementation consideration rather than a claim about any particular consumer’s capabilities.

16.189 Inline Publication Should Not Depend on Interaction

Material machine knowledge should not ordinarily require a user to:

click a tab;
open a modal;
scroll to trigger loading;
submit a form;
accept a visual interaction;
or execute a user-specific workflow;

before the applicable SDT becomes part of the resource.

If the resource claims to represent the knowledge at initial publication, the machine representation should normally travel with that resource.

Interactive applications may legitimately expose additional resource states.

Those states should be modeled according to their own semantic and publication context.

16.190 Personalized Pages Require Scope Discipline

Some web resources vary according to user context.

For example:

Location
Eligibility
Account State
Preferences
Authentication
Session Context

A publisher should not accidentally expose personalized or private context as though it were canonical public knowledge.

The public WebMEM representation should reflect the semantic scope of the public resource.

Where private context participates in a user-specific experience, that context belongs to the applicable private or consumer-side system unless the publisher has a legitimate reason and authorization to represent it.

16.191 Public Knowledge and Private Context Should Remain Separable

For example, a publisher may expose:

Plan
→ availableIn
→ Mohave County

Plan
→ usesFormulary
→ Formulary X

A user-specific application may know:

User
→ livesIn
→ Mohave County

User
→ takes
→ Drug Y

The public WebMEM resource does not need to contain:

User Identity
User Location
User Medications

for a consuming system to combine public knowledge with authorized private context elsewhere.

Machine-readable publishing does not eliminate privacy boundaries.

16.192 Security Boundaries Remain Security Boundaries

WebMEM should not be used as a mechanism for exposing information that is otherwise:

private;
confidential;
access-controlled;
licensed;
embargoed;
or inappropriate for public distribution.

The fact that the SDT is not normally visible on screen does not make its contents private.

If it is delivered in public HTML, it should be treated as publicly published information.

Inert is not secret.

16.193 Authorization Should Precede Machine Publication

Before including knowledge in a public SDT, the publisher should have the same authority to publish that knowledge that would be required for any other public representation.

The machine layer does not create a separate exception for:

copyright;
licensing;
privacy;
contractual restrictions;
data-use limitations;
or organizational governance.

Implementation architecture should therefore include publication authorization where the underlying domain requires it.

16.194 Accessibility and WebMEM Solve Different Problems

Web accessibility remains a human-facing publishing responsibility.

WebMEM does not replace:

semantic HTML for assistive technologies;
alternative text;
keyboard accessibility;
appropriate labels;
readable structure;
or other accessibility practices.

The machine knowledge layer serves a different purpose.

A publisher should not weaken accessible human markup because equivalent information exists in WebMEM.

Two-tier publishing adds a machine representation.

It does not subtract human responsibilities.

16.195 Search Infrastructure and WebMEM Can Coexist

The same principle applies to search optimization.

A publisher may continue using:

titles;
headings;
canonical links;
sitemaps;
internal linking;
robots controls;
structured data;
and other established search practices.

WebMEM does not require the publisher to abandon them.

The systems address different parts of the publication problem.

Search Infrastructure
→ discovery and search presentation


WebMEM
→ machine-facing knowledge representation

They may coexist inside the same publishing architecture.

16.196 Schema.org and WebMEM Can Coexist

A canonical resource may contain both established structured-data markup and WebMEM.

For example:

HTML Document
│
├── Human Content
├── Schema.org / JSON-LD
└── WebMEM SDT

The publisher should maintain semantic compatibility where the systems describe overlapping knowledge.

For example:

Schema:
name = Example Plan

WebMEM:
entity name = Different Plan

would warrant investigation unless the representations intentionally describe different subjects.

WebMEM does not gain credibility by contradicting another machine representation from the same publisher.

16.197 Existing Dataset Markup Can Establish the Resource-Level Signal

Where a publisher uses an established Dataset declaration, that declaration may describe the existence and scope of the machine-readable dataset associated with the resource.

The inline SDT then provides the structured knowledge itself.

Conceptually:

Canonical Resource
│
├── Human Content
│
├── Dataset Declaration
│   └── identifies / describes dataset
│
└── WebMEM SDT
    └── contains machine knowledge

The two layers perform different roles.

The Dataset declaration can describe the dataset as a web-visible object.

The SDT carries the publisher’s semantic representation.

16.198 Dataset Identity and SDT Identity Should Align

Where both are present, implementation should avoid creating unrelated identities for what is intended to be the same resource-level dataset.

For example:

Dataset / SDT Identity:

https://example.org/medicare-options/arizona/mohave-county/#webmem

can provide a stable point of alignment between:

Dataset Declaration
        ↕
Semantic Data Template

This allows the publisher to distinguish:

Canonical Page Identity

from

Dataset / SDT Identity

from

Fragment Identity

from

Entity Identity

without leaving the relationships among them ambiguous.

16.199 Inline Dataset Identity Should Be Stable

The SDT identity should not change merely because:

one factual value changed;
the page was regenerated;
a cache was cleared;
the HTML formatting changed;
or the publication timestamp changed.

If the represented dataset remains the same conceptual dataset associated with the same canonical resource, stable identity supports continuity over time.

Version and temporal information can describe changing states without unnecessarily creating a new identity for every generation event.

16.200 Fragment Identity Should Also Be Stable Where Semantic Responsibility Is Stable

The same principle applies within the SDT.

For example:

fragment:mohave-county-plan-index

may continue identifying the county Plan Index Fragment even as:

Plan membership changes
Plan year changes
source release changes
generation time changes

provided the fragment continues to perform the same semantic responsibility.

A material change in semantic responsibility may justify a different fragment identity or profile version.

16.201 Stable Identity and Changing State Must Be Separated

This distinction appears throughout implementation:

Identity
→ what the object is


State
→ what is true about it now


Version
→ which representation or knowledge state
  is being described


Time
→ when that state applies

Collapsing these concepts leads to unnecessary identity churn and makes longitudinal comparison more difficult.

16.202 Inline Dataset Generation Should Preserve Stable Ordering Where Operationally Useful

Semantic order should be explicit only where order carries meaning.

But deterministic generation may still use stable serialization ordering for operational reasons.

For example:

Fragments ordered by:
defined template sequence

Assertions ordered by:
canonical field sequence

Collection members ordered by:
stable identifier

This can make:

diffs cleaner;
testing easier;
caching more predictable;
and debugging simpler.

Stable serialization order should not be confused with semantic ranking unless the representation explicitly declares such meaning.

16.203 Implementation Should Distinguish Protocol Requirements From Publisher Conventions

A production implementation may adopt conventions that are useful but not required by WebMEM itself.

For example:

Publisher Convention:
fragment IDs use kebab-case

Publisher Convention:
all county entities use FIPS

Publisher Convention:
derived-stat fragments appear after
source-observed fragments

Such conventions may improve consistency.

They should not automatically be described as protocol requirements unless the specification actually requires them.

This distinction protects interoperability and prevents one implementation from accidentally becoming the protocol.

16.204 Implementation Documentation Should Preserve That Distinction

A mature publisher may therefore document three layers separately:

WEBMEM PROTOCOL

Normative requirements


IMPLEMENTATION PROFILE

Domain or resource-type requirements


PUBLISHER CONVENTIONS

Local engineering choices

This makes it easier to determine whether a change affects:

protocol conformance;
profile conformance;
or only local implementation behavior.

16.205 Deployment Documentation Becomes Part of Governance

For significant implementations, the publisher may document:

source systems;
identity conventions;
semantic mappings;
Fragment profiles;
provenance mappings;
applicability rules;
template versions;
validation rules;
publication lifecycle;
and rollback procedures.

This documentation helps future maintainers understand not only how the code works, but why the representation has its particular semantic structure.

16.206 The Implementation Architecture Can Be Audited

Because the pipeline separates source, transformation, representation, and publication, an auditor can conceptually trace:

Published Assertion
        ↓
Fragment
        ↓
SDT
        ↓
Semantic Mapping
        ↓
Publisher Knowledge
        ↓
Source / Derivation

This is substantially stronger than auditing a value visible on a page without knowing how it was produced.

16.207 The Public Artifact Can Be Audited Independently

Inline publication also enables a different form of audit.

An independent reviewer can retrieve the public resource and inspect:

SDT Identity
Fragment Structure
Entity Identity
Assertions
Provenance
Relationships
Applicability
Canonical Resources

without requiring access to the publisher’s internal database.

The reviewer cannot necessarily verify every underlying fact from the SDT alone.

But the publisher’s public semantic claims become inspectable.

16.208 Implementation Transparency Does Not Require Internal Disclosure

A publisher can expose meaningful provenance and semantic structure without publishing proprietary internal systems.

For example:

Published:

Derived From:
CMS Landscape 2026

Method:
Arithmetic Mean

Applicable Geography:
Mohave County

Generated By:
Publisher

does not require publishing:

Database credentials
Internal source code
Infrastructure topology
Private business logic
Security configuration

Machine-facing transparency concerns the published knowledge and its material lineage, not unrestricted disclosure of publisher infrastructure.

16.209 Implementation Should Preserve Publisher Accountability

Automation does not transfer responsibility away from the publisher.

If:

Python generated it

FactSmith extracted it

An LLM suggested it

A plugin serialized it

A template emitted it

the resulting public representation is still publisher-controlled content.

The publisher remains responsible for the knowledge it chooses to publish.

Automation changes production. It does not change authorship responsibility.

16.210 The Implementation Stack Can Be Tested Without an Answer Engine

A publisher does not need to wait for an external AI system to determine whether its WebMEM implementation is internally sound.

Before publication, the publisher can test:

Identity
Assertions
Datatypes
Units
Provenance
Relationships
Applicability
Resolution Coverage
Fragment Composition
Serialization
Conformance

After publication, it can additionally test:

Public Artifact Integrity
Cache State
Cross-Surface Consistency
Human/Machine Alignment

External machine observation answers a different question.

This is important operationally because implementation quality does not depend on receiving a citation from an answer engine.

16.211 External Observation Begins After Implementation

Once the publisher has established a sound public reference, external observation can begin.

The sequence matters:

Publisher Knowledge
        ↓
Representation
        ↓
Validation
        ↓
Publication
        ↓
Verify Public Artifact
        ↓
Observe External Consumers

If observation begins before the publisher knows whether its own representation is correct, machine outputs become difficult to interpret.

A wrong reflection may simply reflect a wrong reference.

A correct reflection may come from somewhere else entirely.

Establish the reference before measuring the reflection.

16.212 External Observation Does Not Complete the Implementation

A publisher may choose to operate a sophisticated observation program.

It may measure:

presence;
citation;
factual fidelity;
identity fidelity;
attribution fidelity;
relationship fidelity;
applicability fidelity;
provenance fidelity;
resolution fidelity;
and temporal drift.

Those measurements may improve publisher understanding.

They are not part of the minimum WebMEM publication contract.

A conforming implementation exists because the publisher represented and published knowledge correctly—not because an external machine subsequently used it.

16.213 Implementation and Observation Should Have Separate Logs

The publisher may therefore maintain two distinct operational histories.

Publication History:

Resource
SDT Identity
Data Version
Template Version
Protocol Version
Generation Time
Validation Result
Publication Time
Change Reason

Observation History:

Consumer
Observation Time
Query Family
Query Context
Publisher Reference Version
Observed Output
Semantic Fidelity Results

The histories can be correlated without being conflated.

This makes it possible to ask:

What did we publish?

When did we publish it?

What did the machine reflect?

When did the reflection change?

16.214 Implementation Data Enables Better Observation

A strong publication history improves the quality of downstream analysis.

Suppose an external consumer begins resolving Segment-specific premiums correctly on August 18.

The publisher knows:

August 10:
Template v2 deployed

Change:
explicit Segment identity added

August 10:
public artifact verified

August 18:
correct Segment resolution
first observed

The publisher can accurately report the sequence.

It may investigate a relationship between the events.

It should not automatically claim:

Template v2 trained the machine
in eight days.

The implementation history supports evidence.

It does not expose the consumer’s hidden mechanism.

16.215 Implementation Supports Controlled Publisher Experiments

Versioned templates and stable publication logs make controlled representation experiments possible.

For example:

BASELINE

Plan identity present
Segment identity implicit


INTERVENTION

Plan identity present
Segment identity explicit
Plan → Segment relationship explicit


UNCHANGED

Factual values
Source data
Human content
Canonical URL

The publisher can validate the revised representation, deploy it to a defined resource set, and observe downstream behavior.

This is substantially stronger than changing several publishing variables simultaneously and attributing any resulting machine behavior to one presumed cause.

16.216 Experiments Should Isolate Representation Changes Where Practical

If the publisher wants to learn whether a representation change correlates with a downstream outcome, unnecessary simultaneous changes should be minimized.

For example:

Weak Experiment:

Change WebMEM
Rewrite page
Change internal links
Change title
Add new source
Submit new sitemap
Launch PR campaign

        ↓

Observe citation increase

        ↓

Cause:
unknown

A stronger experiment may be:

Stable Human Resource
Stable URL
Stable Source Data

        ↓

Change One Material
Representation Dimension

        ↓

Validate

        ↓

Publish

        ↓

Observe

Perfect isolation may not be possible in production systems.

But implementation discipline can improve causal confidence.

16.217 Experiments Must Not Sacrifice Semantic Integrity

A publisher should not deliberately publish false or misleading knowledge merely to determine whether a consumer responds differently.

For example:

Experiment A:
Premium attached correctly to Segment

Experiment B:
Premium falsely attached to Plan

is not an acceptable representation experiment in a production information environment.

Experiments should compare legitimate representation strategies while preserving underlying truth.

16.218 Implementation Can Support Limited Rollouts

Large publishers may choose to deploy a new representation architecture to a limited resource class before broader adoption.

For example:

Protocol / Template Change
        ↓
Small Resource Class
        ↓
Validate Public Artifacts
        ↓
Observe
        ↓
Inspect Operational Effects
        ↓
Expand Deployment

This can reduce operational risk and provide evidence before sitewide rollout.

The purpose of the limited rollout is not to “train” the consumer gradually.

It is to validate the publisher’s implementation under real production conditions.

16.219 A Pilot Should Have Publisher-Side Success Criteria

A pilot should be considered successful first according to criteria the publisher controls.

For example:

Generation Success:
100%

Conformance:
PASS

Human/Machine Alignment:
PASS

Public Artifact Integrity:
PASS

Cache Integrity:
PASS

Cross-Surface Consistency:
PASS

Operational Errors:
0 material

External observations may provide additional evidence.

They should not determine whether the implementation itself was technically successful.

16.220 A Pilot Can Also Establish an Observation Baseline

Before deploying a material machine-representation change, the publisher may record existing consumer behavior.

For example:

PRE-DEPLOYMENT

Presence:
42%

Citation:
18%

Identity Fidelity:
79%

Resolution Fidelity:
61%


POST-DEPLOYMENT

Same Observation Frame
        ↓
Compare

This does not prove that WebMEM caused any subsequent change.

It creates a baseline from which change can be observed more rigorously.

16.221 Large-Scale Deployment Benefits From Resource Cohorts

A publisher may organize resources into cohorts according to:

resource type;
template version;
data source;
domain risk;
deployment date;
or representation maturity.

For example:

Cohort A:
County Resolvers
Template v2

Cohort B:
Contract Resolvers
Template v1

Cohort C:
Plan Resources
No WebMEM

Cohorts can support deployment management, validation, rollback, and observation without changing the underlying protocol.

16.222 Cohorts Can Support Comparative Research

Where resource classes are sufficiently comparable, cohorts may also support research.

For example:

Cohort A:
WebMEM deployed

Cohort B:
WebMEM not yet deployed

        ↓

Observe:
Discovery
Presence
Citation
Fidelity
Resolution

Differences should be interpreted cautiously because resource cohorts may differ in many ways beyond WebMEM deployment.

But structured rollout design can produce better evidence than anecdotal observation alone.

16.223 Implementation Evidence Should Be Preserved

If WebMEM is being evaluated empirically, publishers should preserve enough implementation evidence to reconstruct what happened.

That may include:

deployment date;
resource cohort;
template version;
protocol version;
source-data version;
semantic changes introduced;
validation results;
and public-artifact verification.

Without that history, later observations may be impossible to interpret confidently.

16.224 Implementation Research Should Distinguish Acceptance From Use

A machine crawler retrieving a resource containing WebMEM establishes one kind of evidence.

A search system indexing the resource establishes another.

A machine-generated answer accurately reflecting WebMEM knowledge establishes another.

These events should not be collapsed into one claim.

Conceptually:

Resource Retrieved
        ≠
SDT Parsed
        ≠
SDT Indexed
        ≠
SDT Used in Retrieval
        ≠
SDT Used in Answer Generation
        ≠
SDT Caused Citation

Each step represents a stronger claim and generally requires stronger evidence.

Implementation evidence should say exactly what was observed—and no more.

16.225 Inline Dataset Discovery Is an Empirical Question

WebMEM defines how the publisher represents machine-facing knowledge.

Whether a particular consumer discovers, parses, indexes, or uses that representation is an empirical question about the consumer.

The publisher can test and observe.

The protocol should not convert one consumer’s current behavior into a universal assumption.

This preserves consumer independence while still allowing implementation research to proceed aggressively.

16.226 Implementation Research Can Inform the Protocol

Repeated production experience may reveal weaknesses in the WebMEM architecture itself.

For example:

an identity pattern proves ambiguous across implementations;
a relationship cannot be represented clearly;
a Fragment Class carries too many semantic responsibilities;
a provenance requirement proves insufficient;
or a serialization construct creates recurring implementation errors.

These findings may justify protocol evolution.

The direction remains:

Implementation Evidence
        ↓
Architectural Understanding
        ↓
Protocol Revision

rather than:

Consumer Quirk
        ↓
Immediate Protocol Rule

16.227 Production Use Is Part of Protocol Maturation

A protocol concerned with real publisher knowledge cannot mature entirely through abstract specification.

Production systems expose:

unexpected source structures;
identity collisions;
provenance gaps;
relationship edge cases;
temporal conflicts;
scale problems;
cache behavior;
legacy-system constraints;
and operational governance requirements.

Those problems force the architecture to become more precise.

Implementation is therefore not merely downstream of protocol design.

It is one of the environments through which the protocol is tested and refined.

16.228 Implementation Should Produce Less Guessing Over Time

A mature WebMEM implementation should progressively move semantic decisions out of ad hoc code and into explicit models, profiles, mappings, and tests.

For example:

EARLY

Developer knows:
premium belongs to Segment


MATURE

Knowledge Model:
premium subject = Segment

Profile:
requires Segment identity

Validator:
rejects Plan-scoped premium
where Segment scope applies

The knowledge moves from individual memory into publisher infrastructure.

This is an important form of organizational knowledge preservation.

16.229 Implementation Converts Tacit Publisher Knowledge Into Explicit Infrastructure

Many organizations depend on knowledge that exists primarily in the heads of experienced employees.

For example:

"That field actually belongs
to the Segment."

"Those records are only valid
for the July enrollment month."

"That statistic is ours,
not CMS's."

"Those two IDs look similar
but identify different things."

WebMEM implementation forces those distinctions to become explicit enough to publish and validate.

The result can strengthen the publisher internally as well as externally.

16.230 Implementation Is Also Knowledge Governance

Once publisher knowledge becomes explicit, questions of ownership and responsibility become easier to define.

An organization can ask:

Who owns this entity model?

Who approves this definition?

Who owns the source mapping?

Who validates this derivation?

Who approves this relationship?

Who is responsible for this
semantic template?

These are governance questions.

At scale, machine-facing publishing therefore intersects with data governance, editorial governance, compliance, and software engineering.

16.231 Implementation Roles May Span Several Disciplines

A mature deployment may involve:

Role	Primary Responsibility
Domain Expert	Determines domain meaning and applicability
Data Engineer	Maintains source ingestion, normalization, and lineage
Knowledge Engineer	Models identity, assertions, relationships, terminology, and resolution
Publisher / Editor	Maintains human representation and editorial accountability
Software Engineer	Implements generation, serialization, caching, and deployment
Compliance / Governance	Reviews provenance, risk, policy, and publication controls
Research / Observability	Measures external machine reflections

One person may perform several roles in a small organization.

The responsibilities remain conceptually distinct.

16.232 The Knowledge Engineer Becomes a Publishing Role

Traditional digital publishing teams commonly include:

Writers
Editors
Designers
Developers
SEO Specialists
Data Analysts

Machine-facing knowledge publication introduces another responsibility:

Knowledge Engineer

The role asks questions that sit between content, data, and software:

What does this entity represent?

What is the canonical identity?

Which facts belong to it?

What source supports them?

What relationships exist?

Where do they apply?

What can be resolved?

How should the knowledge be composed?

This is the human discipline behind the machine layer.

16.233 FactSmith Can Amplify the Knowledge Engineer

A system such as FactSmith can automate portions of that work.

It may accelerate:

content analysis;
candidate fact extraction;
entity discovery;
relationship discovery;
terminology identification;
provenance capture;
and semantic template generation.

But automation does not eliminate the need for knowledge architecture.

It makes the discipline more scalable.

16.234 FactSmith and WebMEM Form Different Halves of a Pipeline

The relationship can now be stated cleanly:

FactSmith
        ↓
Structure What the Publisher Knows


WebMEM
        ↓
Publish What the Publisher Knows

Or, more completely:

Human Content / Data / Rules
        ↓
FactSmith / Knowledge Engineering
        ↓
Publisher Knowledge Model
        ↓
WebMEM
        ↓
Machine-Facing Publication

This is substantially different from the original 2025 implementation architecture, which focused primarily on generating and distributing Semantic Digests.

16.235 Inline WebMEM Completes the Pipeline

The final architectural discovery was that machine-facing publication did not require a separate destination.

Knowledge Engineering
        ↓
WebMEM
        ↓
Where does it go?

2025 Answer:
Separate Semantic Infrastructure

2026 Answer:
The Canonical Resource

That closes the implementation loop.

Publisher Knowledge
        ↓
Human Representation
        +
Machine Representation
        ↓
One Resource

16.236 The Implementation Model Is Deliberately Incremental

A publisher can begin with:

One Page
One SDT
One Fragment
One Entity
Several Assertions

and later develop:

Reusable Profiles
Automated Pipelines
Resolvers
Terminology Systems
Cross-Surface Validation
Temporal Governance
Consumer Observation

The architecture does not require organizations to solve the entire knowledge problem before they begin.

It requires them to represent correctly what they choose to publish.

16.237 The Implementation Model Is Deliberately Extensible

Future WebMEM versions may introduce:

additional Fragment Classes;
additional relationship semantics;
additional provenance capabilities;
domain or implementation profiles;
additional conformance levels;
new validation rules;
alternative serialization formats;
and additional mechanisms for machine knowledge exchange.

The current implementation architecture should not prevent those developments.

This is another reason to preserve the separation:

Publisher Knowledge Model
        ↓
WebMEM Conceptual Model
        ↓
Serialization

If a future serialization is defined, a publisher with a sound knowledge model should not need to reconstruct its knowledge from scratch.

It should be able to serialize the same material semantics through the new contract.

16.238 Extensibility Should Not Mean Semantic Instability

An extensible protocol still requires stable meaning.

A future version should not casually redefine:

what entity identity means;
what provenance represents;
what a relationship asserts;
how applicability participates in meaning;
or the distinction between source-observed and derived knowledge.

Extensions should add capability while preserving established semantic contracts wherever possible.

Conceptually:

Protocol Evolution
        ↓
More Expressive Capability
        ↓
Preserved Core Semantics

rather than:

Protocol Evolution
        ↓
Existing Knowledge Changes Meaning

16.239 New Fragment Classes Should Be Justified by Semantic Responsibility

Future implementations may discover recurring knowledge responsibilities that do not fit existing Fragment Classes cleanly.

A new Fragment Class may be justified when:

the knowledge performs a materially distinct semantic role;
the distinction recurs across implementations;
existing Fragment Classes would require misleading composition;
the class can be defined clearly;
and the distinction improves interpretation or validation.

A new Fragment Class should not be created merely because a publisher has a new visual page section or database table.

Fragment Classes exist to separate semantic responsibilities, not implementation artifacts.

16.240 New Relationships Should Be Justified by Domain Meaning

The same discipline applies to relationship vocabularies.

A publisher should not invent increasingly specific predicates simply to make the representation appear richer.

A relationship should exist because the publisher knows that relationship and can define what it means.

For example:

Plan
→ hasSegment
→ Segment

is useful because it expresses a material structural relationship.

A vague relationship such as:

Plan
→ connectedTo
→ Segment

preserves much less meaning.

Extensibility should increase semantic precision rather than vocabulary volume.

16.241 Future Serializations Should Preserve the Conceptual Model

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

A future serialization might use a different syntax or transport environment.

The test for compatibility should be whether it can preserve the same material knowledge.

For example:

Identity
Assertions
Datatypes
Units
Provenance
Relationships
Applicability
Fragment Classes
Resolution Structure
SDT Identity

If a new serialization cannot preserve those semantics, it is not merely another representation of the same model.

It may represent a different knowledge contract.

16.242 Implementation Should Anticipate Protocol Versioning

Publishers should expect the protocol to evolve.

At scale, it may therefore be useful to preserve:

Protocol Version
Serialization Version
Profile Version
Template Version
Data Version

These versions answer different questions.

For example:

Protocol Version:
Which WebMEM semantic contract applies?

Serialization Version:
Which concrete syntax applies?

Profile Version:
Which domain/resource requirements apply?

Template Version:
Which publisher implementation generated this?

Data Version:
Which knowledge state supplied the values?

Separating these dimensions makes migration and debugging substantially easier.

16.243 Backward Compatibility Is a Semantic Question

Backward compatibility should not be evaluated only by whether an older parser can read newer markup.

The more important question is whether established knowledge retains its meaning.

For example:

Version A:
Plan → hasSegment → Segment

Version B:
Plan → hasSegment → Segment

preserves the relationship even if the serialization changes.

But:

Version A:
Premium belongs to Segment

Version B:
Premium belongs to Plan

is not a backward-compatible semantic change merely because both versions parse successfully.

16.244 Protocol Migration Should Be Testable

A publisher migrating between WebMEM versions should be able to compare material semantics before and after migration.

Conceptually:

WebMEM Version A
        ↓
Extract Semantic Model
        ↓
Compare
        ↑
Extract Semantic Model
        ↑
WebMEM Version B

The migration test may ask:

Are entity identities preserved?
Are equivalent assertions preserved?
Is provenance preserved?
Are relationships preserved?
Is applicability preserved?
Are unresolved states preserved?
and does resolution remain semantically equivalent?

16.245 Implementation Can Support More Than the Public Web

The current implementation model centers on inline publication within canonical HTML resources.

But the underlying knowledge-engineering architecture may also support other environments.

For example:

Publisher Knowledge Model
        │
        ├── Public WebMEM
        ├── Internal Search
        ├── Enterprise Retrieval
        ├── Agent Interfaces
        ├── Data Exports
        └── Research Systems

Those systems may use different technical interfaces.

The important architectural lesson remains that explicit publisher knowledge can be reused rather than reconstructed independently for every consumer.

16.246 Public WebMEM Remains Resource-Scoped

The fact that the underlying publisher knowledge may support many systems does not change the scope of the public SDT.

WebMEM publication should remain appropriate to the resource.

For example:

Enterprise Knowledge:
all Plans
all Contracts
all Counties
all Formularies
all Historical Data

        ↓

County Resource SDT:
knowledge relevant to
that County resource

The public machine layer is a projection.

It is not necessarily a dump of the publisher’s complete internal knowledge environment.

16.247 Implementation Can Be Federated Across Publisher Systems

Large organizations may have several systems responsible for different kinds of knowledge.

For example:

System A:
Entity Identity

System B:
Benefits

System C:
Enrollment

System D:
Terminology

System E:
Editorial Policy

The WebMEM composition layer may federate those sources:

Identity Service ──────┐
Benefits Data ─────────┤
Enrollment Data ───────┤
Terminology ───────────┼→ SDT Composer
Editorial Knowledge ───┘
                              ↓
                         WebMEM

Each input can retain its own provenance and temporal state.

Federation should not flatten distinct sources into one generic publisher assertion.

16.248 Federation Requires Identity Discipline

When several systems contribute knowledge, they must agree sufficiently about the subjects being described.

For example:

Benefits System:
H5521-290-001

Enrollment System:
H5521 / 290 / 001

Publishing System:
segment:H5521-290-001

The implementation must establish that these identifiers refer to the same intended Segment before combining their assertions.

Otherwise federation can create false joins.

Shared identity is the prerequisite for safe knowledge composition.

16.249 Federation Requires Provenance Discipline

Likewise, knowledge contributed by different systems should retain its lineage.

For example:

Benefit Assertion
→ Source A

Enrollment Assertion
→ Source B

Derived Market Statistic
→ Sources A + B
→ Publisher Method

Combining the assertions into one SDT does not make their provenance identical.

16.250 Federation Requires Temporal Discipline

Different source systems may also represent different periods.

For example:

Benefits:
Plan Year 2026

Enrollment:
July 2026

Performance:
2026 Release

Derived Statistics:
Generated August 2026

The resource may legitimately contain all of them.

The implementation should preserve their distinct temporal meanings.

This is why a single page-level “last updated” date is often insufficient for the machine representation.

16.251 Implementation Can Support Publisher-Side Resolution Services

Some publishers may choose to build internal or public services around the same knowledge model used for WebMEM.

For example:

Contract ID
        ↓
Publisher Resolution Service
        ↓
Contract
        ↓
Plans
        ↓
Canonical Resources

or:

County
        ↓
Publisher Resolution Service
        ↓
Applicable Coverage Option Space

Such services may be useful.

They are not required by WebMEM.

The protocol allows the same resolution structure to be published directly in the applicable resource.

16.252 Resolvers Are Primarily Knowledge Architecture

A Resolver does not become a Resolver merely because it has a special endpoint or application route.

Its defining characteristic is semantic:

it represents the surrounding knowledge required to resolve a recurring entity or context into a useful information space.

That means a Resolver may be implemented as an ordinary canonical web resource containing:

Human Explanation
        +
WebMEM Resolver Representation

No specialized runtime service is inherently required.

16.253 Implementation Should Not Confuse Resolver Routing With Resolution

Routing answers:

Which resource should receive
this request?

Resolution answers:

What knowledge can be determined
from this identity or context?

For example:

/cms-contracts/H5521/

is routing.

The knowledge:

H5521
→ Contract
→ Carrier
→ Plans
→ Performance
→ Canonical Plan Resources

is resolution.

The implementation may combine both.

They should not be conceptually confused.

16.254 Implementation Can Use Existing Routing Systems

Publishers do not need a special WebMEM router.

Existing routing may continue to determine canonical resources:

WordPress Rewrite Rules

Application Router

Static File Paths

CMS Slugs

Server Routes

WebMEM can then identify the resource and represent its semantic purpose inside the resulting document.

16.255 Implementation Can Preserve Canonical Continuation Through Existing URLs

Existing web architecture can also provide canonical continuation targets.

For example:

County Resolver
        ↓
Plan Identity
        ↓
canonicalResource
        ↓
Existing Plan URL

The publisher does not need to invent a parallel semantic URL if the existing canonical resource already represents the entity appropriately.

This is another consequence of integrating the machine layer into the existing web rather than constructing a second one.

16.256 Implementation Should Avoid Semantic URL Proliferation

The original architecture proposed routes such as:

/semantic/json/
/semantic/ttl/
/semantic/md/
/formats/

The current implementation does not require those routes.

If the publisher has no independent operational reason for them, creating them adds:

routing complexity;
canonicality questions;
versioning obligations;
cache obligations;
provenance coordination;
and synchronization risk.

Do not create another URL merely because the interpreter is a machine.

16.257 The Canonical Human Resource Can Also Be the Canonical Machine Resource

This is perhaps the simplest expression of the current implementation model.

https://example.org/resource/

Human asks:
"What does this page explain?"

Machine asks:
"What knowledge does this resource expose?"

Same URL.
Different representation layer.

The page remains canonical for humans.

The same page can also be canonical for its resource-scoped machine knowledge.

The SDT itself may retain a distinct fragment identity within that resource:

https://example.org/resource/#webmem

This preserves identity without requiring another network endpoint.

16.258 The Implementation Architecture Has Become Smaller and Stronger

The 2025 architecture expanded outward:

Page
→ Digest Endpoint
→ Multiple Formats
→ Repository
→ Syndication
→ Reinforcement
→ Model-Specific Strategy

The 2026 architecture moves inward:

Publisher Knowledge
        ↓
Semantic Integrity
        ↓
SDT
        ↓
Inline Publication

The number of required systems decreased.

The quality demanded of the knowledge model increased.

This is not a reduction in ambition.

It is a clarification of where the hard problem actually lives.

16.259 The Implementation Architecture Reflects the Publisher’s New Job

The publisher’s old technical responsibility was largely:

Store information
        ↓
Render document
        ↓
Make document discoverable

The emerging responsibility is:

Store knowledge
        ↓
Understand semantic structure
        ↓
Render human representation
        +
Render machine representation
        ↓
Publish both coherently

This is the implementation consequence of the larger transition described throughout this paper.

The machine’s job changed.

Now the publisher’s must change with it.

16.260 From Infrastructure Deployment to Publishing Infrastructure

The original Part 16 treated Memory-First Publishing as a specialized infrastructure that publishers would deploy around their existing web presence.

The current framework reaches a different conclusion.

Machine-facing knowledge should become part of ordinary publishing infrastructure.

Not:

Website
        +
AI Infrastructure

but:

Publishing Infrastructure
│
├── Human Representation
└── Machine Representation

This is a much more durable architectural model.

16.261 The New Deployment Milestone

A publisher has reached the essential WebMEM deployment milestone when:

Publisher Knowledge
        ↓
Correct Semantic Model
        ↓
Conforming SDT
        ↓
HTML-in-HTML
        ↓
Canonical Resource
        ↓
Public Artifact Verified

At that point, the publisher has completed its core protocol responsibility.

It may then add:

additional resource profiles;
automation;
FactSmith-assisted knowledge engineering;
inspection tooling;
cross-surface validation;
temporal governance;
semantic diffing;
consumer observation;
and empirical research.

Those capabilities mature the implementation.

They do not redefine the basic publishing contract.

16.262 The New Implementation Principle

The entire Part can ultimately be reduced to a sequence:

Do not begin with markup.

Begin with knowledge.


Do not build a second web
unless you actually need one.

Publish the machine layer
with the canonical resource.


Do not generate multiple
semantic realities.

Generate both representations
from the same publisher knowledge.


Do not trust the generator alone.

Validate the public artifact.


Do not judge implementation
by whether a machine cites it.

Judge the representation first.

Then observe the machine.

16.263 Publisher Knowledge Should Control the Representation

The implementation architecture requires one additional distinction.

Publisher knowledge should not merely be supplied as context to whatever system generates the machine representation.

It should control what the representation is permitted to assert.

The original FactSmith architecture described this as a Master Fact Representation: a machine-readable controlling data structure constructed from normalized structured fact objects and used as the exclusive truth substrate for downstream generation.

The same architectural principle applies to machine-facing knowledge publication.

Conceptually:

Weak Architecture:

Publisher Data
        ↓
Generator Context
        ↓
Generator Decides
What to Represent
        ↓
WebMEM


Stronger Architecture:

Publisher Knowledge
        ↓
Controlling Semantic State
        ↓
Permitted Representation
        ↓
WebMEM

The distinction is important.

A generative system receiving factual context may still:

omit material knowledge;
generalize beyond source scope;
attach an assertion to the wrong entity;
infer an unsupported relationship;
collapse ambiguity;
or introduce knowledge not authorized by the publisher.

A controlling semantic representation establishes the permissible factual and structural universe before serialization begins.

Publisher knowledge should control the representation, not merely provide context for its generation.

16.264 The Intermediate Representation Is a Compiled Semantic Contract

Earlier sections introduced the possibility of an intermediate representation between publisher knowledge and WebMEM serialization.

At scale, that intermediate representation can perform a much stronger role.

It can function as a compiled semantic contract.

Conceptually:

Publisher Knowledge
        ↓
Resource Scope
        ↓
Semantic Compilation
        ↓
Intermediate Representation
        ↓
Validation
        ↓
Serialization

The Intermediate Representation, or IR, contains the knowledge already resolved for the particular publication task.

For example:

Resource:
Mohave County Medicare Options

IR:

resource_identity
county_identity
applicable_plan_collection
plan_segment_relationships
source_observed_assertions
derived_assertions
provenance
temporal_context
canonical_continuation

At this stage, the system should already know:

which entities are being represented;
which assertions belong to those entities;
which assertions are source-observed;
which assertions are derived;
which provenance applies;
which relationships exist;
which applicability conditions govern the knowledge;
which ambiguity remains unresolved;
and which semantic structures are permitted downstream.

The serializer should not reinterpret those decisions.

It should consume the validated IR and render the corresponding WebMEM structure.

IR
        ↓
WebMEM Serializer
        ↓
HTML-in-HTML

This makes the IR more than a convenient internal data object.

It becomes the semantic boundary between:

Knowledge Engineering

and

Publication Rendering

The IR defines what may be published. The serializer defines how it is expressed.

16.265 Executable Constraints Can Govern Publication State

Validation does not need to be limited to reporting warnings after a representation has been generated.

Machine-enforceable constraints can determine whether publication is allowed to proceed at all.

Conceptually:

Intermediate Representation
        ↓
Constraint Evaluation
        ↓
   ┌────┼─────┬─────────┐
   ↓    ↓     ↓         ↓
ADVANCE BLOCK REVERT TERMINATE

The states describe different implementation outcomes.

ADVANCE means the representation satisfies the applicable constraints and may proceed toward serialization.

BLOCK means publication cannot proceed until a required condition is satisfied.

REVERT means the system should return to an earlier knowledge-engineering or compilation stage because the current representation cannot be validated.

TERMINATE means the current publication attempt cannot legitimately continue.

For example:

Assertion:
monthly_premium = 18.50 USD

Source Scope:
Segment

IR Subject:
Plan

Constraint:
Assertion subject must preserve
source applicability scope

Result:
REVERT

Or:

Assertion:
average_monthly_premium

Derived:
true

Required:
derivation provenance

Provenance:
missing

Result:
BLOCK

Or:

Required Entity Identity:
missing

Cannot Resolve Subject:
true

Result:
TERMINATE

This turns conformance and semantic validation into active publication controls rather than passive diagnostics.

A representation known to violate a material semantic constraint should not be published merely because valid HTML can be produced from it.

16.266 Conflict Resolution Should Occur Before Serialization

Publisher knowledge may contain overlapping or conflicting assertions from multiple sources.

For example:

Source A:
premium = 18.50 USD

Source B:
premium = 22.00 USD

The serializer is the wrong place to decide which value is authoritative.

A generative model is also the wrong place to make that decision implicitly.

The conflict belongs upstream in the knowledge-compilation process.

Conceptually:

Source A ──────┐
               │
Source B ──────┼→ Normalization
               │
Source C ──────┘
                     ↓
                Fact Fusion
                     ↓
             Precedence Rules
                     ↓
           Publisher Knowledge
                     ↓
                    IR
                     ↓
               Serialization

Precedence rules may consider:

source authority;
source specificity;
temporal applicability;
source version;
geographic specificity;
entity scope;
publisher methodology;
and explicit exclusion rules.

For example:

Older Source:
premium = 18.50 USD
effective through 2025

Newer Source:
premium = 22.00 USD
effective beginning 2026

Resolution:
No factual conflict

2025 → 18.50 USD
2026 → 22.00 USD

Or:

National Record:
value = X

County-Specific Record:
value = Y

Resource Scope:
County

Precedence Rule:
more-specific applicable record

Resolution:
Y

If the publisher cannot resolve the conflict legitimately, the unresolved state should survive into the knowledge model rather than being hidden by arbitrary selection.

Conflict resolution is knowledge engineering. It should happen before publication rendering.

16.267 Inheritance Rules Should Be Machine-Enforceable

Many semantic defects arise not because a value is wrong, but because a valid value is inherited beyond the scope where it remains true.

For example:

Segment:
H5521-290-001

Premium:
18.50 USD

        ↓

Incorrect Inheritance

        ↓

Plan:
H5521-290

Premium:
18.50 USD everywhere

The source assertion may be completely correct.

The inheritance is not.

A mature implementation can encode explicit inheritance rules governing where knowledge may propagate.

For example:

Plan Year Context
        ↓
May Inherit To:
Plan
Segment
Benefit Assertions


Segment Premium
        ↓
May Inherit To:
Applicable Segment Resource

Must Not Inherit To:
Parent Plan Without
Applicability Qualification

Likewise:

CMS Source Metadata
        ↓
May Apply To:
Source-Observed Assertions

Must Not Automatically Apply To:
Publisher-Derived Assertions

Inheritance rules can therefore govern:

entity scope;
geographic scope;
temporal scope;
provenance scope;
relationship scope;
and fragment-level context.

This converts an important semantic principle into an executable implementation control.

Context should inherit only as far as it remains true.

16.268 Shared IR Ancestry Can Synchronize Human and Machine Artifacts

Two-tier publishing becomes substantially stronger when the human and machine representations do not merely use the same database, but inherit from the same validated semantic state.

Conceptually:

Publisher Knowledge
        ↓
Validated Resource IR
        ↓
   ┌────┴───────────────┐
   ↓                    ↓
Human Renderer      WebMEM Serializer
   ↓                    ↓
Human HTML          WebMEM SDT
   └─────────┬──────────┘
             ↓
      Canonical Resource

The IR becomes the shared semantic ancestor of both artifacts.

This is stronger than:

Human Renderer
→ queries database independently

WebMEM Serializer
→ queries database independently

because independent derivation may apply different:

selection logic;
scope rules;
precedence rules;
normalization;
derivations;
or applicability logic.

Shared IR ancestry allows both representations to inherit the same resolved knowledge state.

For example:

Validated IR:

county = Mohave County
plan_count = 42
average_monthly_premium = 15.26 USD
derived = true
source = CMS Landscape
plan_year = 2026

        ↓

Human Artifact:

"42 Medicare Advantage plans are
available in Mohave County, with an
average monthly premium of $15.26."

        ↓

Machine Artifact:

plan_count = 42
average_monthly_premium = 15.26 USD
derived = true
plan_year = 2026

The wording differs.

The semantic ancestry does not.

This architecture can extend beyond the two primary web representations:

Validated IR
│
├── Human Page
├── WebMEM SDT
├── FAQ
├── Comparison Table
├── API Response
├── Downloadable Report
└── Conversational Artifact

Each output may have different presentation requirements while inheriting the same permissible factual universe.

Multiple artifacts should diverge in presentation without silently diverging in truth.

16.269 Deterministic WebMEM Rendering Completes the Control Architecture

Once the Intermediate Representation has been validated, WebMEM generation can become a deterministic rendering operation.

Conceptually:

Validated IR
        ↓
Deterministic Serializer
        ↓
Conforming HTML-in-HTML
        ↓
Inline SDT

Given:

Same Validated IR
+
Same Serializer Version
+
Same Protocol Version

the publisher should be capable of producing materially equivalent WebMEM semantics across repeated executions.

The serializer does not need to reason about the knowledge.

It does not need to choose between conflicting facts.

It does not need to infer missing relationships.

It does not need to decide whether a value belongs to the Plan or Segment.

It does not need to determine whether an assertion is derived.

Those questions have already been resolved upstream.

The serializer’s responsibility is narrower:

Validated Semantic Input
        ↓
Correct Protocol Representation

This produces a clean separation:

KNOWLEDGE COMPILATION

Sources
→ Normalize
→ Resolve
→ Model
→ Apply Constraints
→ Validated IR


PUBLICATION COMPILATION

Validated IR
→ SDT Composition
→ HTML Serialization
→ Conformance
→ Canonical Resource

Where generative AI is used to create a human-facing artifact, that renderer may also be subordinated to the validated IR.

Where deterministic templates are sufficient, no probabilistic generation is required.

WebMEM itself therefore remains generator-agnostic.

The controlling architecture belongs upstream. The final renderer is replaceable.

16.270 The Complete Controlled Publication Pipeline

With these components added, the current implementation architecture can be expressed more completely:

                    SOURCE SYSTEMS
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     Structured       Editorial     Application
       Data            Content        Logic
          └──────────────┼──────────────┘
                         ↓
                  NORMALIZATION
                         ↓
                   FACT FUSION
                         ↓
                CONFLICT RESOLUTION
                         ↓
               PUBLISHER KNOWLEDGE
                         ↓
                RESOURCE PROJECTION
                         ↓
            INTERMEDIATE REPRESENTATION
                         ↓
               EXECUTABLE CONSTRAINTS
                         ↓
                  STATE CONTROL
             ┌───────────┼───────────┐
             ↓           ↓           ↓
          ADVANCE      REVERT      BLOCK
             ↓                       │
       VALIDATED IR              TERMINATE
             ↓
       ┌─────┴─────────────────┐
       ↓                       ↓
 HUMAN RENDERER          WEBMEM SERIALIZER
       ↓                       ↓
 HUMAN ARTIFACT           WEBMEM SDT
       └──────────┬────────────┘
                  ↓
           CANONICAL RESOURCE
                  ↓
        PUBLIC ARTIFACT VALIDATION
                  ↓
           ORDINARY WEB PUBLICATION

This architecture combines the strongest elements of the original FactSmith control model with the current WebMEM publication model.

FactSmith contributes the upstream discipline:

Facts
→ Compilation
→ Constraints
→ Validated Semantic State

WebMEM contributes the public machine contract:

Validated Semantic State
→ SDT
→ HTML-in-HTML
→ Canonical Resource

The two systems remain conceptually distinct.

But together they reveal a complete publisher architecture:

Compile knowledge before rendering it. Validate meaning before publishing it. Then allow every artifact—human or machine—to inherit from the same controlled semantic state.

Conclusion

The original implementation model was built around endpoints, formats, syndication, and reinforcement.

It assumed that publishing for machines required constructing a parallel semantic infrastructure around the human web.

Implementation experience produced a simpler architecture.

The publisher already has a public distribution system.

It is the web.

The publisher already has a canonical delivery object.

It is the resource.

The missing layer was not another endpoint.

It was the knowledge structure lost between the publisher’s internal systems and the public document.

The current implementation model therefore begins upstream:

Source Data
Editorial Content
Application Logic
Domain Knowledge
        ↓
Knowledge Engineering
        ↓
Publisher Knowledge Model
        ↓
Identity
Assertions
Provenance
Relationships
Applicability
Resolution
        ↓
Semantic Data Template
        ↓
HTML-in-HTML Serialization
        ↓
Conformance Validation
        ↓
Canonical Resource

The result is not a second web page for machines.

It is one resource carrying two representations of the publisher’s knowledge:

Canonical Resource
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
View       View

For structured-data publishers, the path may be almost entirely deterministic:

Data
→ Knowledge Model
→ SDT
→ WebMEM

For legacy content publishers, systems such as FactSmith can assist with the reverse problem:

Human Content
→ Knowledge Extraction
→ Publisher Review
→ Knowledge Model
→ SDT
→ WebMEM

For many publishers, the real architecture will be hybrid:

Structured Data
        +
Editorial Knowledge
        +
Application Logic
        ↓
Unified Publisher Knowledge
        ↓
Human + Machine Publication

That is a substantially different implementation model from the one proposed in 2025.

It requires less new distribution infrastructure.

It requires more semantic discipline.

The hard problem is no longer:

How many machine formats
should we publish?

It is:

What do we actually know?

What does it mean?

What is it about?

Where did it come from?

How does it relate?

Where and when does it apply?

What can be resolved from it?

What must remain unresolved?

Once those questions are answered, serialization becomes comparatively straightforward.

This changes the implementation priority from:

Distribution Infrastructure
        ↓
Machine Exposure

to:

Knowledge Infrastructure
        ↓
Machine Representation

It also changes the definition of deployment success.

A WebMEM implementation does not succeed because an answer engine cites it.

It succeeds first because:

the publisher’s knowledge is represented correctly;
material identity is explicit;
assertions are attached to the correct subjects;
provenance is recoverable;
relationships are preserved;
applicability is represented;
resolution structure is sufficient;
the serialization conforms;
the human and machine representations remain semantically compatible;
and the public artifact contains what the publisher intended to publish.

Only then does the publisher cross the machine boundary and ask:

What did the consumer do with it?

That question belongs to observation.

It does not redefine implementation.

The evolution of the architecture can therefore be stated simply:

2025

Build machine endpoints.
Publish multiple formats.
Syndicate them.
Reinforce them.
Condition retrieval.


2026

Understand the knowledge.
Represent it correctly.
Publish it inline.
Validate it.
Observe what happens.

The first architecture attempted to build infrastructure around machine behavior.

The second builds infrastructure around publisher knowledge.

That is the more durable implementation path because consumers can change without requiring the publisher’s truth to change with them.

Search engines can change.

Answer engines can change.

Models can change.

Agents can change.

Retrieval architectures can change.

The publisher’s responsibility remains:

Know what you know.

Preserve what it means.

Publish it without
unnecessarily throwing
the structure away.

WebMEM makes that responsibility deployable using the infrastructure publishers already possess.

No second web is required.

The machine layer can live inside the first one.