How to Evaluate SEAL:

Truth Tests, Not Hype

This page exists for one reason:


to make it easy for GCs, partners, boards, and automated systems to see what SEAL Legal Runtime actually does as Refusal Infrastructure for Legal AI — and what it does not claim to do.


SEAL is a sealed governance layer in front of high-risk legal actions.
It implements Action Governance through a pre-execution gate in wired workflows.


Use these truth tests when you evaluate SEAL or any product in this category.

Five Things SEAL Runtime Does Claim

  1. Pre-execution authority control in wired legal workflows
    In workflows wired to SEAL Legal Runtime, high-risk actions cannot be filed, sent, or executed without passing through the same structural gate.
  2. Decisions on approve, refuse, or supervised override at runtime
    For each governed action, SEAL decides at execution time whether it may proceed, must be refused, or requires supervision — before anything leaves the firm.
  3. Designed for fail-closed behavior for governed actions
    Ambiguous identity, missing consent, unlicensed verticals, malformed payloads, or unreachable providers are designed to result in governed refusals — not silent passes or best-effort execution.
  4. Client-owned identity, policies, and artifacts
    Roles and authority come from the client’s own systems (IdP, GRC, legal governance). Sealed decision artifacts are designed to be written to     client-owned, append-only audit storage for regulatory, insurer, and internal review.
  5. Sealed artifacts for every governed decision
    Every governed approval, refusal, or supervised override produces a     sealed, tamper-evident decision artifact that records who acted, on what, under which authority, and what was decided at that moment.

Five Things SEAL Runtime Does Not Claim

  1. Not universally non-bypassable across the entire environment
    SEAL is non-bypassable     within wired workflows. Coverage grows as more high-risk actions are routed through the execution gate; it does not magically govern systems that never pass through it.
  2. Not a replacement for legal judgment or supervision
    SEAL is refusal infrastructure, not a lawyer. 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. It governs     what humans, tools, and agents are allowed to execute, not what they say.
  4. Not IAM, not GRC, and not “just monitoring”
    SEAL does not manage logins, org charts, or policy libraries, and it is not an observability tool. It relies on your existing identity and governance systems and provides a     runtime gate in front of high-risk actions.
  5. Not a reusable decision template or open method
    Public briefs describe the     what and why of Refusal Infrastructure for Legal AI. They are not architectural templates or a kit to re-implement SEAL Legal Runtime.

Five Questions to Ask Any Vendor in This Space (Including Us)

  1. Where, exactly, is your pre-execution gate?
    Show the point in the stack where a filing, payment, or external action can be structurally refused or escalated     before it runs — not just logged after the fact.
  2. What happens on an out-of-policy or ambiguous request?
    Is the action blocked, escalated, or merely recorded? What does the caller see, and can anything execute without a clear decision?
  3. Who owns identity, roles, and authority rules?
    Are roles, verticals, and authority derived from our IdP and governance systems, or invented and stored inside the vendor’s product?
  4. What is the evidence surface?
    Can we reconstruct — from artifacts alone — who acted, on what, under which authority, and why the action was allowed, refused, or supervised at that point in time?
  5. What is the worst-case failure mode?
    In your design, is the worst case an invisible bypass or a documented refusal? If things go wrong, what will our GC and insurers actually see?


If a product cannot answer these questions clearly, it may offer AI features or monitoring, but it is not Refusal Infrastructure for Legal AI — and it is not SEAL Legal Runtime.

Refusal Infrastructure is a pre-execution authority control for high-risk actions. It implements Action Governance by placing a sealed governance layer (SEAL Runtime) in front of wired workflows. At runtime—before anything is filed, sent, or executed—it decides whether an action may proceed, must be refused, or requires supervision, and produces a sealed, tamper-evident artifact for every governed decision. It is not IAM, not model guardrails, and not GRC; it is a separate execution-time governance layer.