An Atomic Cross-Agent Property Write Either Commits Fully or Rolls Back Fully

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOSContinuum/eOS-kernellib feature/cohesive-lift branch, when one operation appends a message to two separate rooms through the Merry batch surface in atomic mode, the two writes are a single all-or-nothing unit. cross_write(room_a, room_b, content) appends the same message mapping to each room's chat-room.message-log; run through MERRY->batch(this_object(), "cross_write", args, ([ "atomic": 1 ])) the commit path lands both rooms. A sibling cross_write_then_fail appends to the first room and then throws; under the atomic batch DGD rolls both writes back, so neither room retains the message. The all-or-nothing boundary spans two distinct objects with no application-level transaction code: the runtime carries the coordination that keeps the two writes coherent. This extends the single-room atomic-rollback demonstration (a post and its observer's cross-user write rolling back together) across the cross-room boundary.

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 (the cross-room writer and phase 9d of examples/chat-app/sys/test.c):

/* the cross-room writer: append one message to TWO rooms */
void cross_write(object room_a, object room_b, string content)
{
    mapping msg;
    msg = ([ "content": content, "timestamp": time() ]);
    room_a->set_property("chat-room.message-log", room_a->query_messages() + ({ msg }));
    room_b->set_property("chat-room.message-log", room_b->query_messages() + ({ msg }));
}

/* phase 9d: commit lands both; deliberate failure rolls both back */
MERRY_DAEMON->batch(this_object(), "cross_write",
                    ({ room_ba, room_bb, "commit" }), ([ "atomic": 1 ]));
/* asserts both rooms hold 1 message -- ATOMIC-COMMIT OK */
MERRY_DAEMON->batch(this_object(), "cross_write_then_fail",
                    ({ room_ba, room_bb, "rollback" }), ([ "atomic": 1 ]));
/* throws; asserts both rooms STILL hold only the committed 1 -- ATOMIC-ROLLBACK OK */

cross_write_then_fail appends to room_a then error()s before the second append; the atomic batch's error propagates and DGD unwinds the whole task, including the first append.

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

ChatApp:test: ATOMIC-COMMIT OK
ChatApp:test: ATOMIC-ROLLBACK OK
ChatApp:test: PARTIAL-STATE OK

ATOMIC-COMMIT OK writes only when both rooms hold exactly one message after the committing batch. ATOMIC-ROLLBACK OK writes only when the failing atomic batch threw AND both rooms still hold only the committed message (the partial first write rolled back). Both assertions are inside catch{}.

What the evidence establishes:

The atomic batch makes two writes to two separate objects one all-or-nothing unit: the commit lands both, and a mid-operation failure rolls both back.
The rollback is total across the cross-room boundary: the partial first write to room_a does not survive the throw -- there is no observable partial state.
The coordination is the runtime's: cross_write carries no transaction, journal, or compensating-write code; the atomic mode of the batch supplies the boundary.

What the evidence does not establish:

Concurrent contention between two atomic batches. This phase runs one batch at a time; serialization of two contending atomic operations is the write-coherence Observation, not this one.
Cross-instance atomicity. The two rooms are in one coherence domain; an atomic write spanning a process or machine boundary is outside the platform's primitive and not exercised.
The non-atomic partial-state outcome. That the same writer run without the atomic opt leaves the first room written is the paired negative (PARTIAL-STATE).

What Would Revise It

A committed batch that left one room unwritten, or a failed atomic batch that left the first room's partial write standing, would falsify the all-or-nothing claim; the current evidence shows both-or-neither.
A demonstration that the rollback missed a second-object write would contradict the cross-object totality claim; the current evidence shows both rooms unchanged after the failed batch.
A DGD or eOS-kernellib change to the batch atomic mode or to atomic-task rollback 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) -- cross_write / cross_write_then_fail helpers and phase 9d (ATOMIC-COMMIT / ATOMIC-ROLLBACK).
src/usr/Merry/sys/merry.c -- the batch(obj, func, args, opts) LFUN and its atomic-mode _atomic_run_callable path.
docs/chat-applications.md -- the "Multi-agent coherence" walkthrough, phase 9d.
The isolated runtime staging tree's src/usr/Chat/data/test-result.log -- the sentinel file; carries ATOMIC-COMMIT OK and ATOMIC-ROLLBACK 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-9d commit and rollback assertions), states the limits (no concurrent contention; single-coherence-domain; the non-atomic outcome is the paired negative), and lists concrete revision conditions.
informs_downstream::[[Multiple Agents See Coherent State Without User-Land Coordination]]
- The Conviction holds that the runtime carries the coordination that makes concurrent multi-agent state mutation tractable. This Observation shows the atomic batch carrying that coordination across two objects: an operation touching two rooms either commits fully or rolls back fully, with no application transaction code.
composes_with::[[Agent Operations Commit Wholly or Roll Back Wholly]]
- The cross-room write is one atomic envelope: the two appends commit together or unwind together. The atomic primitive is what makes "both rooms written" and "neither room written" the only two observable outcomes -- no partial cross-object state in between.
contrasts_with::[[A Non-Atomic Cross-Agent Property Write Leaves Partial State on Error]]
- The negative-case peer. This case shows the atomic batch rolling both writes back on failure; the negative shows the same writer run through a NON-atomic batch leaving the first room written and the second unwritten. Together they bound the mechanism: the all-or-nothing boundary is the atomic mode's contribution, and partial state is exactly what its absence leaves behind.