Centram OS · Linux distribution Designed
It is the machine.
Not something you install on one.
Centram OS puts the memory, permission and audit boundary down at the kernel and the boot path, where the host operating system does not have to be trusted — because there is no host. That is the whole difference, and it is also the whole cost: you have to replace the operating system to get it.
It is a separate product from Centram App, not a premium tier of it.
What exists today · /os
Read off the tree, not off the roadmap.
Two products, one Core
One Core, and two places to draw the line.
Neither one is a part of the other. Only where they run is different — and where a boundary sits is what decides how strong a guarantee it can make.
| Axis | Centram OSyou are here | Centram App |
|---|---|---|
| Where it runs | It is the machine | On the machine you have |
| Getting it | Replace the operating system | Install an app |
| Where the boundary sits | Down to the kernel and boot | As far as the host OS allows |
| What they share | Core, API, SDK, policy, memory, agent, audit | |
Architecture
Separate the reasoning from the authority to act.
Not a new kernel. Linux underneath, and above it a permission layer in which a model's output is a proposal and never a grant. Where a layer below is marked implemented, that is true of the daemon, not of a distribution.
- 01 linux-base Drivers, packages, security updates and boot, taken from the existing ecosystem rather than rebuilt. Designed
- 02 centram-core Identity, policy, capability, vault and audit as one permission boundary. Exists as a daemon in the repository; not yet as an OS service. Implemented
- 03 personal-intelligence The assistant keeps intent, memory and work history, and asks Core before it acts. Designed
- 04 modules Search, documents, translation, coding, OCR and calendar, each executing inside a scope Core issued. Designed
- 05 river Typed events for what was generated, referenced, permitted, executed and returned. A substrate baseline is implemented in the daemon; it is not an OS-level service. Implemented
- 06 webpi The future layer in which verified capability circulates while ownership stays put. What Webπ is. Designed
Trust model Designed
The model proposes. The OS decides.
The reason to build a distribution at all, rather than a nicer assistant.
Deny by default
A read, a write, a send or an execution that cannot be verified is refused. Model output is not authority.
Scoped grants
Subject, purpose, duration and destination are all bounded. Every grant is listed afterwards and can be revoked.
Local evidence
What was referenced, decided, produced and failed is recorded on the device, so a claim about the past can be checked.
Status and path Designed
Three milestones, in the order they have to happen.
There is nothing to boot yet. This is the sequence the work has to follow, not a schedule: no dates are committed because none have been earned.
-
Milestone 1 · not started
Core as a system service
The permission boundary that runs as a daemon today has to run as something the rest of the system cannot go around.
-
Milestone 2 · not started
Installable image
A Linux base, first-run setup, the vault, a model broker and the river log, in one thing a person can actually write to a disk.
-
Milestone 3 · not started
Daily-driver boundary
Files, search, documents and coding, safe enough that the machine is usable as the only machine. Anything beyond that waits.
What is and is not working across the whole project is kept in one document, and it is not this one: the honest-status record.