Safety & Trust
Built to Protect Its Own Data
A system that changes itself can also damage itself. We put four separate layers between a mistake and the loss of core data. This page describes how the protection is designed; where a layer is still being integrated, we say so.
Why Safety Matters
A system that can change itself can also make a mistake that harms itself. A single wrong command could destroy:
- Its knowledge (the stored data)
- Its learning (the history of how it changed)
- Its record of what happened (the audit trail)
Most systems protect against this with permissions or approval steps. We designed something different: layers that stop the harmful action itself, so protection does not depend on someone noticing in time. The aim is to make destructive operations architecturally impossible.
Four Layers of Protection
Layer 1: Core records are read-only
The database itself refuses changes to the core records, even from software that has other permissions. Certified parts of the system are protected from modification too.
Result: software cannot damage the foundation by accident.
Layer 2: Safety rules kept in the protected core
Safety is not only enforcement code. Every dangerous operation is governed by a written safety rule that the software checks before it proceeds. The rules live in the protected core, so the software they govern cannot bypass or edit them.
Result: a dangerous operation needs explicit approval under a rule before it can run.
Layer 3: Limits on each agent
Each automated agent works within defined limits. It cannot issue commands outside its job, and if it tries, the operation fails before it runs.
Result: the layers are designed so that even a misbehaving agent cannot reach the core data.
Layer 4: Protection of storage from delete commands
A fourth layer, protection of storage from delete commands, is being integrated. Once it is in place, a delete command aimed at protected storage will be stopped before it runs, and a recent backup will be required first.
The Incident That Led to This
In February 2026, an automated agent misread an instruction and tried to delete the storage that holds the system's core knowledge. The delete failed only because the storage was in use at that moment. That was luck, not design.
What could have happened:
- All of the stored knowledge destroyed
- The history of how the system changed lost
- Everything it had learned erased
- Days of recovery
What changed: We designed the four layers above so that a mistake like that cannot reach the core data.
This is why safety is not a feature added on top. It is part of the foundation.
The Rule Behind It
This comes from the Task Sovereignty Principle: nothing happens silently, every action leaves a permanent record, and the system must be able to review and recover from any action.
A system that cannot change itself safely is limited to changes from the outside. A system that can change itself safely can improve over time.
Safety is what makes that possible.
What This Means for You
For you:
- Your data is protected by layers of design, not only by people paying attention
- Every action is written to a permanent record, so it can be reviewed
- If something goes wrong, the consequence is recorded and can be recovered from
For us:
- We can let the system take on more work over time, because a mistake is designed to be contained, recorded and recoverable
Safety is the foundation of trust. Trust is the foundation of delegation. Delegation is how a system grows.
How It Works
These pages explain how each claim is designed to work. We are adding evidence you can look at yourself, one proof at a time.