saagar patel: one writer, no lies
Sections

One Writer, No Lies

Rent the view. Own the truth.

ACT 1 · BEAT 1 OF 3 append on arrival · no key check

LOCAL the truth

outbox 0 rows

    REMOTE the view

    record 0 pages

        SYSTEM DIAGRAMS

        Keep the mechanism in view

        The simulation above plays six acts of a two-way sync: naive, then owned, then receipted, then laddered, then dry-run gated. These four diagrams hold that same machinery still, in the order the acts build it. Step through each one with the controls below its frame; the full diagram is always the resting state, and each is linkable on its own for a larger view.

        Three protocols, one system

        Every field, prose section, and event in this simulation gets one of three write protocols, chosen by its data shape, not by convenience. Structured fields diff to a single changed value and patch only that value, so one declared owner per field removes a whole class of merge conflict. Shared prose keeps its writer's fenced section and falls back through a write ladder when a direct patch will not land. Events queue durably in an outbox, and a record is not considered delivered until its downstream id docks back upstream as a receipt. Data shape chooses the protocol, and the protocol chooses the guarantee.

        Three protocols, one system Structured fields use diff and patch with one writer per field. Shared prose uses fenced sections and a fallback ladder. Events use an outbox with receipt writeback. Data shape chooses the protocol and its guarantee. Three protocols, one system The data shape chooses the reconciliation protocol, and with it the guarantee. DATA SHAPEPROTOCOLGUARANTEE Structured fieldsDerived properties withone declared owner eachfield:value Diff → patch changed fieldsUnchanged and manual fieldsnever enter the write set. Conflict avoidanceSingle writer per field.No merge algebra needed. Shared proseMultiple writers share a page,but own fenced sections.<!-- start / end --> Section merge → write ladderPreserve other owners, thendegrade through safe write shapes. Bounded coexistencePage-level merge withsection-level ownership. EventsDurable queue rows that mustbecome downstream records.SHIPPED · unprocessed Outbox → page → receiptWrite the downstream page, thendock its id back upstream. Auditable deliveryAt-least-once processing withdurable downstream proof. LOCAL TRUTH → SHAPE-SPECIFIC PROTOCOL → REMOTE MATERIALIZED VIEW
        1. Structured fields diff to one changed value and patch only that value; one declared owner per field means there is nothing to merge.
        2. Shared prose keeps each writer's fenced section, and falls back through the write ladder when a direct patch cannot land.
        3. Events queue in a durable outbox; a record counts as delivered only once its id docks back upstream as a receipt.

        Open this diagram on its own

        The write ladder

        Act 4 climbs this ladder every time a shared-prose section needs an update. It tries the boring outcome first: if the remote text already means the same thing, it writes nothing. Failing that, it swaps just the marker-fenced section, then a full safe replacement guarded by a child-reference check, then an anchor after the page's one unique heading, and finally an append after a verified-unique tail. Every rung is politer than a blind overwrite, and the ladder only descends when the rung above could not land safely. A transport error at any rung triggers a read-back check instead of a retry into the unknown.

        The five-rung managed-section write ladder The reconciler starts with a no-op equality check, then tries a targeted section swap, full safe replacement, insertion after a heading, and append after a unique tail. Transport ambiguity triggers read-back convergence. The write ladderFive ways to write one section, tried politest-first. 1Normalized equality → no-opIf remote already means the same thing, write nothing. The boring outcome is the preferred one.CLEAN · 0 writes 2Targeted section swapReplace only the marker-fenced section. Preserve every other writer's owned content.smallest patch 3Full safe replacementRebuild the page only after the child-reference guard proves nothing owned will be dropped.WAF may reject403 4Insert after the unique headingUse a blunter update shape anchored after H1 when content-sensitive patching is blocked.anchor fallback 5Append after a unique tailShrink a verified-unique tail anchor until the section can be placed without guessing.last safe rung TRANSPORT ERROR? READ BACK → normalized equal → read_back_converged
        1. Rung 1: if the remote already matches, the write is a no-op. Zero writes is the preferred outcome.
        2. Rung 2: a targeted section swap patches only the marker-fenced text, leaving every other writer's content untouched.
        3. Rung 3: a full safe replacement runs only after a child-reference guard proves nothing owned would be dropped.
        4. Rung 4: when content-sensitive patching is blocked, insertion anchors after the page's one unique heading.
        5. Rung 5, the last resort: shrink a verified-unique tail anchor until placement needs no guessing. A transport error triggers a read-back check instead of a blind retry.

        Open this diagram on its own

        The receipt loop

        Act 3 is where an event actually delivers. A local outbox row ships with no downstream reference yet; a key check runs before any write; a miss creates the remote page; and the remote id writes back to the local row as the receipt. Before this loop closed, a crash between create and receipt was a live bug: a retry with no durable key check could create a second remote page. After the fix, the retry queries the sync key first, finds the page that already exists, and writes only the missing receipt. Delivery is not done until proof docks upstream.

        The receipt loop closes the crash window An outbox row creates a remote page and receives the page id back as downstreamRef. Before the sync-key repair, a crash after create but before receipt could duplicate the page on retry. After the repair, retry queries by key and writes only the missing receipt. The receipt loopA downstream page is not delivered until its id docks back upstream. LOCAL OUTBOX#41 · SHIPPEDsync key: bridge:demo:41downstreamRef: empty key checkmiss → create REMOTE BUILD LOGpage · Project ASync Key: bridge:demo:41page id: remote-page-1 receipt: downstreamRef = remote-page-1 PRE-FIX CRASH WINDOWCreate landed · receipt did notRetry could create remote-page-2 because it hadno durable key check before writing. POST-FIX CONVERGENCERetry queries the sync key firstExisting page found → create is skipped → only themissing receipt is written back. Exactly one page. THE RECEIPT IS THE QUEUE'S PROOF THAT DELIVERY CONVERGED
        1. A local outbox row ships with no downstream reference yet.
        2. A key check misses, so the reconciler creates the remote page.
        3. The remote page id writes back to the local row as its receipt.
        4. Before the fix: a crash between create and receipt let a retry create a second remote page, because there was no durable key check.
        5. After the fix: a retry queries the sync key first, finds the existing page, and writes only the missing receipt. Exactly one page.

        Open this diagram on its own

        The orchestration gate

        Act 5 is the weekly discipline this simulation is built to defend: dry run first, write only what earns it. Six lanes always run dry, in a fixed order, with zero writes. A gate then asks three questions: was live requested, did the dry run find real drift, and did every lane finish clean. Any no, or any lane that failed or came back partial, stops the run before it writes a byte. Only a clean yes on all three opens phase two: guarded live execution of the approved drifting lanes, each write followed by a read-back or a loud failure.

        A broken preflight never escalates to writes The weekly refresh always runs six dry-run lanes first. Live execution opens only when live was explicitly requested, preflight found drift worth writing, and no lane failed or returned partial status. Broken, partial, or no-op preflights stop without writes. A broken preflight never escalatesWeekly maintenance is a two-phase gate: observe everything dry, then write only what passed. PHASE 1 · ALWAYS DRYFull preflight 1 · support maintenance2 · control tower3 · execution sync4 · intelligence sync5 · review packet6 · external signals writes: 0 GATElive requested?drift found?no failed/partial? Stop · zero writesbroken · partial · clean/no-op · no approval PHASE 2 · GUARDED LIVERun approved drifting lanesSame fixed order. Control-towerfailure skips every dependent lane. status: completed | cleanwrites: only verified drift after each writeread back / receipt / convergenceor fail loudly DRY RUN IS AN ANTI-ENTROPY AUDIT · LIVE IS A SEPARATE, EXPLICIT PHASE
        1. Phase 1 always runs dry: six lanes execute in a fixed order, and nothing writes yet.
        2. The gate asks three questions: was live requested, was drift found, and did every lane pass clean.
        3. Any no, or any failed or partial lane, stops the run with zero writes.
        4. Only a clean yes on all three opens phase 2: guarded live execution, each write followed by a read-back or a loud failure.

        Open this diagram on its own