A Cached Snapshot Read Diverges From the Live Shared Log

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOSContinuum/eOS-kernellib feature/cohesive-lift branch, when a reader caches its own copy of a chat room's message log and a further message then posts, the cached snapshot disagrees with the live shared log. A reader captures the log (three entries) into a local variable, a fourth message posts through the append observer, and a fresh read of the live property returns four entries while the cached copy still holds three. The divergence is the failure mode the runtime's coherent shared state removes by construction: it appears only because the reader held a private snapshot instead of reading the shared property at use time. This is the read-side analogue of the lost update -- both are costs an application incurs by acting on state captured before a concurrent change rather than reading current state when it is needed.

Grounds

This is an Empirical Observation. The grounds are a captured three-boot smoke run 2026-05-31 against the live MVA demonstration instance with examples/chat-app/ overlaid at the isolated runtime staging tree's src/usr/Chat/.

Setup (verifiable from repo state):

Driver: DGD 1.7.9 built from dworkin/dgd; binary symlinked at the isolated runtime staging tree's bin/dgd.
Kernel layer: eOSContinuum/eOS-kernellib on feature/cohesive-lift at HEAD fbda75a.
Application layer: examples/chat-app/, deployed into the isolated runtime staging tree with the Chat domain overlay.
Runtime config: the instance config; the three-boot regression harness (expected 20 sentinels).

Load-bearing source (phase 9c of examples/chat-app/sys/test.c, the cached-diverge half):

/* after three messages have posted to room_r */
cached = room_r->query_messages();              /* private snapshot: 3 entries */
CHAT_DAEMON->post_message(judy, room_r, "four"); /* a fourth message lands */
live = room_r->query_messages();                /* live shared log: 4 entries */
/* asserts: sizeof(cached) == 3; sizeof(live) == 4 -- the cache has drifted */

The append observer's Set($this, "chat-room.message-log", Get(...) + ({ $new })) builds a NEW array on each append, so the property points at the four-element array while cached still references the three-element array captured before the post.

Smoke transcript (the load-bearing portion of the result log after boot 1):

ChatApp:test: COHERENCE OK
ChatApp:test: CACHED-DIVERGE OK

CACHED-DIVERGE OK writes only when the cached snapshot stayed at three entries AND the live read advanced to four. The assertion is inside catch{}; a mutated cache or a non-advancing live log each logs a distinct FAIL.

What the evidence establishes:

A reader's private cached copy drifts from the shared log once a further write lands: the cache shows three, the live property shows four.
The divergence is application-introduced: it exists only because a snapshot was held, not because the runtime failed to keep the shared log coherent (the live read is correct at four).
Reading the shared property at use time -- the COHERENCE positive -- is what avoids the drift; caching is what reintroduces it.

What the evidence does not establish:

A runtime coherence failure. The live read is correct; the divergence is in the application's held copy, not in the shared state. The Observation is about the cost of caching, not a defect in the platform.
Cross-reader divergence under shared reads. Three readers of the shared log agreeing is the paired positive (COHERENCE), not this case.
A general claim about all caching. The demonstration is one held snapshot across one intervening write; it does not characterize cache-staleness windows under arbitrary workloads.

What Would Revise It

A cached snapshot that tracked the live log without an explicit re-read would contradict the drift claim; DGD's copy-on-append for the property is what keeps cached at three. A change making query_raw_property return a live-updating reference would revise this.
A live read that did not advance to four would indicate the append observer failed, a different (FAIL) outcome than the one captured.
A DGD or eOS-kernellib change to array-value or property-write semantics would invalidate the snapshot; the claim rests on DGD 1.7.9 plus feature/cohesive-lift HEAD fbda75a.

Sources

examples/chat-app/sys/test.c (in eOS-kernellib feature/cohesive-lift) -- phase 9c (CACHED-DIVERGE): a held snapshot drifts from the live log.
examples/chat-app/sys/test.c -- SRC_APPEND (the append observer building a new array per post).
docs/chat-applications.md -- the "Multi-agent coherence" walkthrough, phase 9c.
The isolated runtime staging tree's src/usr/Chat/data/test-result.log -- the sentinel file; carries CACHED-DIVERGE OK after a clean boot.
The three-boot regression harness and the instance config.

Relations

conforms_to::[[Observation Form Contract]]
- Carries has_epistemic_status::[[Empirical Observation]], names the measurement (one three-boot smoke run; the phase-9c cached-diverge assertion), states the limits (not a runtime failure; one snapshot across one write), and lists concrete revision conditions.
informs_downstream::[[Multiple Agents See Coherent State Without User-Land Coordination]]
- The Conviction holds that the runtime keeps all readers coherent so application code need not reconcile. This Observation is the negative evidence: where an application caches state the runtime already keeps coherent, the cached copy drifts -- the divergence the shared-property read removes.
contrasts_with::[[Three Users in One Chat Room Observe Identical Message Order]]
- The positive-case peer. The positive shows that reading the shared log keeps all readers coherent; this negative shows that holding a private snapshot drifts from the live log once a further write lands. Together they bound the mechanism: coherence is the runtime's standing condition for shared-property reads, and divergence appears only when an application caches.