Three Outcomes

Success and Failure Are Not Enough

A local write has two outcomes: it happened or it did not. A write that crosses a network has three, and most systems collapse the third into one of the first two, usually the wrong one. Soul Vault names all three, and the dividing line is a single question: did the request leave this Mac?

It never left. The canonical Mac or this Mac's own Delta could not be reached, or a Delta on the way has no write call yet. The answer is canonical_unreachable, at once. Nothing was written and nothing is queued; the caller still holds its text and can try again later with a fresh read.
It left and no answer came back. The answer is outcome_unknown, carrying the request id. The write may or may not have landed. The caller settles it with request_outcome, or by sending the very same request id again, which the store answers with the first result if it completed (track 5). A soul's creation or removal checks the completed request first, too.
The store answered. Either its result, or its own named refusal raised again under the same name on the caller: revision_conflict, writer_sealed, rollout_hold and the rest. If Delta itself refuses (this Mac or this app may not write that share), that is policy_denied.

Each outcome tells the caller exactly what it may assume. Only the second leaves uncertainty, and that uncertainty has a name and a procedure, instead of a guess.

Proved on the Live Store

On 2026-11-10 between 17:19 and 17:22 KST, the outcomes were exercised against the real store from the MacBook, the workbench and a third Mac, each working only in a system-test soul it created and removed (the real vaults were not written, and the fixtures' tree and rows were gone afterwards):

A write from another Mac: 72 to 83 ms, one commit naming the request, the actor, the harness and the Mac Delta verified.
The same request id again: answered as replayed in 5 to 7 ms; still one commit.
A stale revision from a writer whose own view was a few seconds old: sent, and refused by the canonical store as revision_conflict naming the current revision (1.1 ms in its handler); no commit.
With the canonical Mac's Delta stopped for four seconds (under a timer that would start it again): from the MacBook and the third Mac, write_note answered canonical_unreachable in 0.4 to 1.6 s (the house link dropped, the tailnet tried), and the write call itself said "nothing was sent" in 5 to 9 ms. Afterwards the history was unchanged and neither request id had an outcome.

The Line in the Report That Did Not Hold

The architecture document records one more result, the uncomfortable one. On the workbench, that last step did not hold: Delta keeps answering for about a second after it is told to stop, and a write sent in that second was accepted and committed like any other. Nothing was wrong with the write; it really did land, and the answer said so. What failed was the test's assumption about when "stopped" begins.

The report could have left that line out, since the system behaved correctly. It keeps it, because a test whose setup did not do what it believed is not evidence for what it set out to prove. The honest summary is "never left" was demonstrated from two Macs, and on the third the setup raced the shutdown.

Code

A caller that respects all three outcomes (pattern)·python

def save(vault, note, text, rev, me, rid):
    try:
        return vault.write_note(note, text, expected_revision=rev, actor=me,
                                request_id=rid, reason="...")
    except VaultError as e:
        if e.code == "canonical_unreachable":      # 1. never left: nothing written, nothing queued
            keep_draft(note, text)                  #    the text stays with the caller
            raise
        if e.code == "outcome_unknown":            # 2. left, no answer: settle by request id
            done = vault.request_outcome(rid)
            return done if done is not None else vault.write_note(
                note, text, expected_revision=rev, actor=me, request_id=rid, reason="...")
        raise                                       # 3. the store answered with a named refusal

Did the request leave this Mac? (the decision table)·text

where it stopped                          answer                 what the caller may assume
----------------------------------------  ---------------------  ---------------------------------
before leaving (Delta / canonical away)   canonical_unreachable  nothing written, nothing queued
after leaving, no reply                   outcome_unknown (rid)  unknown: ask request_outcome(rid)
store replied                             result or its refusal  exactly what the store says
Delta refused (no permission)             policy_denied          nothing written

Exercise

For a networked write you own, classify every error the client can see into the three outcomes: never left, left without an answer, answered. Give each its own error name, make the 'left without an answer' error carry the request id, and add a status call that answers whether a request id completed. Then test 'never left' by stopping the server, and check whether the server really stopped before your first write.

Hint

Measure how long your server keeps accepting work after it is told to stop. If your test does not wait for that, your 'never left' result may be a race, exactly as the workbench run was.