Design philosophy: central source, derived state

Design philosophy of the AI OS: central source of truth, derived state, applied across the four components.

The principle this page describes is held in the charter, the system's canonical layer. This page's job is to show how it plays out across the four components, not to restate it.

The invariant

Each fact in the system lives in exactly one place. Every other surface that asserts the fact is a derived view of that canonical home.

The charter entry says it like this:

Treat every "manifest of truth" the project depends on as a single canonical source. Every public surface that asserts that fact is a derived view that should re-derive itself from the canonical at build time, or fail loudly when it drifts.

The contrapositive is the failure mode: when a fact lives in two places, drift is the steady state. The two copies disagree within weeks. Whichever you read first is the one you believe. The system silently lies.

What "derived view" means in practice

A derived view is anything that summarises, rolls up, indexes, restates, or rephrases content owned elsewhere:

A README that lists "the skills we ship": derived from each skill's own definition file
A slide deck explaining a programme: derived from an archive note
An HTML page on async-digital.com: derived from the shared stylesheet and canonical brand constants
An index inside an archive folder: derived from each note's own description
A documentation-coverage report: derived from each artefact's own declaration

Derived views are not bad. The archive has dozens of them. They are useful because they aggregate. They are dangerous only when they become the source of truth. They tend to, because they're the convenient surface to edit.

The rule, then: hand-edit the canonical; regenerate the derived view. Never the reverse.

How this applies to each component

Charter

The charter is canonical, by definition. It is the highest-priority surface in the system; everything else derives from it or pretends to.

The corollary: changes to discipline land in the charter first. Memory entries (derived views of the charter for fast lookup) update afterward, often as pointers that link to the charter prose rather than copying it.

A second corollary: a memory entry that disagrees with the charter means the memory is stale. Trust the charter.

Executive

The executive implements the charter. Each hook, agent, and skill cites the charter entry it enforces.

The executive should not contain doctrine; it contains executable enforcement of doctrine. If a hook starts to encode a rule that isn't in the charter, the rule lands in the charter first. Otherwise the hook is the source of truth and the charter drifts behind.

A recent example: the contracts for skill concurrency and documentation coverage were ratified in the charter before the hooks that enforce them were written. The contract is canonical; the hooks are derived enforcement.

MCP server

The MCP server is the API onto the archive. It does not store or assert anything beyond what the archive contains; queries return live state.

When the server returns a summary, that summary is a derived view of the underlying notes: useful for the calling agent's prompt, but not authoritative. If you find yourself relying on the summary as truth, you've hit the failure mode; read the underlying notes.

Worked failure mode: drift across two copies

A drift scenario the system has actually hit, multiple times:

A rule lands in the charter (say, "never edit on main; branch off").
The rule gets saved as a memory entry so it loads on relevant keywords.
Months later, the charter entry is refined.
The memory entry isn't updated. Now memory and charter disagree.
The memory hits the agent's context first (it's keyword-loaded). The agent follows the stale memory. The refinement is bypassed.

The fix: when a load-bearing rule changes, audit the memory entries that point at it. The fix that prevents recurrence: write memory entries as pointers to the charter, not copies of it. The entry says where the live rule lives; the rule itself stays in one place and updates land there.

Worked success mode: declarations as canonical, enforcement as derived

The skill-concurrency contract is a recent example of getting this right from the start:

The list of skills that mutate the archive is not hardcoded anywhere.
Each such skill declares the fact in its own definition.
The lock that serialises them reads each skill's declaration at runtime and acts on it.
Adding a new skill of this kind is a one-line edit on that skill; nothing else changes.

The set of protected skills is derived from the declarations on the skills themselves. There is no central registry to maintain. There is no place to forget to update.

The same pattern repeats for documentation coverage: the audit reads each artefact's own declaration rather than a hand-maintained list.

Where this principle hurts

Three places the principle costs more than it saves, and where deliberate violations live:

Memory entries duplicate small charter snippets. A pointer entry costs an extra hop to load the charter; some entries copy the rule inline anyway. Audits catch drift periodically.
Auto-load rules are centralised. Each skill could declare its own load triggers; today they live in one central file. The set is stable enough that the centralisation cost is low.
Synthesis notes in the archive. Programme outlines roll up ticket bodies. The synthesis is the convenient surface; the tickets are the canonical home. The rule is enforced socially.

These violations are conscious. They are not the same as drift. They are documented deviations from the principle, accepted for cost reasons.

Where to read next

Operating philosophy: the postures the executive encodes
Methodology: how docs and derived views are produced and kept fresh

Last verified: 2026-06-12