Capability is not
the same as permission.

A system can be technically able to take an action without being authorised to take it. KoLo keeps those two facts apart, so operational control stays explicit rather than emergent.

Autonomy without authority is not intelligence we are willing to deploy.


01 — THE AUTHORITY PRINCIPLE

Most AI incidents are permission failures, not capability failures.

When an automated system causes institutional harm, the cause is rarely that it could not do the task. It is that nobody had decided, in advance and in writing, what it was allowed to do — so capability quietly became permission by default. The gap is filled at runtime by whatever the system happens to be able to reach.

Treating the two as separate facts costs something: every consequential action has to be classified before it can be taken. That cost is the point. An institution that cannot say who authorised an action cannot be said to be in control of it.

Capability is discovered. Permission is granted. A system that confuses them will eventually do something nobody chose.

02 — WHO MAY DO WHAT

Four actors. Four verbs.

Every consequential action in a KoLo deployment resolves to a cell in this table. Nothing acts outside it, and nothing approves its own action.

The KoLo governance core — permission boundaries, human review gates, append-only audit and recovery/rollback around the runtime event flow.
What each actor may observe, recommend, act on and approve.
ObserveRecommendActApprove
Autonomic systemDefinedLimitedBounded Not permitted
KoLo agentDefinedDefinedPolicy-bound Not permitted
Human operatorYesYesRole-basedDefined
Accountable authorityYesYesYesFinal

03 — BOUNDED AUTONOMY

What defines the edge of an envelope.

“Bounded” is meaningless unless the bounds are named. Five dimensions define what an autonomous component may do — and each is declared before deployment rather than discovered during an incident.

ScopeThe systems, data and actions an agent may touch at all — declared in advance, not inferred at runtime.
ReversibilityWhether an action can be undone. Irreversible actions never sit inside an autonomous envelope.
Blast radiusThe maximum consequence of the action being wrong, evaluated before the action is permitted.
Rate and repetitionHow often an action may be taken before it stops being routine and becomes a pattern requiring review.
ExpiryAuthority is granted for a period. Permissions that never expire become permissions nobody remembers granting.

04 — EVIDENCE AND AUDIT

An action without a record did not happen accountably.

Governance that cannot be inspected afterwards is a claim, not a control. Five properties turn activity into evidence.

Append-only recordActions are written to a log that is added to, never edited. A record that can be revised is not evidence.
AttributionEvery entry names the actor — which system, which agent, which person, under which role.
JustificationThe observation or policy that prompted the action, captured with the action rather than reconstructed later.
OutcomeWhat actually resulted, recorded separately from what was intended. Firing is not landing.
RetentionHow long the record is kept, and under what authority it may be read.

The fourth is the one most systems get wrong. Recording that a job ran is not the same as recording that it achieved anything — and a dashboard built on the first will report green through a total failure of the second.

05 — ESCALATION

The conditions that return control to a person.

Confidence is not authorityA system being sure is not a reason to let it act. Escalation is triggered by consequence, not certainty.
NoveltyConditions outside the envelope the system was authorised for return control to a person by default.
ConflictWhere policy and operational pressure disagree, the disagreement is surfaced rather than silently resolved.
DegradationWhen the system knows it is operating on reduced capability, its authority narrows rather than persisting unchanged.
SilenceA component that stops reporting is escalated. Absence of alarm is not evidence of safety.

06 — SOVEREIGNTY

Seven layers, not one server.

Sovereignty is claimed too often on the strength of where a model is hosted. Hosting is one layer of seven.

01 · DataWhere institutional data resides, how it is reached and under whose authority it is processed.
02 · ModelsSpecialist, institutional, local or frontier — chosen by operational and policy requirement.
03 · MemoryAuthorised context preserved without surrendering continuity to an external session.
04 · InfrastructurePrivate, local, edge, hybrid or nationally controlled compute.
05 · PermissionsWho may read, invoke, approve and use sensitive capability.
06 · GovernanceAudit, policy, escalation and human authority inside the intelligence layer.
07 · KnowledgeThe institution’s own rules, legislation, procedure, terminology and prior decisions.

07 — GOVERNANCE ACROSS DEPLOYMENTS

Authority does not widen with capability.

A deployment that escalates from a local model to a frontier one gains capability. It does not thereby gain permission — the envelope is a property of the institution’s policy, not of the model answering.

EdgeLocal reflex action inside a narrow envelope; anything consequential waits for connectivity and a person.
InstitutionalFull policy engine under the organisation’s own control, with its own roles and approval chains.
HybridAuthority does not travel upward with capability — escalating to a larger model does not widen what may be done.
SovereignGovernance constraints follow the jurisdiction, including where evidence may be stored and who may read it.

08 — TRUST IS OPERATIONAL

Trust has to be inspectable.

Institutional trust cannot rest on a system appearing intelligent. It rests on whether the organisation can see what happened, why, under whose authority and on what evidence.

PermissionsWho may access, invoke or approve.
ProvenanceWhere the information and the evidence came from.
AuditabilityWhat the system did, and when.
EscalationThe conditions under which control returns to people.
RecoveryHow the system restores safe operation.

09 — STATUS AND CLAIM BOUNDARY

What this page does not claim.

Not a compliance certificationThis page describes an architecture. It is not an audit result, and it does not assert conformance to any standard.
Not a legal frameworkGovernance here is operational control. It does not substitute for the institution’s own legal and regulatory obligations.
Not externally assessedNo independent party has assessed this authority model. Where that changes, it will be stated with the assessor named.

The goal is not unrestricted autonomy. It is useful autonomy, operating inside visible authority, evidence and human responsibility.