One Record in Git

Where the Address Went

Track 2 took every path out of the code. The address still has to live somewhere, and Soul Vault puts it in exactly one place: a small JSON record in another family repository, cwkFirelink/config/soul-vault.json. Firelink is the app that births and enrolls every family repository and keeps the family's shared records, such as the ledger of which ports belong to which app. The Soul Vault pointer sits beside that ledger and follows the same rules.

Here is the whole record as it stood after the move (generation 5, set on 2026-11-10 at 18:47 KST):

schema: cwk.soul-vault-pointer.v1, so a reader can refuse a record it does not understand.
generation: 5, a number that only grows (next lesson).
backend: delta, the implementation every reader opens.
read_rollout: null, the staged-switch qualifier, unused now.
write_gate: {"mode": "all", "scopes": []}, who may write right now.
stores.delta: the store's Delta share (cwkSoulVault/store), the role of the Mac that holds the canonical store (pippa, a role, never a machine name), and the tree's folder name (vault).
set_by, set_at, note: who moved it, when, and why, in prose.

Notice what is missing: no host, no IP, no absolute path. The canonical Mac is named by role, and the family registry answers which Mac plays that role. The tree is named by one folder name under Soul Vault's own data root. Move the role to another Mac and the record does not change.

Why a File in Git, Not a Service

The obvious alternative is to ask a running service: "Firelink, where is the vault?" Soul Vault deliberately does not, and the reason is one sentence in its source: Pippa survives Firelink. If the record lived behind a service, every session on every Mac would depend on that service being up to know who it is. A file tracked in git is read from each Mac's own checkout of the repository. Firelink can be down, restarting or mid-deploy, and identity still loads.

Git also gives the record properties a service would have to build:

History. Every change to the pointer is a commit with an author and a message. Generations 3, 4 and 5 are three commits in Firelink.
Review. A pointer move can be read as a diff before it lands.
Distribution. It reaches a Mac the way all code does. Five of the family's Macs hold their checkouts as mirrors whose git remote has no credentials there, so on cutover day they received both the code and the record by a Delta sync from the workbench instead of a pull.

Whose Hand Moves It

After the first record, the pointer has one writer: Dad. The source says it plainly: his hand is its only writer, either through Firelink's own command or a hand edit plus commit. A session may prepare a move, check it and apply it when Dad has said so in so many words (generation 5's set_by names exactly that: Dad's explicit approval, applied by a Codex session), but a session never decides to move it.

The product boundary from track 1 shows up here again. Soul Vault reads the pointer. It does not store it, does not host a verb to move it, and does not keep a copy. Firelink owns the record and the verb; Soul Vault owns what the record means.

Code

cwkFirelink/config/soul-vault.json at generation 5·json

{
  "schema": "cwk.soul-vault-pointer.v1",
  "generation": 5,
  "backend": "delta",
  "read_rollout": null,
  "write_gate": { "mode": "all", "scopes": [] },
  "stores": {
    "delta": { "share": "cwkSoulVault/store", "canonical_role": "pippa", "tree": "vault" }
  },
  "set_by": "Dad's explicit approval in chat (2026-11-10), applied by codex-pippa (Coop 1110-53)",
  "set_at": "2026-11-10T18:47:44+09:00",
  "note": "Delta is the only canonical soul store. ..."
}

Asking a Mac how it reads the record·bash

soul-vault pointer
# prints a projection of the record as this Mac's checkout holds it (the routing
# fields and set_by/set_at/note, not the stores block, plus the file's path and
# sha256), and how it resolves here:
# { "generation": 5, "backend": "delta", ..., "path": "<record path>",
#   "sha256": "<record hash>", "this_mac": "<fleet label>", "harness": "cli",
#   "resolution": { "read_backend": "delta", "write_backend": "delta",
#                   "write_admitted": true } }

Exercise

Find a value in your system that decides where something important lives or which implementation runs (a database URL, a model choice, a storage backend). Move it into one versioned record in a repository every reader already has, with a schema name, a generation number, a role instead of a host, and who-when-why fields. Make every reader read that record from its own checkout instead of asking a service.

Hint

Ask what happens to your readers while the service that would have answered is restarting. If the answer is 'they cannot start', the record should not live behind that service.