How to Evaluate SEAL:

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 Refusal Infrastructure applied to high-risk legal actions.
It implements Action Governance by inserting the missing Commit Layer: a pre-execution authority gate in wired workflows.


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

Five Things SEAL Legal Runtime Does Claim

  1. Commit-Layer control in wired legal workflows
    In workflows integrated with SEAL Legal Runtime, designated high-risk actions are evaluated at a     pre-execution authority gate before they proceed.
  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. Fail-closed behavior for governed actions
    Where identity, policy, authority / consent, or required context is missing, ambiguous, inconsistent, or unreliable, governed actions are designed to return a     refusal or supervised override path — not silent passes or best-effort execution.
  4. Client-owned identity, policy sources, and decision artifacts
    Roles and authority come from the client’s own systems (IdP, GRC, legal governance). Sealed decision artifacts are designed for     client-controlled audit retention and review, with append-only retention and integrity controls where applicable.
  5. Sealed artifacts for every governed decision
    Governed approvals, refusals, and supervised overrides are designed to produce     integrity-verifiable decision artifacts suitable for audit, oversight, and evidentiary review.

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 pre-execution authority 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 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 provides a     Commit-Layer runtime gate in front of high-risk actions.
  5. Not an open framework or public control specification
    Public briefs describe the     what and why of Refusal Infrastructure for Legal AI. They are not a blueprint or public kit to re-implement SEAL Legal 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 your pre-execution authority gate / Commit Layer?
    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 your decision records support independent review of what kind of governed action was attempted, what decision was returned, under which governance posture, and when?
  5. What is the worst-case failure mode?
    In your design, is the worst case a documented refusal or an undetected execution path? If things go wrong, what evidence will leadership, auditors, and insurers be able to review?


If a product cannot answer these questions clearly, it may offer AI features, monitoring, or policy administration, but it is not the same category of Refusal Infrastructure / pre-execution governance runtime described here.