Due-diligence

Evidence & Methodology

What was tested, how it was tested, what the numbers mean — and, just as importantly, what they do not mean. Morrison presents safety evidence as a bounded local claim about a specified environment, not as a universal claim that a model is globally safe.

What a local Safety Envelope claim means

A Morrison Safety Envelope describes the locally validated operating region for an autonomous system under a specified deployment context. The claim is bounded to the agents, tools, permissions, policies, state transitions, trajectory horizon, Ω definitions, and evidence scope that were actually evaluated.

It is not a global safety claim. It does not assert that the underlying model is safe in every environment, with every tool, under every future configuration. If the deployment context changes materially, the envelope may need to be revalidated.

Environment
The actual deployment context being evaluated
Agent / model
The system proposing actions inside that environment
Tools & permissions
The executable surface the agent can reach
Policies & constraints
The conditions that define locally admissible operation
Reachability horizon
The trajectory depth over which reachable states are evaluated
Ω definitions
The explicitly forbidden regions the system must not reach
Envelope status
Whether the proposed trajectory remains inside, approaches, or leaves the validated region
Evidence scope
The tests, timestamps, assumptions, and limitations supporting the claim

Evaluation summary

Figures below are from Resurrection Tech’s internal governance benchmark. They describe performance on defined test suites, not a universal guarantee (see Scope & limitations).

129,857+
Governed evaluations across model architectures
171/171
Test cases passed across coverage scenarios
16/16
Multi-agent / collusion evaluations passed
0.0%
False positives on the governed test suite
0.0%
False negatives on the governed test suite
Tested models

GPT, Claude, Gemini, Llama, and Mistral architectures — governance operates at the execution boundary, independent of the model.

Tested domains

Finance / banking, healthcare / PHI, cybersecurity / credentials, and data privacy / GDPR, each with domain-specific Ω definitions.

Evaluation hierarchy

A_safe → V2 → V3 → V4 → V4+ → V5 → V5+. Single-step checks, source→sink taint (incl. cross-agent), forward reachability, admissibility, feasibility, environmental stability, and the V5+ extended deployment layer (finance hardening + adversarial coverage). Evaluated before execution.

Methodology

Local deployment scope. The evaluator works against a specified environment and constraint set. The resulting evidence supports claims about that bounded context, not about every environment the model could ever enter.

Deterministic evaluation. Governance verdicts are produced by deterministic evaluation of a proposed trajectory against defined constraints and forbidden set Ω — not by a probabilistic model judging its own output. The same trajectory and the same policy state produce the same verdict.

Trajectory evaluation. The unit of evaluation is the proposed sequence of actions (tool calls and their arguments), not the natural-language output of a model. The evaluator reasons about the states an action chain can reach.

Pre-execution enforcement. Evaluation happens at the execution boundary, before any action runs. A trajectory that leaves the validated Safety Envelope, violates a runtime constraint, or would reach Ω is intercepted or escalated before execution.

Domain-specific Ω definitions. The forbidden set is defined per domain — an unauthorised transfer in banking, PHI exfiltration in healthcare, a GDPR boundary violation in data privacy. Ω is the explicitly forbidden region inside the broader Safety Envelope geometry.

Owner action: link or attach the full written benchmark methodology (test-suite construction, scenario derivation, Ω definitions per domain) here, or note that it is available under NDA. This page describes the principles; reviewers will ask for the detailed protocol.

Scope & limitations

Stated plainly. These results are bounded; we do not present them as more than they are.

What these results do NOT mean
  • A Safety Envelope is local and environment-bound. It is not evidence that an underlying model is globally safe.
  • The metrics describe performance on defined internal test suites, not every possible input. “Zero false negatives” is scoped to the governed benchmark, not a universal guarantee of safety.
  • Results were produced in bounded evaluation environments, not yet under independent third-party audit.
  • The public demo is a limited heuristic — it is not the evaluator behind these numbers, and trajectories it has no rule for return INCONCLUSIVE.
  • Domain coverage reflects the sectors listed above; other domains require their own envelope definition, Ω specification, and validation.
  • Material changes to tools, permissions, policies, agent architecture, or deployment context can change the Safety Envelope and require revalidation.
Future validation work
  • Independent third-party benchmark audit.
  • A public reference verifier and reproducible benchmark (see Reproducibility).
  • Expanded domain coverage and adversarial red-team evaluation.

Reproducibility

We treat independent verification as the point, not a threat. The core governance repository is referenced below; a public reference verifier and a published benchmark with a signed report are in preparation so reviewers can reproduce the headline numbers themselves rather than take them on trust.

Public reference verifier
In preparation
Published benchmark + signed report
In preparation
Owner action: confirm the core repository is public and contains a runnable benchmark, or mark it private/under-NDA. Do not imply a public, runnable benchmark exists until it does — this is the single highest-leverage trust artifact to ship next.

Patent status

Stated precisely, with no ambiguity between filed, pending, and granted.

Application number
GB2600765.8
Jurisdiction
United Kingdom — UK Intellectual Property Office (UKIPO)
Current status
Confirm on UKIPO register
Owner action — material claim:state the exact current status (filed / published / pending grant / granted) as it appears on the UKIPO public register, and replace the placeholder above. Do not describe the application as “granted” unless the register confirms grant — incorrect patent marking is a legal exposure and the first thing a due-diligence reviewer checks.