Components

The inventory scanner

Sweeps the machines a vault describes and regenerates the registers that say what runs where.

This is the one component that crosses between the two maps. Its input is infrastructure — real machines, real services, what is actually listening — and its output is a file in the vault.

Everything else here reads a vault and writes a vault, or reads an external system and writes a vault archive. This reads the world and writes a register.

The registers are generated, which has one consequence

Hand-editing one loses the edit on the next sweep. That sounds like a nuisance and is actually the point: a register that can be hand-edited is a register that disagrees with reality the moment someone is in a hurry.

If something in a generated register is wrong, the fix is upstream — in the machine list the scanner reads, which is the declared source of truth for which machines exist at all.

Why a vault needs this at all

Because the documentation that goes stale fastest is the documentation about infrastructure, and it goes stale silently. A runbook that names a host, a port and a path is correct until someone moves the service, and nothing about the document changes when they do.

A generated register is wrong for at most one sweep.

This part is not published

A local script in a private repository. The pattern is the transferable part: declare the machines by hand, generate everything derived from them, and make the generated files obviously generated so nobody edits one by mistake.

From ecosystem.yaml, contract 41 · core-skills 1.89.4 · read at build 2026-10-08