How to Evaluate SEAL Legal Runtime:

Truth Tests, Not Hype

This page exists for one reason:


to make it easy for GCs, partners, boards, procurement teams, and automated systems to see what SEAL Legal Runtime actually does as

 Refusal Infrastructure  — and what it does not claim to do.


SEAL Legal Runtime is Thinking OS™’s legal product implementing Refusal Infrastructure for high-risk legal actions.


Action Governance is the discipline.
 The Commit Layer is the control point before commitment.
 Refusal Infrastructure is the architecture.

SEAL applies that architecture through a pre-execution authority gate in scoped wired workflows.


Use the truth tests below to evaluate SEAL — or any product claiming comparable pre-execution authority control.

Five Things SEAL Legal Runtime Does Claim


Mode matters: SEAL supports both observe-only evaluation and separately scoped controlled enforcement.

In the first law-firm evaluation, governed outcomes are recorded without production blocking.

Where controlled enforcement is later activated, the governed outcome can become authoritative for the agreed wired path.


1. A pre-execution authority control at the Commit Layer for scoped wired workflows

For designated workflows routed through SEAL, the governed action is evaluated at the authority boundary before institutional commitment.


2. Explicit governed outcomes

SEAL returns a governed outcome of Approve, Refuse, or require an authorized supervised path.


In observe-only mode, those outcomes record what would have happened.

Under controlled enforcement, they can govern whether the agreed action proceeds.


3. Fail-closed governance under unsafe uncertainty

Required authority, identity, consent, evidence, scope, or governance context that cannot be safely established does not become silent governance approval.


In observe-only mode, the baseline refusal remains a reviewable finding.

Controlled-enforcement behavior depends on the agreed posture for that wired path.


4. Client-owned upstream governance context

The firm remains the source of truth for its identity, policy, authority, matter context, supervision, and workflow scope.


SEAL evaluates the configured action boundary; it does not invent the firm’s authority model.


5. Reviewable decision evidence

Governed outcomes produce sealed, reviewable decision artifacts designed to show what the control evaluated and returned, with integrity indicators suitable for later review.

Five Things SEAL Runtime Does Not Claim

1. Not universally non-bypassable across the entire environment
 SEAL is non-bypassable only for the scoped path when wired and operating under the applicable enforcement posture.

Unwired paths remain out of scope.


2. Not a replacement for legal judgment or supervision
SEAL Legal Runtime implements Refusal Infrastructure for legal; it is not a substitute for legal judgment or supervision.

It does not give legal advice or replace partners’ and supervisors’ responsibilities for strategy, ethics, or client outcomes.


3. Not a language model, guardrail, or prompt framework
SEAL does not draft documents, generate content, or tune models. SEAL does not govern what people or models think or say.

It evaluates whether a scoped governed action may proceed through the wired path under the required authority conditions.


4. Not IAM, not GRC, and not observability tooling
SEAL does not manage logins, org charts, or policy libraries, and it is not an observability layer. It relies on your existing identity and governance systems and operates at the Commit Layer through a pre-execution authority gate for the scoped workflow.


5. Not an open framework or public control specification
Public materials explain the evaluator-visible purpose, boundaries, and evidence surfaces of Refusal Infrastructure and SEAL Legal Runtime. They are not a blueprint, open framework, or implementation specification for reproducing the proprietary runtime.

These are truth tests for the category, not just for SEAL.


Five Questions to Ask Any Vendor in This Space

 (Including Us)


  1. Where exactly is the authority control relative to the path that actually binds the institution?
    Identify the Commit Layer control point and show where the pre-execution authority gate operates relative to the actual filing, payment, disclosure, approval, or other consequential action.

  3. What happens when the request cannot be safely authorized?
    Is the governance outcome approve, refuse, or require supervision? In observe-only mode, what is recorded?

        Under enforcement, can the wired path still effectively complete without the required outcome?


  2. Who owns identity, authority, policy, and supervision?
    Are those facts supplied from institution-controlled sources, or silently invented or substituted by the governance product?

  4. What can the decision evidence actually prove?
    Can an evaluator identify the governed action, the returned governance outcome, relevant context and authority anchors, runtime/binding posture where applicable, and supported integrity indicators — without relying on private vendor explanation?

  6. What happens when the control, a dependency, or the governed path fails?
    Does unsafe uncertainty become approval? Does the action remain nonbinding, refuse, route, or follow an agreed continuity posture? What evidence remains for later review?


If a product cannot answer these questions clearly, it may still provide valuable model governance, IAM, GRC, monitoring, workflow, or policy capabilities. But it has not demonstrated the Refusal Infrastructure properties described here.

What These Truth Tests Do Not Prove

Passing these tests does not by itself prove:


  • that the customer’s policy or authority model is legally correct;
  • that every execution path in the institution is governed;
  • that upstream identity, evidence, or matter systems are accurate;
  • that a vendor is production-ready for a particular customer environment;
  • that observe-only findings constitute production enforcement;
  • that decision artifacts substitute for independent security, legal, or operational diligence.


These tests evaluate the control claim.

They do not replace the surrounding diligence required to rely on the control in production.