Framework
ENGRAM
A governance loop for artificial intelligence, written from real deployments rather than principles. Seven steps, one register, and a single rule that decides how much authority any system holds.
Nothing starts above L1 and nothing rises except on evidence.
Why a loop, not a policy
Most AI policies describe intentions. They are written once, signed, and then overtaken by what teams actually build.
ENGRAM is operational. Each use of AI moves through the same seven steps, keeps a record, and is reviewed on a date that is already in the diary.
The result is a governed estate you can describe to a board, an auditor or a customer without preparing anything special.
The seven steps
Register to promote
00
Register
Every AI capability is named, owned and recorded before it runs.
Nothing enters the estate anonymously. Each use case gets an entry: what it does, which business process it touches, who owns it, which model and vendor sit behind it, and what happens if it stops working.
The register is the single list a board can be shown. If a use is not on it, it is not sanctioned.
What it produces
- Register entry with a named accountable owner
- Model, vendor and data sources declared
- Initial risk note and business purpose
The question it answers
Who is accountable, and what would we tell a regulator this does?
01
Level
A trust level, L1 to L5, sets how much the system is allowed to do. It is never assumed.
Every registered use is placed on a trust ladder from L1 to L5. The level describes the balance of authority between the person and the system, not the sophistication of the model.
New uses start at L1. Levels are earned later, in the promotion review, on evidence, never assigned because a pilot felt convincing.
What it produces
- Assigned trust level with written rationale
- Required human control at that level
- Conditions that would force a downgrade
The question it answers
If this is wrong, who catches it before it reaches a customer?
02
Scope
An allow-list of the exact systems, data and actions permitted.
Scope is the boundary: which tasks are in, which are explicitly out, which data may be used, where it may travel, how long it is kept, and which actions the system may never take without a person.
Written scope is what makes drift visible. When usage grows beyond the boundary, that is a change to govern, not an accident to discover later.
What it produces
- In-scope and out-of-scope task list
- Data classes, retention and residency
- Prohibited actions and escalation paths
The question it answers
What is this explicitly not allowed to do?
03
Contract
Executable acceptance criteria, agreed before any build.
The acceptance contract states what good looks like in measurable terms: accuracy or quality thresholds, latency, cost per task, safety and bias checks, and the fallback when the system fails.
It is agreed by the owner and the reviewer up front. This is the Assay practice: define the test before you see the result, so success cannot be redefined after the fact.
What it produces
- Measurable thresholds for quality, cost and latency
- Safety, privacy and bias test set
- Defined fallback and rollback plan
The question it answers
What result would make us stop?
04
Score
A quality ledger, scored on reliability multiplied by utility.
Both reliability and utility are scored from 0 to 1. The capability must sustain a reliability × utility score of 0.75 or above across a rolling review window. Below the threshold for a single cycle and it drops a level, with no committee and no debate.
Once live, the use is measured against its own contract. Outcomes, exceptions, overrides, incidents and reviewer effort are logged in a ledger that no one can quietly reset.
The ledger turns opinion into evidence. It also shows the honest cost of a system: the human time still needed to keep it safe.
What it produces
- Ongoing scores against contract thresholds
- Rolling reliability × utility score with a 0.75 threshold
- Override, exception and incident log
- Human effort and cost per outcome
The question it answers
Is this still performing as promised this quarter?
05
Log
The decision is recorded, including the options that were rejected.
Every governance decision is written into a durable log: what was decided, by whom, on what date, on what evidence, and which alternatives were considered and turned down.
This is the step that makes the whole loop auditable. Without the rejected options, a record shows only what happened, never whether the judgement was sound.
What it produces
- Dated decision record with named decision-maker
- Evidence cited at the point of decision
- Rejected options and the reason for rejection
The question it answers
If we were asked in a year why we allowed this, could we answer from the record?
06
Promote
Promotion or demotion, on evidence only.
At a set cadence the owner brings the ledger to review. The only question is whether the evidence supports more autonomy, the same autonomy, or less.
Promotion is a deliberate act with a written decision. Retirement is a normal outcome, not a failure: uses that no longer earn their place are closed and removed from the register.
What it produces
- Written promote, hold, downgrade or retire decision
- Updated level and scope in the register
- Date of the next review
The question it answers
What evidence would justify giving this more authority?
Trust levels
L1 to L5
A level describes how much authority a system holds, and therefore how much human control is required around it.
Downgrades are automatic and require no approval. Upgrades require two consecutive qualifying review cycles.
- L1Sandboxed
- No production reach. Synthetic or copied data, and every output reviewed in full before any use.
- L2Assisted
- Reads production data and writes nothing. Every output is reviewed before it takes effect.
- L3Supervised
- Writes to a production system, with a named human approving each action before it commits.
- L4Delegated
- Writes within a bounded scope, with no per-action approval. Sampled review plus automatic rollback.
- L5Autonomous
- Runs unattended inside its scope. Humans are involved by exception only.
Bringing ENGRAM into an organisation
The framework is usually adopted in stages: register what already exists, level it honestly, then run the first promotion reviews with the people who will own them afterwards.