Scenarios

How SEAL Legal Runtime Behaves in Practice

These scenarios show how SEAL Legal Runtime applies Refusal Infrastructure to concrete high-risk legal action patterns.


They are synthetic but buyer-realistic examples designed to make the control boundary understandable without using client data or exposing non-public runtime implementation.


The scenarios answer four questions:

  1. What action was being attempted?
  2. What authority or governance condition mattered?
  3. What governed outcome did SEAL return?
  4. What reviewable decision evidence was produced?


Current evaluation posture


In the first law-firm evaluation, SEAL runs observe-only.


That means a scenario may produce a governance outcome such as Approve, Refuse, or require an authorized supervised path, while the production workflow remains nonblocking.


Controlled enforcement is considered only later under separate written scope.

Sealed Artifact, Not a Dashboard

Here’s an example artifact.

A paralegal tried to file a motion in a venue where only licensed counsel may file. The 𝗽𝗿𝗲-𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗮𝘂𝘁𝗵𝗼𝗿𝗶𝘁𝘆 𝗴𝗮𝘁𝗲 refused the action and produced this sealed record: who acted, on what matter, under which policy/authority, and why the action was blocked.

This is what it looks like when the 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗴𝗮𝘁𝗲 actually says “no” and leaves evidence.

Redacted artifact example. Fields unrelated to verification have been removed.

Scenario 1 — Missing Client Consent

A governed legal action reaches the final-submit boundary without the consent required by the firm’s configured posture.


Governance question:
Is the required consent present for this action and matter?


SEAL outcome:
 Refuse


In observe-only mode, this is recorded as a would-have-refused finding without production blocking.



Evidence:
A reviewable decision artifact records the governed action, relevant consent posture, reason for the refusal, and associated decision context.

Scenario 2 — Wrong Matter, Venue, or Authority Scope

A filing or submission is associated with context that does not match the authority supplied for the action.


Governance question:
Does this actor’s authority apply to this specific action, matter, docket, venue, or other required scope?


SEAL outcome:
 Refuse


In observe-only mode, the mismatch becomes a reviewable finding rather than a production block.



Evidence:
The decision artifact preserves the relevant context and authority anchors and records why the action did not satisfy the configured authority conditions.

Scenario 3 — Action Requires Supervision

A high-risk legal action reaches the final-submit boundary under conditions the firm has configured to require authorized review.


Governance question:
May this action proceed ordinarily, or does it require an authorized supervised path?


SEAL outcome:
 Supervise


SEAL records that supervision is required.


The firm owns the supervision workflow, reviewer selection, escalation, and any later authorized override.


Evidence:
The governed outcome is recorded with the relevant action, authority, supervision, and decision context.

What These Scenarios Are — and Are Not

These scenarios are designed to demonstrate control behavior, not legal judgment.


SEAL does not:


  • draft the filing;
  • decide whether the filing is legally correct;
  • select legal strategy;
  • choose the firm’s policy;
  • operate the firm’s supervision workflow.


The firm supplies the governance posture.


SEAL evaluates the scoped action boundary and records the governed outcome.

See the Evidence

These scenarios are designed to demonstrate control behavior, not legal judgment.


These scenarios explain the behavior.



The proof materials show the evaluator-visible evidence.