Part 6: Knowledge Integrity and Observability

From Memory Governance to Publisher-Side Validation and Measurement

The original WebMEM framework proposed a Memory Governance Layer built around Trust Feedback Records and a Digest Authority Resolver.

The objective was ambitious.

Structured knowledge would be validated before ingestion, machine interactions with that knowledge would be observed after retrieval, and those observations would feed back into a system intended to reinforce future machine memory and trust.

That architecture combined three different problems:

Knowledge Validation
        +
Machine Behavior Observation
        +
Machine Memory Governance

Subsequent implementation revealed that these responsibilities do not belong to the same layer.

The publisher can validate the knowledge it publishes.

The publisher can observe externally visible machine behavior.

The publisher cannot govern the internal memory, trust model, ranking system, or ingestion policies of an independent consuming system.

The current WebMEM architecture therefore separates:

PUBLISHER CONTROL

Knowledge
→ Validation
→ Provenance
→ Conformance
→ Publication
→ Observation


CONSUMER CONTROL

Ingestion
→ Indexing
→ Retrieval
→ Trust Evaluation
→ Ranking
→ Reasoning
→ Citation
→ Memory

This produces a more defensible governance model.

Govern what the publisher controls. Observe what the publisher does not.

6.1 Knowledge Governance Begins Before Publication

The most reliable place to govern machine-facing knowledge is before that knowledge crosses the publishing boundary.

A publisher may know:

• where a source record originated;
• which entity the record describes;
• which transformations were applied;
• which values were calculated;
• which definitions govern field interpretation;
• which relationships are supported by source data;
• which geography or time period governs applicability;
• and which canonical resource represents the resulting entity.

Those are governance opportunities.

Before publication, a machine-facing representation can be evaluated for:

Identity Integrity
Provenance Integrity
Relationship Integrity
Applicability Integrity
Fragment-Class Integrity
Serialization Integrity
Conformance

This does not determine whether an external machine will trust the representation.

It determines whether the publisher has represented its own knowledge coherently.

6.2 From Digest Authority Resolver to Conformance Validation

The original Digest Authority Resolver attempted to act as a gatekeeper between public information and private AI memory.

It proposed three primary operations:

• term validation;
• provenance scoring;
• and assembly of a scored memory object for ingestion or rejection.

The first two operations exposed legitimate problems.

The third crossed the publisher-consumer boundary.

The current WebMEM architecture reframes the publisher-side portion as conformance validation.

Conceptually:

Publisher Knowledge
        ↓
WebMEM Representation
        ↓
Validation
│
├── SDT structure valid?
├── Fragment Class valid?
├── Subject identity present?
├── Assertions interpretable?
├── Provenance recoverable?
├── Derivation represented?
├── Relationships complete?
├── Applicability preserved?
├── References resolvable?
└── Serialization conforming?
        ↓
Publish

The validator does not return:

Trusted by AI:
0.94

It returns something much more defensible:

Conformance:
pass / fail

Validation Findings:
explicit and inspectable

WebMEM validation evaluates the representation. It does not assign machine trust.

6.3 Provenance Is Not a Trust Score

The original Memory Governance Layer treated provenance as one input to a computed trust score.

The current protocol gives provenance a more fundamental role.

Provenance preserves lineage.

For example:

Assertion:
monthly_premium = 18.50 USD

Subject:
segment:H5521-290-001

Source:
CMS PBP 2026

Publisher:
Example Publisher

Transformation:
normalized currency representation

or:

Assertion:
average_monthly_premium = 15.26 USD

Derived From:
CMS Landscape 2026

Method:
arithmetic mean

Generated By:
Publisher Calculation Pipeline

Neither representation tells a consuming system:

trust_score = 0.97

Instead, it exposes evidence from which a consuming system may make its own evaluation.

This distinction is central to the current WebMEM model:

Provenance
→ exposes lineage

Conformance
→ evaluates representation integrity

Consumer
→ determines trust according to its own policies

WebMEM publishes the evidence. It does not dictate the verdict.

6.4 Defined Terms Support Interpretation, Not Authority

The original Digest Authority Resolver also proposed validating every important term against an accepted glossary or external ontology.

Defined terminology remains important.

But glossary alignment does not automatically establish authority or truth.

A DefinedTermFragment may establish:

Term:
Maximum Out-of-Pocket

Canonical Identifier:
term:maximum_out_of_pocket

Definition:
...

Domain:
Medicare Advantage

An assertion may then reference that term.

This helps preserve what the publisher means by the field.

It does not prove that the asserted value is correct.

Likewise, an external identifier such as a public knowledge-graph identifier may help establish identity alignment without transferring authority from that external system to the publisher’s assertion.

Definitions establish meaning. Provenance establishes lineage. Neither should be misrepresented as an automatic trust score.

6.5 Conformance Is the Publisher-Side Gate

The current WebMEM Protocol places conformance at the final publisher-side boundary.

Before a representation is described as WebMEM-conforming, applicable requirements must be satisfied.

Conceptually:

Knowledge Model
        ↓
SDT Composition
        ↓
Fragments
        ↓
Assertions
        ↓
Identity
        ↓
Provenance
        ↓
Relationships
        ↓
Applicability / Resolution
        ↓
Serialization
        ↓
CONFORMANCE
        ↓
Published Representation

This gate is fundamentally different from the original Digest Authority Resolver.

It does not determine whether an external machine should ingest the knowledge.

It determines whether the publisher can legitimately claim that the published representation satisfies the applicable WebMEM requirements.

6.6 Validation Is Not Truth Certification

A WebMEM validator can test many things mechanically.

For example:

• Does the SDT have an identity?
• Does each fragment declare a recognized Fragment Class?
• Are fragment identifiers unique?
• Are required entity identities present?
• Are assertion values compatible with declared datatypes?
• Are units present where required?
• Do provenance references resolve?
• Do relationships contain identifiable sources, predicates, and targets?
• Are derived assertions distinguishable from source-observed assertions?
• Is inherited context internally coherent?

A validator cannot necessarily determine:

• whether the source dataset itself is correct;
• whether the publisher selected the correct source record;
• whether a real-world relationship is factually accurate;
• whether a derivation methodology is substantively appropriate;
• or whether a policy interpretation is legally correct.

Therefore:

Valid Representation
≠
Verified Truth

Conformance protects the integrity of the representation.

It does not transform WebMEM into an arbiter of reality.

6.7 Observation Begins After Publication

Once knowledge has crossed the publishing boundary, the publisher enters a different mode.

Control becomes observation.

A publisher may be able to observe evidence such as:

• whether a resource was crawled;
• whether a resource was indexed;
• whether machine traffic reached a resource;
• whether an answer system cited the resource;
• whether an entity appeared in generated answers;
• whether facts were reproduced accurately;
• whether source attribution was preserved;
• whether the wrong entity was associated with a fact;
• or whether an answer changed over time.

These observations can be valuable.

They do not reveal the complete internal state of the consuming system.

For example:

Observed:
Resource cited in answer

Does NOT prove:
Stored in model memory
Used in training
Preferred globally
Assigned specific trust weight

The current framework therefore distinguishes:

Observed Machine Behavior
≠
Inferred Internal Machine State

6.8 From Trust Feedback Records to Observation Records

The original Trust Feedback Record attempted to log interactions such as:

• retrieval;
• citation;
• paraphrase;
• contradiction;
• confidence;
• and changes in reinforcement weight.

The first four remain potentially observable behaviors.

The latter concepts depend on access to internal machine state that publishers generally do not possess.

A more defensible publisher-side observation record might contain:

resource_id

observed_system

observation_type

observed_query_or_context

observed_entity

observed_assertion

citation_present

attribution_present

factual_fidelity

observation_timestamp

evidence_reference

Such a record describes what was actually observed.

It does not claim to measure hidden trust or memory.

6.9 Observation Types

Useful observation categories may include:

Presence

Was the publisher or entity represented
in the observed answer?

Citation

Was the publisher's resource cited?

Attribution

Was the assertion attributed to
the correct source or publisher?

Factual Fidelity

Did the generated answer preserve
the material factual value accurately?

Identity Fidelity

Was the fact attached to
the correct entity?

Applicability Fidelity

Was the fact applied to
the correct geography, time,
segment, jurisdiction, or population?

Relationship Fidelity

Did the answer preserve
the correct relationship
between the participating entities?

These are observable outcomes.

They can be recorded and compared without pretending to know why the consuming system produced them.

6.10 Factual Fidelity Matters More Than Citation Alone

The original framework placed substantial emphasis on whether machines retrieved or cited a publisher’s content.

Citation remains useful, but citation alone does not establish successful machine interpretation.

Consider:

Publisher Fact:
segment:H5521-290-001
monthly_premium = 18.50 USD

Machine Answer:
"The plan has an $18.50 premium."

Citation:
Correct publisher

The citation may be correct while the answer has generalized a segment-specific premium to the parent plan.

The failure is semantic.

A stronger measurement model therefore asks:

Was the value correct?

Was the subject correct?

Was the applicability correct?

Was the relationship correct?

Was the provenance preserved?

Visibility without factual fidelity is not a successful outcome.

6.11 Citation Drift

The original framework correctly identified citation drift as an observable problem.

The concept survives, but it should be defined carefully.

Citation drift occurs when the relationship among an assertion, its apparent source, and the cited resource changes materially in machine-generated output.

For example:

Publisher A
→ derives statistic
→ from CMS Dataset

Machine Answer
→ states statistic
→ cites CMS directly

The underlying source lineage may be partially correct.

But the derivation performed by Publisher A has disappeared.

Another form:

Publisher A
→ publishes fact about Entity X

Machine Answer
→ repeats fact
→ attaches it to Entity Y
→ cites Publisher A

The citation survived.

The identity did not.

These observations can reveal where published semantic structure is failing to survive downstream interpretation.

6.12 Semantic Drift

A broader category is semantic drift.

Semantic drift occurs when machine-generated output materially changes the meaning of published knowledge.

Examples include:

• attaching a fact to the wrong entity;
• generalizing a child-specific assertion to a parent;
• applying a current value to a historical period;
• treating a derived statistic as source-observed;
• converting an option space into a recommendation;
• applying a policy outside its jurisdiction;
• or treating a relationship as transitive when it is not.

These failures correspond directly to the semantic distinctions WebMEM attempts to preserve at publication time.

6.13 Observation Does Not Establish Causation

This is one of the most important corrections to the original framework.

Suppose a publisher changes its WebMEM representation and later observes improved citation or factual fidelity.

The publisher may accurately state:

After publication change X,
observed outcome Y increased.

That does not automatically establish:

Change X caused internal model
mechanism Z to change.

Many factors may affect machine output:

• index updates;
• model updates;
• retrieval changes;
• source availability;
• ranking changes;
• query interpretation;
• prompt variation;
• freshness;
• or changes to competing sources.

Observation should therefore be recorded as observation.

Mechanistic explanations require separate evidence.

Measure the effect you can see. Do not invent the mechanism you cannot.

6.14 Feedback Still Matters

Removing machine-conditioning claims does not eliminate the value of feedback.

It changes what the feedback is used for.

Consider:

Publish
        ↓
Observe
        ↓
Detect Semantic Failure
        ↓
Investigate Publisher Representation
        ↓
Correct Identity / Provenance /
Relationship / Applicability
        ↓
Republish
        ↓
Observe Again

This is a legitimate publishing feedback loop.

But the loop operates on the publisher’s representation.

It does not claim to write directly into machine memory.

The publisher can use observed failures to ask:

• Was the entity identity ambiguous?
• Was provenance too coarse?
• Was a relationship left implicit?
• Was geographic applicability missing?
• Was the Fragment Class inappropriate?
• Was temporal context unclear?
• Was a derived value insufficiently distinguished from source-observed data?
• Was a parent-child distinction lost?
• Was an option space represented too loosely?
• Was the canonical continuation resource unclear?
• or was the machine-facing representation semantically correct and the observed failure simply outside the publisher’s control?

That final possibility matters.

Not every downstream failure indicates a publishing defect.

A conforming, semantically precise representation can still be ignored, misinterpreted, incompletely retrieved, or incorrectly synthesized by an external system.

The purpose of observation is to identify what can be improved—not to assume that every machine outcome can be controlled through publishing.

6.15 The Publisher Feedback Loop

The revised feedback model therefore looks different from the original Trust Feedback Record architecture.

Originally:

Publish Memory Object
        ↓
Machine Retrieves
        ↓
Trust Feedback Record
        ↓
Trust Delta
        ↓
Reinforcement
        ↓
Condition Future Machine Memory

The current model is:

Publish Knowledge Representation
        ↓
Observe External Behavior
        ↓
Record Evidence
        ↓
Compare Against Published Knowledge
        ↓
Identify Semantic Failure
        ↓
Correct What the Publisher Controls
        ↓
Republish
        ↓
Observe Again

The second loop is less speculative and more operationally useful.

It gives publishers a repeatable way to improve machine-facing knowledge without requiring access to proprietary model internals.

6.16 Presence and Fidelity Are Different Metrics

One of the most important lessons from observing answer systems is that presence and fidelity should be measured separately.

Presence asks:

Did the publisher, resource,
entity, or knowledge appear?

Fidelity asks:

Did the machine preserve
the meaning correctly?

A publisher may have high presence and poor fidelity.

For example:

Publisher:
frequently cited

Entity Identity:
frequently wrong

or:

Publisher:
frequently mentioned

Premium:
correct value

Geographic Applicability:
incorrect

Conversely, a publisher may have excellent factual fidelity when used but low overall presence.

Those are different problems requiring different responses.

Visibility measures whether the knowledge appears. Fidelity measures whether the knowledge survives.

6.17 A Practical Observation Model

A publisher evaluating machine-facing knowledge may maintain an observation record containing fields such as:

Field	Purpose
observation_id	Unique identifier for the observation
observed_system	System in which the behavior was observed
observed_at	Date and time of the observation
query_context	Prompt, query, or information need under observation
resource_id	Publisher resource relevant to the observation
entity_id	Entity whose representation is being evaluated
presence	Whether the entity or knowledge appeared
citation_present	Whether the publisher resource was cited
attribution_fidelity	Whether attribution remained correct
factual_fidelity	Whether material factual values remained accurate
identity_fidelity	Whether facts remained attached to the correct entities
relationship_fidelity	Whether material entity relationships remained correct
applicability_fidelity	Whether geographic, temporal, jurisdictional, or other scope remained correct
evidence	Reference to the observable output supporting the record

This is an observational model, not a required WebMEM Fragment Class or protocol object.

Its purpose is to illustrate how publishers can evaluate downstream behavior without claiming access to hidden machine state.

6.18 Observation Records Are Not Trust Feedback Records

The distinction between the original Trust Feedback Record and the revised observation model is fundamental.

Trust Feedback Record — 2025

Claimed to represent:
→ machine interaction
→ trust state
→ confidence
→ reinforcement weight
→ future conditioning signal


Observation Record — 2026

Represents:
→ externally observable behavior
→ evidence
→ comparison with published knowledge
→ identified semantic discrepancies

An observation record does not contain a trust_delta.

It does not claim that citation increased machine confidence.

It does not claim that repetition changed model memory.

It does not claim that an external system retained the represented knowledge.

It records what can actually be observed.

6.19 Observability Is Not Part of Core WebMEM Conformance

A publisher does not need to monitor answer engines in order to publish conforming WebMEM.

Observability is an operational practice built around the protocol, not a requirement of the core knowledge representation.

This distinction matters:

WebMEM Protocol
→ representation requirements

Conformance
→ whether those requirements were satisfied

Observability
→ what happened after publication

A resource can be fully conforming even if no external machine has ever retrieved or cited it.

Likewise, frequent citation does not prove that a resource conforms to WebMEM.

6.20 Conformance and Observability Work Together

Although observability is not required for conformance, the two can form a useful operational cycle.

Conforming Representation
        ↓
Publication
        ↓
Observation
        ↓
Semantic Comparison
        ↓
Potential Representation Improvement
        ↓
Validation
        ↓
Conforming Representation

Conformance gives the publisher a known internal standard.

Observability provides evidence about how knowledge survives outside the publisher’s systems.

Together, they allow publishers to distinguish between:

Representation Failure
→ something under publisher control

Consumer Failure
→ something outside publisher control

Unknown Cause
→ insufficient evidence

That third state is important.

A mature measurement system should be capable of saying:

We do not know.

6.21 Knowledge Drift at the Publisher

Not all semantic drift occurs downstream.

The publisher’s own representations can drift over time.

For example:

Source Dataset Updated
        ↓
Human Page Updated
        ↓
SDT Not Updated

or:

Entity Relationship Changed
        ↓
Application Updated
        ↓
Machine Representation Still Publishes
Old Relationship

or:

Derived Methodology Changed
        ↓
Derived Value Updated
        ↓
Provenance Still Describes
Old Method

These are publisher-side integrity failures.

They can be addressed through:

• shared generation pipelines;
• versioning;
• automated validation;
• source synchronization;
• conformance testing;
• and periodic comparison between human-facing and machine-facing representations.

6.22 Human/Machine Representation Drift

Two-tier publishing introduces a specific governance responsibility:

the human-facing and machine-facing representations must remain semantically aligned.

For example:

Human Page:
monthly premium = $18.50

SDT:
monthly_premium = 32.00 USD

is a material alignment failure unless the representations refer to different identities or applicability contexts that are explicitly preserved.

A publisher may therefore test:

Human Value
↔
Machine Assertion

Human Entity
↔
Machine Entity Identity

Human Citation
↔
Machine Provenance

Human Scope
↔
Machine Applicability

This is one reason shared data pipelines are preferable to independently maintained parallel content.

6.23 Source Drift

External source data also changes.

A source may:

• publish a new version;
• correct prior records;
• change methodology;
• retire a dataset;
• change identifiers;
• or alter publication cadence.

Provenance allows the publisher to identify which source version supported the published knowledge.

That makes it possible to distinguish:

Published Knowledge Was Wrong

from:

Published Knowledge Was Correct
for the Source Version and Time
Under Which It Was Published

This distinction becomes particularly important in regulated, historical, and time-sensitive information systems.

6.24 Temporal Integrity

Knowledge governance must preserve more than the date on which a page was updated.

Different temporal concepts may include:

Source Publication Date
Source Retrieval Date
Effective Date
Applicable Plan Year
Applicable Month
Publisher Generation Date
Publisher Modification Date

These dates are not interchangeable.

For example:

Retrieved:
2026-08-01

Applicable Plan Year:
2026

does not mean the underlying fact first became effective on August 1, 2026.

Likewise:

Page Modified:
2026-08-20

does not necessarily change the temporal applicability of the underlying source data.

Publisher-side governance should preserve these distinctions where they materially affect interpretation.

6.25 Governance Without Central Authority

The phrase Memory Governance Layer implied a centralized mechanism capable of determining which knowledge should enter machine memory.

The current WebMEM architecture makes no such claim.

There is no universal WebMEM authority deciding:

• which publisher is true;
• which source should be trusted;
• which assertion a model should prefer;
• or which knowledge a consuming system should retain.

Instead, WebMEM provides structures through which publishers can expose:

Identity
Provenance
Assertions
Relationships
Applicability
Derivation
Resolution Structure

Consuming systems remain free to evaluate those representations according to their own policies.

This is not centralized trust governance.

It is publisher-side knowledge accountability.

6.26 Trust Is a Consumer Judgment

This leads to a fundamental correction of the 2025 framework.

A publisher can publish evidence of trustworthiness.

A publisher cannot unilaterally publish:

Trust = true

and require an independent machine to accept it.

The publisher can expose:

• who created the source;
• when it was published;
• what dataset was used;
• how a value was derived;
• what entity it describes;
• which jurisdiction applies;
• and what canonical resources support further inspection.

The consuming system may then evaluate that evidence.

Trust is not a publisher-declared property. It is a consumer judgment informed by evidence.

6.27 Provenance Is the Durable Trust Infrastructure

The original Trust Feedback architecture searched for a mechanism capable of making machine trust persistent.

The more durable infrastructure was already present inside the model:

provenance.

Provenance does not guarantee trust.

It makes trust evaluation possible without severing the assertion from its lineage.

Assertion
        ↓
Source
        ↓
Creator
        ↓
Publication
        ↓
Transformation
        ↓
Derivation
        ↓
Responsible Publisher

When this chain remains recoverable, a consuming system has evidence it can evaluate.

When the chain disappears, the value may survive while its evidentiary meaning collapses.

This is why provenance became a core protocol component rather than merely one field in a trust-scoring system.

6.28 The New Governance Layer

If the term governance layer is retained at all, its 2026 meaning is substantially different from the original Memory Governance Layer.

It now describes the publisher-side practices that protect knowledge integrity:

Source Governance
        ↓
Identity Governance
        ↓
Provenance Governance
        ↓
Relationship Governance
        ↓
Applicability Governance
        ↓
Serialization Validation
        ↓
Conformance
        ↓
Publication
        ↓
Observability

The publisher governs the representation.

The publisher observes the ecosystem.

The consumer governs its own interpretation.

6.29 What Survived From Trust Feedback Records

Trust Feedback Records are no longer part of the core WebMEM Protocol.

But the original concept contained several durable observations:

• machine behavior should be measured rather than assumed;
• citation behavior can change over time;
• facts can survive while attribution drifts;
• machine interpretation can diverge from publisher intent;
• publisher representations should be validated before publication;
• provenance is central to evaluating machine-facing knowledge;
• and downstream observations can reveal weaknesses in publisher-side representation.

Those observations survive.

What does not survive is the assumption that publisher-generated feedback records can directly govern or reinforce the internal memory state of independent AI systems.

6.30 From Memory Governance to Knowledge Accountability

The original Part 6 asked how publishers might govern what machines retain, reuse, and trust.

The current framework asks a question the publisher can actually answer:

How do we ensure that the machine-facing knowledge we publish is identifiable, traceable, semantically coherent, and observable after it leaves our systems?

The resulting architecture is:

BEFORE PUBLICATION

Represent
→ Validate
→ Establish Provenance
→ Test Conformance


AFTER PUBLICATION

Observe
→ Compare
→ Diagnose
→ Correct What We Control
→ Republish

This creates a feedback loop without pretending the publisher controls the machine on the other side.

The shift is subtle but fundamental:

2025:
Govern machine memory.

2026:
Govern publisher knowledge.
Observe machine behavior.

The publisher cannot enforce trust inside the machine.

The publisher can make its own knowledge worthy of evaluation.