Three Users in One Chat Room Observe Identical Message Order

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOS-kernellib chat-app multi-agent-coherence branch, when three users in one chat room each read the message log after a sequence of posts, all three reads return identical content in identical order. The log is one property (chat-room.message-log) on the room clone, recorded by a single append observer; the readers hold no per-user copies, so each query_messages() returns the same shared array. The append-only structure preserves posting order, so every reader sees the same sequence. No reader runs a reconciliation, a version check, or a merge -- the runtime keeps the single shared view coherent, which is the read-side companion of the write-coherence serialization.

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 into the isolated runtime staging tree.

Setup (verifiable from repo state):

Driver: DGD 1.7.9 built from dworkin/dgd; binary symlinked into the runtime staging tree.
Kernel layer: eOSContinuum/eOS-kernellib's chat-app multi-agent-coherence branch at HEAD fbda75a.
Application layer: examples/chat-app/, deployed with the Chat domain overlay.
Runtime config: the instance config; the chat-app smoke script runs the three-boot regression and counts OK sentinels (expected 20).

Load-bearing source (a phase of examples/chat-app/sys/test.c):

/* one append observer on the shared room; three messages post in order */
MERRY_DAEMON->register_observer(room_r, "chat-room.message", "main", SRC_APPEND);
CHAT_DAEMON->post_message(judy, room_r, "one");
CHAT_DAEMON->post_message(kevin, room_r, "two");
CHAT_DAEMON->post_message(leo, room_r, "three");

/* three independent reads of the one shared log */
seen_j = room_r->query_messages();
seen_k = room_r->query_messages();
seen_l = room_r->query_messages();
/* asserts: each sees 3; order is one/two/three; the three reads agree */

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

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

COHERENCE OK writes only when all three reads return three messages, the first/second/third contents are one/two/three, and the three readers agree on the first and last entries. The assertion is inside catch{}; a wrong count, a wrong order, or a disagreement among readers each logs a distinct FAIL.

What the evidence establishes:

Multiple readers of one runtime property see the same state at the same time: the three reads return identical content with no reconciliation step.
Message order is preserved across all readers by the append-only log structure; no reader observes a reordering.
The coherence is the runtime's: the readers carry no merge, version, or cache-invalidation logic -- they read the shared property and agree.

What the evidence does not establish:

Genuine wall-clock concurrency among the reads. DGD's single-threaded scheduling runs the three reads as sequential tasks; "simultaneous" here means interleaved sequential tasks reading one coherent property. The demonstration shows shared-state coherence, not parallel reads.
Cross-instance read coherence. The demonstration is single-coherence-domain; reads crossing a process or machine boundary are outside the platform's primitive and not exercised.
Divergence under application caching. That the divergence appears only when a reader holds a private cached snapshot is the paired negative Observation, not this Observation.

What Would Revise It

A case where two readers of the shared log disagreed on content or order would falsify the identical-order claim; the current evidence shows all three reads agree.
A reordering of the append-only log (a later message appearing before an earlier one) would contradict the order-preservation claim; the current evidence shows one/two/three in posting order.
A DGD or eOS-kernellib change to property-read or single-threaded task semantics would invalidate the snapshot; the claim rests on DGD 1.7.9 plus the cited eOS-kernellib HEAD.

Sources

examples/chat-app/sys/test.c (eOS-kernellib) -- the coherence phase: three users read one shared log.
examples/chat-app/obj/room.c (eOS-kernellib) -- query_messages / the chat-room.message-log property.
docs/chat-applications.md (eOS-kernellib) -- the "Multi-agent coherence" walkthrough, coherence phase.
The result log written into the runtime staging tree's usr/Chat/data/ path -- carries COHERENCE OK after a clean boot.
The chat-app smoke script and the instance config -- the three-boot regression harness and runtime config.

Relations

conforms_to::[[Observation Form Contract]]
- Carries has_epistemic_status::[[Empirical Observation]], names the measurement (one three-boot smoke run; the coherence-phase assertion), states the limits (no wall-clock concurrency; single-coherence-domain; divergence-under-caching is the paired negative), and lists concrete revision conditions.
informs_downstream::[[Multiple Agents See Coherent State Without User-Land Coordination]]
- The Conviction holds that all agents see the same state at the same time. This Observation is the positive evidence for the read-coherence half: three readers of one shared log observe identical content and order with no reconciliation, the companion to the write-coherence serialization the bounded-resource Observation shows.
contrasts_with::[[A Cached Snapshot Read Diverges From the Live Shared Log]]
- The negative-case peer. This case shows that reading the shared property keeps all readers coherent; the negative shows that a reader holding a private cached snapshot drifts from the live log once a further write lands. The two together bound the mechanism: coherence is the runtime's standing condition for shared-property reads, and divergence appears only when an application caches state the runtime already keeps coherent.