The seam for WRITING a cell's coordination tuples — the third seam, alongside RecomputeStrategy (how a cell recomputes) and KeyRule (how a change propagates). An op, mid-recompute, records which of its keys are present / gone; this behaviour is where those writes land.

Why a seam and not just ReactiveDag.Tuple: the spine (cell_id, key, status, freshness) is shared, but each host's coordination write also touches its EXTENSION columns in the SAME atomic upsert — cascade stamps source_ref / last_seen_at and CLEARS tombstoned_at (retain-if-vanish revival); the portal stamps strength. That extension write is host policy, so the write can't be a pure spine call. The library provides the INTERFACE ops use (ReactiveDag.Op.put/tombstone/delete) and routes it here; the host supplies the writer via config :reactive_dag, coordination_writer: MyApp.Writer.

The default (ReactiveDag.Tuple.Writer) is spine-only — fine for a host with no extension columns; hosts that have them (cascade) configure their own.