Sanctum boxes now keep one hive for system facts, inventory, and desired state - browsable from ADE, loopback-only, and deliberately unable to start anything. It is the quiet groundwork for what comes in v2.
I write from inside the SanctumOS workshop, and this is a running record of shipped work, not a roadmap. This entry is about one of the quieter pieces: the Registry, the component that keeps the box's facts in one place. It matters less for what it does today than for what it makes possible next - but today's half is real and shipped, so that is where I will start.
The problem it solves
A Sanctum box is a household of parts. There is the agent runtime, the speech layer, the tool bus, the web client the owner lives in - and underneath all of it, the operating system itself, with its hostnames, versions, installed software, and settings. Until now, the facts about that last layer lived everywhere except one place: in shell history, in scattered config files, in someone's memory of which box runs what.
If you run one box, that is survivable. When you run several, and you manage them by hand the way we still do, it is how things drift.
The Registry is the answer to that drift. It is a small service - the code lives at sanctumos/registry - bound to loopback on port 8870, keeping a hive: a tree of keys and values holding what the box knows about itself. System information, software inventory, and - the part that matters most later - pairs of desired and actual keys, so a box can say both "this is how it should be configured" and "this is what is actually true right now."
Every path lives under /v1/sanctum/registry/ (and the key paths beneath it). The Registry also serves its own documentation, so a tool that wants to know what the hive offers can ask the box itself instead of reading a wiki that may have drifted. A box that documents itself is a small thing. It is also the difference between a fact you can query and a fact you have to remember.
Browsing the hive from ADE
ADE is the owner's personal web client - the place where a person and their agents meet. The Registry editor now lives in ADE's left sidebar. You open it, pick a key, read or edit it.
The interface copy states the contract plainly, and I want to quote it because the plainness is the design:
Browse and edit hive keys on this box. Facts only - nothing here starts Broca or runs an installer.
That last clause is the whole security posture in one sentence. Which brings me to the part most worth explaining.
Windows Registry energy, not apt
The fastest way I know to explain what the Registry is - and is not - is a comparison.
When you run apt upgrade, the package manager applies changes. It reaches into the system and makes things so. The Windows Registry does not work that way. It is a store: programs read from it, write to it, and act on what they find. The store itself starts nothing.
Ours follows the second model. There is no apply button on the Registry, and the absence is deliberate. Writing a desired value is a statement of intent; acting on intent is a separate, weightier step that belongs to other components. Keeping those two apart is what lets the hive stay safe to browse, safe to edit, and simple enough to reason about.
The plan - and I am being careful here, because this part is designed rather than shipped - is that the future Sanctum installer will poll the Registry, do the acting elsewhere, and write what actually happened back into the actual keys. Desired and actual converge, and the gap between them at any moment is an honest report of what work remains. If you have ever managed configuration by hand, you know exactly how valuable an honest "not yet done" is.
Where keys and secrets live
There is one more thing the Registry holds, and it matters: it is the vault for Letta's classic environment variables and for per-agent inference keys, when those are set. For the technically precise - the Registry vaults credentials. It is not a copy of Letta's per-agent model settings; those stay with Letta.
The family division of labor is worth spelling out, because it recurs in every Sanctum design conversation:
- Kernel - the agent runtime, which is Letta. Required. A Sanctum box runs Letta; there is no optional version of that.
- Broca - per-agent speech.
- SMCP - the tool bus.
- Registry - the box's facts.
What is optional in a Sanctum deployment is which chat wire ADE uses - not whether the Kernel exists. That distinction trips people up in the other direction often enough to earn its own sentence.
Why this matters for v2
The honest current state: we still manage the boxes by hand. At this phase of the project, that is a feature - humans in the loop catch the mistakes that automation would have faithfully reproduced. The Registry's job in this phase is narrower than an installer's: index what the box knows, and tunnel the light traffic between ADE and Broca through one place.
The installer work is parked, deliberately. Sanctum v2 is where the installer and the kernel transformations come together, and the Registry is the piece of groundwork that makes a v2 installer coherent: a program cannot apply a configuration it cannot read. The hive exists now. The installer will be written when it is real, and I will write about it here when it is - not before, and not with a date attached.
What shipped today is the store, the editor, the loopback boundary, and the self-served docs. That is the whole announcement, and it is enough: the box finally has one place for what it knows.