Part 14: Temporal Knowledge Integrity

Preserving Meaning Across Change, Version, and Time

The original Memory-First framework proposed Temporal Memory Mapping: a method for estimating how long knowledge remained retrievable by AI systems and scheduling repeated publication before presumed machine memory decayed.

The model introduced concepts such as:

• memory persistence curves;
• semantic epochs;
• recall plateaus;
• decay intervals;
• memory half-lives;
• and reinforcement schedules.

Those concepts attempted to explain changing machine outputs through an internal memory mechanism the publisher generally could not observe.

The current WebMEM framework does not retain that model.

But time remains fundamental.

Knowledge changes.

Sources change.

Relationships change.

Applicability changes.

Publisher representations change.

And external machine outputs change.

The current framework therefore replaces Temporal Memory Mapping with Temporal Knowledge Integrity.

The question is no longer:

How long will the machine remember this?

It is:

What was true, when was it true, what representation was published at that time, and does the current machine-facing knowledge preserve those distinctions correctly?

14.1 Time Is Part of Meaning

Some factual assertions are stable for long periods.

Others are inherently temporal.

For example:

Plan Year 2025:
monthly_premium = 18.50 USD

Plan Year 2026:
monthly_premium = 22.00 USD

Neither value is necessarily wrong.

The applicable time determines which assertion is relevant.

Likewise:

Listing Status — June:
active

Listing Status — August:
sold

or:

Interest Rate — Q1:
4.25%

Interest Rate — Q3:
4.75%

or:

Policy Version A:
effective through 2026-06-30

Policy Version B:
effective beginning 2026-07-01

In each case, time is not merely metadata describing publication.

Time participates in the meaning of the assertion.

14.2 Temporal Concepts Must Not Be Collapsed

A publishing system may contain several different dates associated with one knowledge object.

For example:

Source Publication Date

Source Effective Date

Source Retrieval Date

Applicable Period

Plan Year

Measurement Period

Publisher Generation Date

Publisher Publication Date

Publisher Modification Date

Observation Date

These dates describe different events.

They should not be treated as interchangeable.

For example:

Source Retrieved:
2026-08-01

Plan Year:
2026

does not mean:

Fact Became Effective:
2026-08-01

Likewise:

Page Modified:
2026-08-20

does not necessarily mean:

Underlying Knowledge Changed:
2026-08-20

Temporal precision begins by identifying what each date actually means.

14.3 Publication Time and Applicability Time Are Different

This distinction is especially important in machine-facing publishing.

Consider:

Published:
August 25, 2026

Applicable:
January 1–December 31, 2026

The publication event occurred in August.

The represented knowledge applies to the 2026 plan year.

Now consider:

Published:
October 1, 2026

Applicable:
January 1–December 31, 2027

The resource is published in 2026 but represents future-period knowledge.

A machine should not need to infer applicability from the page’s publication timestamp.

Where temporal applicability materially affects meaning, it should be represented explicitly.

14.4 Source Time and Publisher Time Are Different

Provenance may also contain several temporal events.

For example:

CMS Dataset
published:
2026-07-15

Publisher retrieved:
2026-07-18

Publisher transformed:
2026-07-19

Web resource published:
2026-07-20

These events form part of the knowledge lineage.

They should not be collapsed into one generic:

date = 2026-07-20

when the distinctions matter to interpretation or auditability.

14.5 Historical Truth Is Still Truth

A value does not become false merely because it is no longer current.

For example:

2025 premium:
18.50 USD

2026 premium:
22.00 USD

The correct interpretation is not:

18.50 USD = wrong

It is:

18.50 USD
→ historically applicable to 2025

22.00 USD
→ applicable to 2026

This distinction matters for historical resources, trend analysis, auditability, legal interpretation, financial records, public statistics, and other time-sensitive domains.

Current truth should not erase historical truth.

14.6 Supersession Is a Relationship

Some knowledge changes through replacement rather than simple value update.

For example:

Policy Version A
        ↓
supersededBy
        ↓
Policy Version B

or:

Dataset Release 2026-Q1
        ↓
supersededBy
        ↓
Dataset Release 2026-Q2

or:

Regulation Version A
        ↓
amendedBy
        ↓
Regulation Version B

The newer object does not necessarily make the older object meaningless.

The relationship explains their temporal order and current applicability.

This is more precise than simply deleting the earlier object or overwriting it without lineage.

14.7 Version Identity Matters

Where versions are materially distinct, they may require identifiable representation.

For example:

Dataset:
CMS Landscape

Release:
2026-07

Identity:
dataset:cms-landscape:2026-07

or:

Policy:
Example Coverage Policy

Version:
2026-07-01

Identity:
policy:example:2026-07-01

This allows provenance to point to the source version that actually supported the assertion.

Without version identity:

derivedFrom:
CMS Landscape

may be insufficient to determine which release produced the value.

14.8 Temporal Applicability Can Exist at Different Levels

Like other context, time may apply at several semantic scopes.

For example:

SDT Context:
plan_year = 2026

        ↓

DataFragment:
source_release = 2026-07

        ↓

Assertion:
enrollment = 1842

applicable_month = 2026-07

The plan year applies broadly.

The source release applies to the fragment.

The enrollment month applies specifically to the assertion.

The representation should preserve those distinctions rather than forcing all temporal context into one page-level date.

14.9 Temporal Context Should Be Declared Where It Is True

The same inheritance principle established elsewhere in the protocol applies to time:

SDT Temporal Context
        ↓
Fragment Temporal Context
        ↓
Sub-Structure Temporal Context
        ↓
Assertion Temporal Context

More-specific temporal context may override broader context where necessary.

For example:

SDT:
plan_year = 2026

DerivedStatsFragment:
source_period = 2026

Enrollment Assertion:
applicable_month = 2026-07

Declare temporal context at the broadest level where it remains true—and no broader.

14.10 Temporal Integrity and Provenance

Time is often inseparable from provenance.

Consider a derived statistic:

Source:
CMS Landscape 2026

Source Release:
2026-07-15

Publisher Retrieved:
2026-07-18

Method:
Arithmetic Mean

Publisher Generated:
2026-07-19

Applicable Plan Year:
2026

Each temporal field answers a different question:

When did the source publish?

When did the publisher obtain it?

When was the derivation performed?

What period does the result describe?

Preserving these distinctions allows later evaluation of whether a published assertion was reasonable given the information available at the time.

14.11 Temporal Integrity and Derived Knowledge

Derived knowledge creates a specific temporal problem.

Suppose:

July Dataset
        ↓
average_monthly_premium
= 15.26 USD

and a later source release changes the underlying records:

October Dataset
        ↓
average_monthly_premium
= 15.81 USD

The two derived values may both be correct relative to their respective source versions.

The publisher should preserve enough lineage to distinguish:

15.26
→ derived from July source state

15.81
→ derived from October source state

Without that context, downstream systems may treat legitimate historical differences as contradictions.

14.12 Temporal Integrity and Relationships

Relationships can also change over time.

For example:

2025:

Plan A
→ belongsToContract
→ Contract X


2026:

Plan A
→ belongsToContract
→ Contract Y

or:

June:

Provider
→ participatesIn
→ Network A


October:

Provider
→ no longer participatesIn
→ Network A

A relationship should not be treated as timeless when the publisher knows it is temporally bounded.

Temporal relationship integrity may therefore require:

Relationship
+
Effective Period

rather than only:

Subject
→ Predicate
→ Object

14.13 Temporal Integrity and Collections

Collection membership can change as well.

For example:

County Plan Index — 2025
├── Plan A
├── Plan B
└── Plan C


County Plan Index — 2026
├── Plan A
├── Plan C
└── Plan D

The collection should preserve the period to which membership applies.

Otherwise a consuming system may merge historical and current membership into one inaccurate collection.

14.14 Temporal Integrity and Resolvers

Resolvers frequently operate against time-sensitive knowledge.

For example:

County
        ↓
2026 Medicare Option Space

is not necessarily equivalent to:

County
        ↓
2027 Medicare Option Space

Likewise:

Contract
→ Current Plans

requires some definition of current.

A Resolver should preserve temporal context when the resolved information space changes over time.

Conceptually:

Entry Context
        +
Applicable Time
        ↓
Resolver
        ↓
Applicable Resolution Space

14.15 “Current” Is a Resolution Requirement

Natural-language information needs often contain implicit temporal language:

current
today
now
this year
latest
still
formerly
historically
next year

These words change the resolution requirement.

For example:

“Which plans are currently available in Mohave County?”

requires:

Geography
        +
Current Applicable Period
        ↓
Applicable Plan Collection

while:

“Which plans were available in Mohave County in 2025?”

requires a historical collection.

Temporal context is therefore part of Query-to-Resolution Mapping.

14.16 Future Knowledge Is Also Temporal Knowledge

Publishers may legitimately publish knowledge before it becomes effective.

For example:

Published:
October 2026

Applicable:
Plan Year 2027

The representation should distinguish:

Publication State:
available now

Applicability State:
future

A consuming system should not need to infer that distinction from surrounding prose or calendar assumptions.

14.17 Effective Time and Observation Time Are Different

The observability framework introduces another temporal dimension:

when the machine behavior was observed.

For example:

Publisher Reference:
Version A

Published:
August 1

Consumer Observation:
August 5

Publisher Reference:
Version B

Published:
August 10

Consumer Observation:
August 15

The August 5 reflection should be compared against Version A.

The August 15 reflection should be compared against Version B.

Comparing both observations against the current representation would corrupt the measurement.

14.18 Reference-State History

A mature observation system may therefore preserve historical publisher reference states.

Conceptually:

Reference v1
Effective / Published Period
        ↓
Observations A, B, C


Reference v2
Effective / Published Period
        ↓
Observations D, E, F


Reference v3
Effective / Published Period
        ↓
Observations G, H, I

This allows the publisher to answer:

What did we actually publish when this machine output was observed?

That question is essential for meaningful longitudinal analysis.

14.19 From Memory Epochs to Observation Periods

The original framework defined Memory Epochs such as initial exposure, recall plateau, decay, and rebinding.

The current framework does not infer those hidden memory states.

But defined Observation Periods remain useful.

For example:

Period A:
Before WebMEM Publication

Period B:
Early Post-Publication

Period C:
Stable Publisher Representation

Period D:
After Source Update

Period E:
After Representation Revision

These periods describe observable publisher and measurement states.

They do not claim to describe internal stages of machine memory.

14.20 From Memory Decay to Output Drift

The original framework interpreted declining citation or paraphrase consistency as memory decay.

The current framework uses the more defensible term output drift.

For example:

June:
Publisher cited
Correct fact

July:
Publisher cited
Correct fact

August:
Publisher absent
Correct fact

September:
Publisher absent
Wrong fact

The output changed over time.

That is observable.

The cause may involve:

• consumer updates;
• retrieval changes;
• index changes;
• source changes;
• competitive sources;
• query interpretation;
• publisher changes;
• or unknown mechanisms.

The publisher can accurately state:

Observed output changed over time.

The publisher should not automatically conclude:

The machine forgot the knowledge.

Output drift is observable. Memory decay is an inference about hidden machine state.

14.21 Output Drift Can Be Measured Temporally

The semantic fidelity framework developed earlier can be extended across time.

For example:

Observation Period	Presence	Factual Fidelity	Identity Fidelity	Applicability Fidelity
Period A	42%	98%	96%	91%
Period B	57%	97%	95%	92%
Period C	51%	94%	90%	81%

The measurements describe changing observable outcomes.

They do not require a theory of memory half-life.

A decline in applicability fidelity, for example, is meaningful regardless of whether the underlying cause is retrieval, model behavior, source selection, or another mechanism.

14.22 Temporal Comparison Requires a Stable Observation Frame

Longitudinal measurement becomes unreliable if the observation conditions change without being recorded.

For example:

June:
Query A
Consumer A
Location X

August:
Query B
Consumer B
Location Y

does not provide a clean basis for concluding that machine behavior changed over time.

Where practical, temporal comparisons should preserve:

• query family;
• consumer identity;
• material query context;
• geographic context;
• session state where relevant;
• measurement definitions;
• and the applicable publisher reference state.

Changes in those conditions should be recorded rather than silently treated as temporal drift.

14.23 Temporal Comparison Requires the Correct Reference

The reference against which a machine output is evaluated must correspond to the knowledge applicable at the time of observation.

Consider:

2025 Reference:
premium = 18.50 USD

2026 Reference:
premium = 22.00 USD

An answer observed in 2025 should not be marked incorrect because it differs from the 2026 value.

Likewise, a 2026 answer should not be evaluated against an obsolete 2025 representation.

This creates a temporal comparison rule:

Observed Reflection at Time T
        ↓
Compare Against
        ↓
Applicable Publisher Reference at Time T

Without that alignment, fidelity measurement itself can become temporally incorrect.

14.24 From Reinforcement Schedules to Update Policies

The original Temporal Memory Mapping framework prescribed refresh schedules such as every two weeks, monthly, quarterly, or before anticipated periods of retrieval demand.

The current framework does not prescribe arbitrary republication schedules for machine reinforcement.

Instead, publishers should maintain update policies tied to legitimate knowledge events.

For example:

Source Dataset Updated
→ Evaluate affected knowledge

New Plan Year Published
→ Generate applicable representations

Regulation Changed
→ Update affected Policy knowledge

Entity Relationship Changed
→ Update relationship

Methodology Changed
→ Recalculate derived knowledge

Semantic Defect Discovered
→ Correct representation

The update event is tied to knowledge integrity.

It is not tied to an assumed machine-memory refresh interval.

14.25 Event-Driven Updating Survives

One concept from the original Temporal Memory Mapping framework does survive strongly: event-driven updating.

The reason changes.

The original model used events as semantic clocks intended to refresh machine memory.

The current model uses events because they may change the underlying knowledge or its applicability.

For example:

CMS Data Release
        ↓
Source State Changed
        ↓
Determine Affected Assertions
        ↓
Regenerate Representations
        ↓
Validate
        ↓
Publish

or:

New Regulation
        ↓
Policy Changed
        ↓
Determine Effective Date
        ↓
Supersede Prior Policy
        ↓
Publish New Applicable Knowledge

The event triggers knowledge maintenance, not memory reinforcement.

14.26 Source Cadence Can Drive Publisher Cadence

Different source systems operate on different schedules.

For example:

Source A:
annual

Source B:
quarterly

Source C:
monthly

Source D:
event-driven

A publisher integrating those sources should not necessarily assign one generic freshness date to the resulting resource.

Each knowledge component may have its own source cadence and applicable period.

This creates a more accurate model:

Resource
│
├── Knowledge A
│   └── Source Cadence: annual
│
├── Knowledge B
│   └── Source Cadence: quarterly
│
└── Knowledge C
    └── Source Cadence: monthly

Temporal integrity preserves these distinctions where they matter.

14.27 “Last Updated” Is Often Too Coarse

A single page-level:

Last Updated:
August 25, 2026

may be useful for human readers.

But it may be semantically inadequate for a machine-facing representation containing knowledge from several sources and periods.

For example:

Landscape Data:
2026 Plan Year

Performance Data:
2026 Release

Enrollment Data:
July 2026

Derived Statistics:
generated August 2026

One page modification date cannot replace those source-specific temporal semantics.

The human resource may still display a simplified update statement.

The machine representation can preserve the more precise temporal structure.

14.28 Artificial Freshness Is Not Temporal Integrity

The original reinforcement model encouraged refreshing content partly to create new exposure.

The current framework distinguishes genuine update from artificial freshness.

For example:

Knowledge unchanged

Source unchanged

Relationships unchanged

Applicability unchanged

        ↓

Change publication date anyway

does not make the knowledge more current.

It changes a timestamp.

Likewise:

Rewrite definition
with different wording

        ↓

Underlying meaning unchanged

does not create a new knowledge state.

Temporal metadata should describe real temporal events, not simulate freshness.

14.29 Change Detection Should Begin Upstream

A mature temporal publishing system should detect change as close to the source as practical.

Conceptually:

Source Version N
        ↓
Compare
        ↑
Source Version N+1
        ↓
Identify Material Changes
        ↓
Map Changes to Publisher Knowledge
        ↓
Regenerate Affected Representations

This is preferable to blindly regenerating every resource on a calendar.

Change detection can identify:

• new entities;
• retired entities;
• changed values;
• changed relationships;
• changed applicability;
• changed source metadata;
• and changes affecting derived calculations.

14.30 Temporal Dependency Mapping

One source change may affect many downstream representations.

For example:

Plan Premium Record Changes
        ↓
Plan Resource
        ↓
County Resolver
        ↓
Derived County Average
        ↓
Comparison Resource

The publisher may therefore maintain a temporal dependency model:

Source Change
        ↓
Affected Assertions
        ↓
Affected Fragments
        ↓
Affected SDTs
        ↓
Affected Resources
        ↓
Affected Derived Knowledge

This turns updating into a dependency problem rather than a page-refresh problem.

14.31 Derived Knowledge Must Be Re-Evaluated When Inputs Change

A source update may leave some direct assertions unchanged while invalidating derived knowledge.

For example:

Plan A Premium:
unchanged

Plan B Premium:
changed

Plan C Premium:
unchanged

        ↓

County Average Premium:
must be recalculated

The publisher should not assume that a derived assertion remains valid merely because its own record was not directly edited.

Its validity depends on its inputs and method.

Temporal dependency tracking makes that relationship explicit.

14.32 Temporal Integrity and Caching

Caching introduces another temporal layer.

A publisher may update the underlying knowledge while an older machine-facing representation remains cached.

Conceptually:

Database:
Version B

Generated SDT:
Version B

Public Cache:
Version A

The publisher’s internal knowledge is current.

The public machine representation is not.

Temporal integrity therefore extends through the publication pipeline:

Source
→ Database
→ Transformation
→ SDT
→ Page
→ Cache
→ Public Resource

A stale layer anywhere in that chain can expose obsolete knowledge.

14.33 Temporal Integrity and Distributed Resources

Cross-surface publishing creates additional temporal risk.

For example:

Plan Resource:
Version B

County Resolver:
Version B

Contract Resolver:
Version A

The publisher now exposes inconsistent knowledge states simultaneously.

Cross-surface consistency testing should therefore include temporal state.

A resource may be semantically correct in isolation and still be stale relative to the publisher’s current knowledge environment.

14.34 Temporal Consistency Does Not Require Simultaneous Publication

Large publishing systems may not be able to update every affected resource at exactly the same moment.

Temporary differences do not automatically constitute a protocol failure.

The publisher should instead manage:

• update ordering;
• version boundaries;
• cache invalidation;
• effective dates;
• and reasonable propagation windows.

Where partial publication could create materially misleading knowledge, deployment may need to be coordinated more tightly.

The appropriate strategy depends on domain risk.

14.35 Temporal Integrity and Conformance

Conformance cannot guarantee that every published value is current.

But where temporal context is required to interpret an assertion correctly, omitting that context may create a semantic conformance problem.

For example:

premium = 18.50 USD

may be structurally valid.

If the same Plan has different premiums across plan years and no applicable period is recoverable, the representation may be semantically insufficient.

The applicable conformance requirements should therefore distinguish:

Timestamp Present
        ≠
Temporal Meaning Preserved

14.36 Temporal Integrity and Resolution Coverage

Query-to-Resolution Mapping can reveal temporal requirements directly.

Consider:

“What is this plan’s premium?”

If the Plan has:

2025:
18.50 USD

2026:
22.00 USD

then time is part of the resolution requirement.

Without applicable year:

Resolution State:
UNRESOLVED

Required Context:
plan_year

Likewise:

“Which plans are available now?”

requires a current applicable period.

Resolution coverage is incomplete if the publisher cannot distinguish current from historical membership.

14.37 Temporal Ambiguity Should Be Preserved

Just as geographic ambiguity should not be collapsed, temporal ambiguity should remain explicit when necessary.

For example:

Question:
"What is the applicable rate?"

Known:
Product identity

Unknown:
effective date

Rates:
4.25% through June
4.75% beginning July

The correct state is not to choose the newest or oldest rate automatically.

It is:

UNRESOLVED

Required Context:
effective date

“Latest” and “applicable” are not always the same thing.

14.38 Temporal Integrity and Consumer Independence

Different consumers may refresh their knowledge at different times.

For example:

Publisher:
Version B live

Consumer A:
reflects Version B

Consumer B:
still reflects Version A

Consumer C:
mixes values from A and B

The publisher should not create different current truths for each consumer.

The publisher maintains the correct current representation and observes consumer lag independently.

This is consumer independence applied to time.

14.39 Consumer Lag Is Observable

When a publisher changes a representation, different consumers may reflect that change at different times.

A publisher can record:

Publisher Version B:
published August 1

Consumer A:
first observed Version B behavior
August 3

Consumer B:
first observed Version B behavior
August 9

Consumer C:
first observed Version B behavior
August 18

This is an observable propagation pattern.

It may be operationally useful.

But it should not automatically be interpreted as:

memory reinforcement lag

or:

model retraining interval

The underlying mechanism may be unknown.

14.40 Propagation Lag Is Not Memory Half-Life

This distinction replaces another concept from the original framework.

The publisher may measure:

Time From Publication
        ↓
First Observed Updated Reflection

This can be called an observed propagation lag or reflection lag.

It describes what happened externally.

It does not measure how long a model “remembered” the prior value.

For example:

Version B Published:
Day 0

Consumer Reflects Version B:
Day 12

Observed Reflection Lag:
12 days

The publisher does not know whether those twelve days resulted from crawling, indexing, caching, retrieval refresh, model behavior, or another mechanism.

14.41 Temporal Observability Metrics

The temporal framework can therefore use metrics grounded in observable events.

Examples include:

Metric	Meaning
Source-to-Publish Lag	Time between relevant source availability and publisher representation update
Representation Age	Time since the current publisher representation was generated or materially changed
Observation Interval	Time between defined consumer observations
Reflection Lag	Time between publisher change and first observed corresponding consumer change
Output Stability Period	Period during which an observed semantic outcome remains materially consistent
Drift Detection Time	Time between first detectable output change and publisher detection
Correction Lag	Time between confirmed publisher-side defect and corrected publication

These metrics describe operational and observable temporal behavior.

They do not require estimating hidden memory half-lives.

14.42 Output Stability Is Not Memory Stability

A machine may produce the same answer repeatedly over several months.

The publisher can accurately describe:

Observed Output:
stable for 90 days

That does not establish:

Machine Memory:
stable for 90 days

The same observable output could result from many different internal states or retrieval paths.

The distinction remains:

Output Stability
→ observable

Memory Stability
→ inferred

Temporal measurement should remain on the observable side of that boundary.

14.43 Temporal Drift Can Occur Without Publisher Change

A publisher may leave a representation completely unchanged while external machine behavior changes.

For example:

Publisher Reference:
unchanged

June Reflection:
correct

July Reflection:
correct

August Reflection:
incorrect

September Reflection:
correct again

This is useful evidence because it demonstrates that machine-mediated interpretation is itself temporally variable.

The publisher may investigate:

• whether competing sources changed;
• whether source selection changed;
• whether the consumer changed;
• whether the query context changed;
• or whether another observable condition explains the difference.

If the publisher reference remained correct throughout the period, there may be no publisher-side intervention to make.

Temporal variation in the reflection does not necessarily imply temporal failure in the reference.

14.44 Publisher Drift Can Occur Without Consumer Drift

The inverse is also possible.

A publisher may accidentally introduce a stale or incorrect representation while an external system continues returning the previously correct answer.

For example:

Publisher Reference v1:
premium = 18.50 USD
correct

Publisher Reference v2:
premium = 32.00 USD
incorrect for applicable geography

Consumer Reflection:
18.50 USD
still correct

The machine’s correct answer does not validate the publisher’s new representation.

This reinforces an important principle:

Consumer output is not the publisher’s source of truth.

The publisher must validate its own knowledge independently.

14.45 Source Drift, Publisher Drift, and Consumer Drift

Temporal integrity becomes easier to reason about when three different forms of change are separated.

SOURCE DRIFT

The upstream source changes.


PUBLISHER DRIFT

The publisher representation changes,
becomes stale, or diverges from the source.


CONSUMER DRIFT

The observed machine reflection changes.

These may occur together.

They may also occur independently.

For example:

Source Changes
        ↓
Publisher Does Not Update
        ↓
Publisher Drift


Publisher Updates
        ↓
Consumer Continues Old Answer
        ↓
Consumer Lag


Source Unchanged
Publisher Unchanged
        ↓
Consumer Answer Changes
        ↓
Consumer Drift

Separating these states prevents every temporal change from being labeled “memory decay.”

14.46 Temporal State Transitions

Some knowledge can be represented as movement through defined states.

For example:

FUTURE
        ↓
CURRENT
        ↓
HISTORICAL

or:

ACTIVE
        ↓
SUPERSEDED

or:

PROPOSED
        ↓
EFFECTIVE
        ↓
REPEALED

or:

LISTED
        ↓
PENDING
        ↓
SOLD

The applicable state vocabulary belongs to the domain.

WebMEM’s concern is that state transitions material to interpretation remain recoverable rather than being inferred solely from page age or publication order.

14.47 Temporal State Is Not Universal

The protocol should not impose one universal lifecycle on every kind of knowledge.

A Medicare Plan, legal regulation, real-estate Listing, financial rate, public dataset, and glossary definition do not share the same temporal model.

For example:

Medicare:
plan_year

Legal:
effective_date / repeal_date

Real Estate:
listing_status / status_date

Finance:
rate_effective_period

Government Data:
reference_period / release_date

The domain defines which temporal distinctions matter.

The protocol provides a structure through which those distinctions can remain explicit.

14.48 Stable Knowledge Should Remain Stable

Not all knowledge needs frequent temporal intervention.

A definition may remain valid for years.

An institutional identifier may remain stable indefinitely.

A mathematical formula may not require routine republication.

If:

Knowledge unchanged
Source unchanged
Meaning unchanged
Applicability unchanged

then repeated modification is unnecessary merely because time has passed.

This directly reverses the original reinforcement-schedule model.

Stable knowledge does not need artificial motion.

14.49 Volatile Knowledge Requires Stronger Temporal Architecture

Other knowledge changes frequently.

Examples may include:

• enrollment counts;
• financial rates;
• inventory;
• listing status;
• provider participation;
• prices;
• regulatory status;
• and operational availability.

For these domains, temporal integrity may require stronger controls around:

• source cadence;
• effective periods;
• version identity;
• cache invalidation;
• dependency regeneration;
• and stale-data detection.

The update architecture should reflect the volatility of the knowledge rather than an arbitrary publishing calendar.

14.50 Temporal Risk Is Domain-Dependent

The consequences of stale knowledge also vary.

For example:

LOWER RISK

Outdated descriptive wording


MODERATE RISK

Old market statistic


HIGHER RISK

Outdated insurance benefit


CRITICAL RISK

Expired eligibility or regulatory rule
presented as currently applicable

A publisher may therefore prioritize temporal controls according to both change frequency and consequence.

This is a more defensible basis for refresh policy than presumed machine-memory decay.

14.51 Temporal Integrity Can Be Validated

Many temporal defects can be tested mechanically.

For example:

• Does the assertion have required applicable-period context?
• Does the source version exist?
• Does the effective period conflict with the parent context?
• Does a superseded object incorrectly claim current status?
• Does a historical relationship lack an end date where one is required?
• Does a current collection contain expired members?
• Was a derived statistic regenerated after its inputs changed?
• Does the public cache expose an older representation than the current generated artifact?

Domain-specific validators may add stronger rules.

Temporal integrity therefore becomes an engineering concern rather than a publishing intuition.

14.52 Temporal Integrity Can Be Observed

The Publisher Feedback Loop adds a second temporal layer after publication.

The publisher can observe:

Reference State
        ↓
Consumer Reflection
        ↓
Time
        ↓
New Consumer Reflection

This makes it possible to measure:

• reflection lag;
• output stability;
• fidelity changes;
• citation changes;
• identity drift;
• applicability drift;
• and resolution drift.

The publisher measures what changed.

It does not need to invent an internal memory lifecycle to explain the observation.

14.53 A Temporal Integrity Dashboard

The original framework proposed a Temporal Fitness Dashboard centered on recall curves and memory decay.

A revised dashboard might instead monitor publisher-controlled temporal integrity and external temporal observations separately.

Publisher Temporal Health:

Source Versions Current          PASS
Applicable Period Coverage       99%
Derived Dependencies Current     PASS
Cross-Surface Temporal Match     98%
Stale Cache Findings             0
Supersession Integrity           PASS
Historical References Valid      PASS

Observed Temporal Outcomes:

Consumer A Reflection Lag        3 days
Consumer B Reflection Lag        9 days
Consumer C Reflection Lag        unknown

30-Day Factual Fidelity          97%
30-Day Applicability Fidelity    94%
30-Day Resolution Fidelity       91%

Material Output Drift Events     2

Again, the distinction is deliberate.

One side measures publisher knowledge maintenance.

The other measures observable external behavior.

14.54 From Reinforcement ROI to Maintenance Value

The original framework proposed evaluating which reinforcement activities produced the longest machine-memory persistence.

The current framework can evaluate a more concrete operational question:

Which knowledge-maintenance practices most effectively preserve current, coherent, and auditable publisher representations?

For example:

• automated source-diff detection;
• dependency-aware regeneration;
• shared source-of-truth pipelines;
• versioned provenance;
• cross-surface consistency testing;
• cache validation;
• and temporal conformance checks.

These investments improve the publisher’s knowledge infrastructure regardless of how any particular consumer behaves.

14.55 From Semantic Epochs to Knowledge States

The original concept of semantic epochs attempted to describe stages in machine recall.

A more useful temporal model describes states in the publisher’s knowledge lifecycle.

For example:

Source Available
        ↓
Ingested
        ↓
Normalized
        ↓
Validated
        ↓
Published
        ↓
Current
        ↓
Superseded / Historical

For derived knowledge:

Inputs Current
        ↓
Derived
        ↓
Validated
        ↓
Published
        ↓
Input Changed
        ↓
Derivation Stale
        ↓
Recalculated

These states can be observed and governed directly.

14.56 Temporal Integrity Extends the Provenance Chain

Provenance answers:

Where did this knowledge come from?

Temporal integrity adds:

When did each relevant event occur?

What period did the knowledge describe?

Which version was used?

When did the representation change?

What superseded it?

Together, they create a more complete lineage:

Source
        ↓
Source Version
        ↓
Source Publication Time
        ↓
Publisher Retrieval
        ↓
Transformation
        ↓
Publisher Generation
        ↓
Applicable Period
        ↓
Published Representation
        ↓
Supersession / Historical State

This is especially important when knowledge must later be audited or reconstructed.

14.57 Temporal Integrity Extends Resolution

Resolution also becomes more precise when time is treated as part of context.

Instead of:

Entity
        ↓
Applicable Knowledge

many domains actually require:

Entity
        +
Time
        +
Other Context
        ↓
Applicable Knowledge

For example:

Plan
+
County
+
Plan Year
        ↓
Applicable Segment
        ↓
Premium

or:

Statute
+
Jurisdiction
+
Effective Date
        ↓
Applicable Rule

or:

Financial Product
+
Date
+
Term
        ↓
Applicable Rate

Time is often not an annotation on resolution. It is one of the inputs to resolution.

14.58 Temporal Integrity Extends Consumer Independence

Part 13 established:

One Reference
→ Many Reflections

Time extends that model:

Reference v1
        ↓
Many Reflections at Time A

Reference v2
        ↓
Many Reflections at Time B

Reference v3
        ↓
Many Reflections at Time C

The publisher controls the sequence of reference states.

Each consumer may reflect those states differently and at different times.

The publisher should preserve both histories without conflating them.

14.59 The Temporal Publishing Model

The complete temporal architecture can now be expressed as:

Source State
        ↓
Source Version
        ↓
Publisher Knowledge State
        ↓
Applicable Period
        ↓
Representation Version
        ↓
Validation
        ↓
Publication
        ↓
Current / Future / Historical State
        ↓
Consumer Observation
        ↓
Temporal Fidelity Measurement
        ↓
Change Detection
        ↓
Publisher Maintenance

This is a temporal system the publisher can actually govern.

14.60 What Survived From Temporal Memory Mapping

The original Temporal Memory Mapping concept contained several observations that remain useful:

• machine outputs change over time;
• one successful retrieval does not guarantee future retrieval;
• publishing systems require ongoing observation;
• external events can materially change the information environment;
• different consumers may reflect updated knowledge at different times;
• and static publication is insufficient for knowledge that genuinely changes.

Those observations survive.

What does not survive is the assumption that those changes can be modeled reliably as:

Exposure
→ Machine Memory
→ Decay
→ Reinforcement
→ Rebinding

without evidence of the internal mechanism.

14.61 From Memory Half-Life to Knowledge Integrity

The conceptual change can be stated directly:

TEMPORAL MEMORY MAPPING — 2025

Publish
        ↓
Machine Exposure
        ↓
Recall
        ↓
Memory Plateau
        ↓
Decay
        ↓
Reinforcement
        ↓
Rebinding


TEMPORAL KNOWLEDGE INTEGRITY — 2026

Source State
        ↓
Publisher Knowledge
        ↓
Applicable Time
        ↓
Versioned Representation
        ↓
Publication
        ↓
Observation Over Time
        ↓
Detect Source / Publisher /
Consumer Drift
        ↓
Maintain What the Publisher Controls

The first model attempted to map the machine’s memory lifecycle.

The second maps the publisher’s knowledge lifecycle and the observable behavior around it.

14.62 The New Temporal Principle

The publisher does not need to keep stable knowledge moving merely to make it appear fresh.

The publisher does need to know:

• which source version supports an assertion;
• when the assertion applies;
• when relationships apply;
• which representation was public at a given time;
• what has been superseded;
• what remains historically valid;
• what changed;
• and whether dependent knowledge was updated accordingly.

That is a substantially stronger temporal discipline than publishing on a reinforcement calendar.

Conclusion

The original Temporal Memory Mapping framework treated time as a threat to machine recall.

The current framework treats time as part of knowledge itself.

Some knowledge is current.

Some is historical.

Some is future.

Some is superseded.

Some changes monthly.

Some remains stable for decades.

The publisher’s responsibility is not to keep repeating all of it so machines do not forget.

The publisher’s responsibility is to preserve which knowledge was true, when it was true, why it was true, and which representation applies now.

Then observe how external systems reflect that knowledge over time.

The transition is:

2025:
Manage the machine's presumed memory timeline.

2026:
Manage the publisher's actual knowledge timeline.

Time is not a reinforcement schedule.

Time is part of the meaning.