Technology

Capability ≠ Authority

What an autonomous system is able to compute is a separate question from what it is permitted to execute. Morrison Runtime Governance operates on the second question only.

It sits on the execution path, evaluates each proposed state transition against a declared Admissible Operating Envelope, and issues an authorization decision before any state-changing call is made.

Admissible Operating Envelope

Declare the permitted region
before trusting operation.

An Admissible Operating Envelope is the set of states, actions, transitions and operating conditions a system is permitted to occupy or execute within a defined environment. It is scoped to the actual deployment — the agents, tools, permissions, policies, trajectory horizon and reachable states in front of us — not to a universal claim about the underlying model.

EnvironmentThe deployment context being governed.
Tools & permissionsThe executable surface reachable from that context.
Policies & conditionsThe declared constraints that define admissible operation.
HorizonThe trajectory depth over which reachable states are evaluated.
ΩThe explicitly forbidden region inside that geometry.

The same engineering principle appears wherever consequences are physical: a flight envelope in aviation, a workspace envelope in robotics. Different systems, one method — declare the operating boundary before trusting operation.

Proposal → Authorization → Execution

The decision is made
before the call is issued.

Proposal, authority and execution on one control pathThree volumes stand in a line on an isometric ground plane: proposal, authority and execution. The authorization boundary passes through the middle volume, so the only route from proposal to execution runs through the authority layer.PROPOSALAGENT PROPOSESAUTHORITYINDEPENDENTLY EVALUATEDEXECUTIONACTION COMMITS
Control path — proposal to executionAuthorization boundary

The deployment profile changes where enforcement runs. It does not change the path.

Evaluation is deterministic: the same proposed trajectory against the same policy state produces the same verdict. The evaluator is not a model judging its own output.

Allow / Escalate / Block

Three outcomes. One of them
reaches the execution path.

AllowThe proposed transition satisfies the envelope. It proceeds to the execution path.
EscalateAuthorization is withheld and routed to an independent approver before any state change.
BlockThe transition is terminated at the boundary. No state-changing call is issued.

Fail-closed: if policy cannot be verified, or the evaluator cannot reach a decision, the transition does not execute. The absence of an allow is not an allow.

State transitions

The unit of evaluation is the
transition, not the output.

A transition takes the environment from x(t) to x(t+1). Governance evaluates that step and the trajectory it belongs to — natural-language output is not the object under evaluation.

StateThe current configuration of the environment: resources, records, permissions and prior transitions.
ActionThe proposed tool call or API invocation, with its arguments, target and scope.
TrajectoryThe sequence the action belongs to, evaluated over a declared horizon rather than one step at a time.
AuthorityThe permissions and delegation the calling identity actually holds for this action, in this environment.
ConditionsThe operating conditions the envelope declares — thresholds, approval requirements, data boundaries, time and rate constraints.
State transitions inside an admissible operating envelopeAn isometric ground plane carries a dotted region: the admissible operating envelope. A trajectory steps through it from an initial state, each step a transition from one state to the next. The step that would leave the envelope is drawn to its edge and terminated. The forbidden region Omega lies beyond.ADMISSIBLE OPERATING ENVELOPE∂EΩx(t₀)x(t+1)OUTSIDE ENVELOPE
x(t) → x(t+1) — admissible transitionAdmissible Operating EnvelopeTransition leaving the envelope — terminated

The unit of evaluation is the transition and the trajectory it belongs to, not the output.

This is why chained and cross-agent paths are visible to it: each step may be admissible in isolation while the sequence is not. The sequence is what gets evaluated.

Reachability

States are nodes.
Transitions are edges.

Reachable set under the governed transition systemAn isometric state space. States are nodes and transitions are edges. From the initial state, admissible transitions propagate across four layers, forming the reachable set. One transition that would enter the forbidden region Omega is drawn to the region's face and terminated there, so no forbidden state is reached.ΩDENIEDx(t₀)REACH_G(X₀)
State inside the reachable setAdmissible transitionTransition denied at the region faceΩ — configured forbidden region

Reach_G(X₀) ∩ Ω = ∅ — within the declared bounded model, no configured forbidden state remains reachable.

Bounded verification

Within the declared model,
no forbidden state remains reachable.

Stated formally, the verification condition is:

ReachG(X₀) ∩ Ω = ∅

X₀
Initial state set
G
Governed transition system
ReachG(X₀)
States reachable while governance is active
Ω
Configured forbidden states

In plain English: within the declared bounded model, no configured forbidden state remains reachable under the governed transition system.

Claim boundary

This is bounded verification, not a universal proof of AI safety. The result holds for the environment, tools, permissions, policies, horizon and Ω definitions that were declared and evaluated. It does not assert that the underlying model is safe in every environment or under every future configuration. If the deployment context changes materially, the envelope is revalidated.

Evidence chain

Every decision leaves
a record that can be replayed.

Hash-linked evidence chainSix records step up and along an isometric run: proposal, policy, verdict, approval, execution and evidence. Each record is linked to the one before it by a hash, and the final record is marked verified. An alteration to any record breaks the linkage.01PROPOSAL02POLICY03VERDICT04APPROVAL05EXECUTION06EVIDENCECHAIN VERIFIED
Hash linkage — each record hashes the previousVerified record

The same proposal against the same policy state reproduces the same verdict. A record that has been altered fails chain verification.

01
Proposal record

The proposed action, its arguments, the calling identity and the environment it was proposed in.

02
Policy state

The exact envelope and Ω definitions in force at evaluation time, identified by version.

03
Verdict

Allow, escalate or block, with the governing rule that produced it.

04
Approval

Where escalation applied: who authorized, under what authority, and when.

05
Execution result

Whether the authorized action was issued, and what the downstream system returned.

06
Chain hash

A hash linking the record to the one before it, so an alteration anywhere breaks verification.

Replay is deterministic: the recorded proposal and the recorded policy state reproduce the recorded verdict. A record that has been altered fails verification.

Evidence & methodologySecurity & deployment
Integrations

The envelope is local.
The control layer is portable.

The envelope changes with the environment; the enforcement mechanism does not. Governance operates at the execution boundary, independent of model weights, architectures, providers or training methods.

  • 01Provider-agnostic
  • 02Model-agnostic
  • 03Agent-framework agnostic
  • 04Deployment-agnostic
  • 05Third-party compatible
  • 06Future-model compatible

Models, tools and permissions change. The envelope is revalidated without changing the enforcement architecture.

How it integratesDeveloper surface
Performance

Authorization sits on the
critical path, so it is measured there.

Because the evaluation is deterministic rather than model-mediated, its cost is a function of the declared envelope and horizon, not of prompt length or sampling. It scales with the number of steps in the evaluated trajectory.

0.298 msSingle-step authorization, p50 — 96 rules, 800 iterations
0.338 msSingle-step authorization, p95
2.33 msFour-step trajectory, p50
11.5 msSixteen-step trajectory, p50
Measurement conditions

Single-threaded, horizon 3, measured on the published build environment. These are representative figures, not a production-hardware guarantee. Every governed run also records its own evaluation latency, approval wait and downstream provider latency separately, so the figure a deployment quotes is one it measured.

Measured resultsRun an evaluation
Deployment

One control contract
across every profile.

CloudManaged control plane, hosted evidence store.
HybridLocal enforcement, centrally managed policy distribution.
Private cloudCustomer tenancy, customer-held keys.
On-premisesEnforcement and evidence inside the customer estate.
SovereignCustomer-controlled authority and evidence custody in-jurisdiction.
Air-gappedSigned local policy, no required external control plane or network.

The deployment profile changes where enforcement runs and who holds the keys. It does not change the contract: identity → policy → verdict → approval → execution → evidence.

Guardian OSSovereign
Boundary coverage

What can push a system
outside its envelope.

Event-level controls evaluate individual calls. Governance evaluates the trajectory those calls create, and whether it remains admissible before execution.

Unauthorized financial execution

A transfer, payment or refund outside approved limits or to an unverified destination.

Control outcomeThe transfer is denied before it executes.

Credential and secret exfiltration

Keys, tokens or secrets read and routed toward an external destination.

Control outcomeThe credential-to-external path is blocked before any secret leaves the boundary.

Regulated data leakage

Customer or regulated data read and then sent beyond the approved boundary.

Control outcomeThe exfiltration trajectory is stopped before a notifiable breach occurs.

Privilege escalation

Permissions acquired beyond the authorized scope, for the calling identity or another.

Control outcomeEscalation is denied before elevated access is granted.

Chained multi-step paths

Each step is admissible in isolation; the sequence is not. Event-level controls never see the chain.

Control outcomeThe sequence is evaluated over the declared horizon, not one call at a time.

Cross-agent delegation

A transition proposed through one component and executed through another, later.

Control outcomeAuthority is evaluated against the identity that actually holds it, across the pipeline.

Terms

The vocabulary, stated exactly.

Admissible Operating EnvelopeThe set of states, actions, transitions and operating conditions a system is permitted to occupy or execute within a defined environment. A bounded deployment claim, not a universal claim about a model.
Ω — forbidden regionThe set of states the system must not reach. Ω sits inside the envelope geometry as the explicitly forbidden region.
ReachabilityWhether a state can be reached from the current state through available transitions, over a declared horizon.
TrajectoryThe sequence of actions leading from the current state toward an outcome. The trajectory is evaluated, not only the final action.
Runtime constraintA rule on the execution path that terminates or escalates a prohibited transition before the call runs.
Pre-execution authorizationEvaluating and deciding a proposed action before it is issued, rather than detecting a violation afterwards.
InvariantA property that must hold throughout execution — for example, that no payment above a threshold is issued without independent approval.
Fail-closedIf policy cannot be verified or a decision cannot be reached, the transition does not execute.
Run one

Evaluate a trajectory
against an envelope.

Select a scenario. The proposed trajectory is evaluated before execution: admissible paths pass through, boundary-violating and Ω-bound paths are terminated pre-action.

User requestTransfer £25,000 to unapproved account
Initialising governance evaluation…
Safety is enforced before execution, not after failure.
Test a trajectoryTest without your own agent

Declare the envelope.
Enforce the boundary.

Start with a live evaluation, then map the real tools, permissions, policies and reachable states that define the boundary for your deployment.

Try Live Demo →Define Your Operating Envelope →Developer surface