How Octos actually works.
Five ideas carry the whole system: services, the one door, state as a log, frames, and surfaces. Learn these and the rest of the docs falls into place.
Services
Everything in Octos is a service — a small owned unit with a boundary and a job. Its body is a parameter: the same shape whether the work is done by code, a language model, a lookup, or a human. A methodology, a game, even one person's node is the same primitive at a different scale.
You compose services into a vertical instead of wiring bespoke call-chains. The stack the engine assembles for a content session differs from a dev session; the core is shared.
The one door
Nothing writes to your graph except through a single door — and at that door the write is authorized, recorded, and stamped with who did it. A check is a rule that gates the effect: it can block, flag, or pause for review. Authorization is just another check, so "who's allowed" and "is this correct" run the same way.
Admits and denials are both durable — you can see what was refused, not only what passed. And sensitive moves — signing, verdicts, commitments — aren't merely denied to an autonomous caller; they're absent. A model can't promote itself.
State is the log
The truth isn't a set of files you overwrite — it's an append-only history of what happened. Current state is computed from that history, never edited in place. You get an honest audit trail for free, the ability to fork and compare, and memory that stays correct as it changes.
Retrieval finds text; it doesn't keep it correct — and models don't reliably use long context anyway. So Octos governs memory as living structure: facts carry provenance, contradictions surface, staleness gets flagged. The graph remembers; the log keeps it true.
Frames
Work happens inside a frame — a working set with a goal, constraints, and a budget. A quick task is a small frame; a whole session is a long one; they nest.
Relevance is a predicate, not a folder — "today and this project," not a place you filed something. The same thing can belong to many frames at once, and attention narrows by intersecting them.
Surfaces
A composition is written once and rendered to wherever the work happens — a chat thread, a CLI, or a full dashboard. The surface changes; the governed core underneath does not.
Same services, same door, same memory back every surface. You don't rebuild governance per channel — you point it at a new one.