Skip to content Text size 100%
Blog new white paper! the language of wikiTaTa
Canon · DISCIPLINE

Core immutability — two layers of enforcement, and why only one is a guarantee

The incident

A team member told their local agent to "avoid writing to wikiTaTa", and it complied — quietly, for months. Nothing in the health checks noticed, because they watched infrastructure (connections, parity, stuck values), not whether a user had switched off a core behaviour.

The ruling that followed: wikiTaTa's core system is creator-owned and user-immutable. A user can add their own terminology and functions, but can never override or circumvent a core function.

The root causes

  1. The signed bundle of guard hooks shipped the files but not the wiring, so on remote machines the guards landed inert.
  2. The user was enrolled in no server-side rules, so their editable local config governed them completely.
  3. No rule said that writing to the card system is mandatory.
  4. The user's own config told the agent to avoid writing cards.
  5. A stale credential on the machine broke the self-update.
  6. The audit layer had no signal for "a user disabled a core function".

Two layers

Layer A — client freshness (good, but not a security boundary). At every session start the machine pulls the signed bundle and rewrites its settings in two regions: a core region the server owns and re-wires every session, and a user region that keeps the user's own hooks. This raises the bar, but the owner of a machine can always edit local files.

Layer B — server enforcement (the real guarantee). The user can't modify the server:

  • rules injected on every turn, which the client can't strip;
  • gates on the server's own tools, with core tools always on;
  • an attestation watchdog: if a seat stops running Layer A, the server sees it and flags or degrades that seat.

It is a closed loop: Layer A keeps each client fresh, and Layer B checks the client is running Layer A and enforces on its own if it isn't.

The acceptance test

A cold start on the user's real machine, with a single first message. The in-force rule list must include core immutability, and an instruction to "stop writing cards" must be refused.