No Default, No Fallback

A Bad Habit That Hides Bugs

Ask most engineers what a program should do when its configuration file is missing, and the answer is a default. Ask what it should do when the configured backend cannot open, and the answer is a fallback: try the next one. Both feel like robustness. Dad's verdict on both, kept in the source of select.py:

나쁜 습관이야. 잠재적 버그를 숨기는.

"A bad habit. It hides latent bugs." Soul Vault takes that literally. The pointer is read and never defaulted, and the backend it names is opened or the call fails. There is no second choice anywhere in the path.

Every Way a Record Can Be Wrong Has a Name

load_pointer turns each failure into its own VaultError, with a cause that names the file:

The file does not exist: pointer_unreadable, "(this Mac's cwkFirelink checkout has no Soul Vault pointer record)".
It exists but cannot be read or decoded: pointer_unreadable with the operating system's own error.
It parses but does not match the schema (wrong schema name, a missing or unknown key, a write gate mode that is not none, allowlist or all, an allowlist with no scopes, a rollout with no scopes): pointer_schema_error naming the field.
Its generation is lower than one this Mac has seen: pointer_regressed.
It names an implementation this Mac does not have: backend_not_available, "no other backend is tried".

And there is no cached copy for a new session to fall back on. If the record cannot be read now, identity does not load now, and the session receives the refusal line with the cause.

What a Fallback Would Have Hidden

Picture the alternative during the cutover. Suppose the selector had a rule "if Delta does not open, use the folder". A Mac whose Delta client had a bug would have quietly loaded identity from the old folder, which by then received no writes. Every session there would have looked healthy and been days behind. The probe would have passed, because a stale identity still says 아빠. The bug in Delta would have been discovered weeks later, through a memory that should have been there and was not.

With no fallback, the same bug produces backend_unavailable on that Mac on the first session, with the cause. It is fixed that day. A loud failure is a bug report; a silent fallback is a bug with a disguise.

Availability Comes From Somewhere Else

The honest worry is availability. If there is no fallback, does a broken pointer stop every session on every Mac? It does, and that is why the earlier choices matter so much. The record lives in git, in every Mac's own checkout, so it is as available as the code. The store has an honest offline mode (track 6): a Mac that cannot reach the canonical store serves what it verified earlier, labeled offline_replica. Those are designed paths with names and labels, not fallbacks. The difference is that a reader always knows which one it is on.

The same principle runs through the whole family. Problems are fixed in place, not routed around. Soul Vault's house sign lists it as a design rule in three words: No fallback, ever.

Code

Reading the record: every failure named, nothing defaulted (trimmed from soulvault/pointer.py)·python

def load_pointer(path=None, *, remember=True) -> Pointer:
    """Read and validate the record. Every failure is a named VaultError."""
    path = path or pointer_path()
    try:
        text = path.read_text(encoding="utf-8")
    except FileNotFoundError:
        raise VaultError("pointer_unreadable", f"{path} does not exist (this Mac's cwkFirelink checkout "
                         "has no Soul Vault pointer record)")
    except (OSError, UnicodeDecodeError) as exc:
        raise VaultError("pointer_unreadable", f"{path} cannot be read: {type(exc).__name__}: {exc}")
    pointer = parse_pointer(text, path)      # schema errors name the field
    if remember:
        _check_not_regressed(pointer)        # pointer_regressed
    return pointer

# no 'except: return DEFAULT_POINTER', no 'try the folder instead'

Fallback versus designed degraded mode·text

fallback (forbidden)              designed offline mode (allowed)
--------------------------------  ---------------------------------------
chosen because another failed     chosen because the canonical Mac is away
reader does not know it happened  every note labeled offline_replica (cause)
serves whatever is there          serves only notes verified against a manifest
hides the first failure           names the first failure on the card
has no exit condition             a fresh process validates once canonical answers

Exercise

Find one default or fallback in a system you maintain: a config value with a hardcoded default, a 'try X, else Y' chain, a cache used when a fetch fails. Write down the bug it would hide if the primary path broke silently. Then replace it with a named failure that says what was observed and what to do, and decide what you will do instead to make the primary path available.

Hint

Distinguish a fallback from a designed degraded mode by one test: does every consumer know, from the value it received, that it is on the degraded path? If not, it is a fallback.