Governance Boundary & Coverage FAQ

How SEAL Legal Runtime governs — and what stays outside its seal

1. Does SEAL govern every action in our environment?


No.


SEAL Legal Runtime governs high-risk actions you choose to route through it.


  • In-scope: actions wired to SEAL’s pre-execution gate (for example: file, send, approve, move money, commit a binding step).
  • Out-of-scope: actions and systems that never pass through that gate.


Coverage grows as you wire more high-risk actions through SEAL.
We do not claim universal control over everything in your environment.

2. What does “non-bypassable within wired workflows” actually mean?


Once a workflow is wired to SEAL:


  • there is no alternate “approve” path in that workflow that skips the SEAL gate, and
  • any attempt to execute the governed action must receive a SEAL decision: approve, refuse, or supervised override.


If an action can execute without SEAL’s decision, that workflow is not yet wired and is treated as out of scope.

3. Who decides which actions must go through SEAL?

 

You do.


  • Legal, risk, and operations leaders define which actions are “high risk” and must be governed.
  • Those actions are then wired to SEAL as part of the implementation program.


SEAL enforces your authority model.

 It does not invent roles, policies, or risk thresholds.

4. What happens if someone tries to bypass SEAL?


Inside wired workflows, bypass attempts are treated as governance failures, not clever shortcuts.


Typical outcomes (depending on your design):


  • the action cannot be executed without going through the SEAL gate, or
  • the request is blocked and logged as an out-of-policy attempt.


Within wired workflows, the governed action cannot complete without a SEAL decision. If an organization observes or detects out-of-band execution paths, those should be treated as governance incidents and brought under wiring or control.

5. What happens if SEAL is unavailable?


For governed actions in wired workflows, SEAL is designed to be fail-closed:


  • If SEAL cannot return a decision, the default for governed actions is refusal, not silent approval.
  • You can define documented contingency procedures (for example: manual escalation path) that sit on top of that fail-closed behavior.


We do not treat downtime as permission.

6. How does SEAL interact with IAM, guardrails, and GRC?


  • IAM decides who can access systems and data.
  • Guardrails / model safety decide what models are allowed to say.
  • GRC holds your policies, controls, and risk posture.


SEAL Legal Runtime uses these as inputs and adds the missing piece:


A pre-execution authority gate that decides whether a specific high-risk action is allowed to run now, under this authority.


SEAL does not replace IAM, guardrails, or GRC.
It gives them an execution-time enforcement point.

7. What exactly is recorded in a sealed artifact? Are we over-collecting?


Sealed decision artifacts are designed to be governance-grade, not surveillance-grade.


They record:


  • governance anchors (role, vertical, scenario/motion type, venue/jurisdiction, consent state, turnaround profile),
  • the decision outcome (approve / refuse / supervised override),
  • high-level reason categories and timestamps.


They do not need to store:


  • full client matter content,
  • full prompts or model traces,
  • internal strategy or advice.


Artifacts are intentionally narrow: just enough to reconstruct who acted, on what, under which authority, and what SEAL decided.

8. Who owns the artifacts and identity data?


You do.


  • Identity and roles come from your IdP/SSO and governance systems.
  • Sealed artifacts are designed to be written to client-owned, audit storage with append-only / WORM-style integrity guarantees, depending on deployment.


Thinking OS™ does not claim ownership of your identity data, matter context, or artifacts.

9. Can SEAL Runtime make a bad decision we can’t override?


SEAL enforces your configured policies, but it is not infallible.


  • For governed actions, SEAL can return supervised override as an outcome.
  • Overrides are explicit, traceable decisions – not backdoor hacks:
  • who overrode,
  • on what basis,
  • under which authority,
  • at what time.


You retain both control (through policy design) and recourse (through supervised override), with a sealed record either way.

10. How do we expand coverage over time?


Coverage typically grows in three steps:


  1. Define high-risk actions in each practice / product line (file, send, approve, etc.).
  2. Wire those actions through SEAL’s pre-execution gate.
  3. Review artifacts to identify additional actions that should be brought under governance.


You don’t have to decide everything on day one.
SEAL lets you start with the highest-risk actions and expand in a controlled, evidence-backed way.

11. How do you keep “supervised override” from becoming a loophole?


Supervised override is a governed outcome, not a backdoor.


An override decision only appears when the firm’s own supervisory regime has explicitly authorized it. SEAL verifies that a valid authority signal was presented (for example, a signed supervisory approval), that it matches the matter and motion being overridden, and that it comes from a role the firm has marked as eligible to override. Both the original refusal and the override are sealed, so the firm can show who overrode what, when, and under which authority.


Policy about when overrides are allowed remains entirely under the firm’s GRC and professional-responsibility framework.

12. What inputs does SEAL require — and what does it not need?


At minimum, a governed request includes:


  • who is acting and in which role (from your IdP / SSO),
  • what they are trying to do (vertical / motion / action type),
  • where it sits (matter ID, venue / jurisdiction),
  • consent / authority posture, and
  • the relevant policy or rule-basis references.


SEAL does not require:

  • full matter text,
  • model prompts or traces, or
  • privileged strategy or advice.


It evaluates structured governance anchors, not the substance of your client work.

13. How are sealed artifacts verified, and who controls verification?


Each governed decision is tied to a unique decision ID and cryptographic hashes of the human-readable artifact and its JSON audit capsule.



Clients (or their auditors) can:


  • use those IDs and hashes to verify that artifacts haven’t been altered,
  • join SEAL records to their own logs, and
  • perform independent checks using their own storage and key-management systems.


Key custody and verification tooling stay under client control or client-approved HSM/KMS patterns; SEAL does not run a shared analytics layer across tenants.

14. How do policy changes and versions show up in artifacts?


Authority rules and governance policies are versioned in the client’s own systems. SEAL artifacts are designed to reference:


  • which policy set was in force, and
  • which version governed that decision.


When policies change, new decisions are made under the new version; historical artifacts remain intact and tied to the policy version that applied at the time. Remediation, when required, is done by issuing new decisions — not by editing past artifacts.

15. What is SEAL’s threat model, and what is explicitly out of scope?


In scope:


  • preventing out-of-policy execution for actions routed through the SEAL gate,
  • enforcing identity, consent, and authority checks even when an identity token is misused, and
  • producing a forensic trail of approvals, refusals, and overrides.


Out of scope:


  • actions and systems that never route through the SEAL gate,
  • physical-world behavior outside digital workflows, and
  • compromises of client-owned IdP, keys, or endpoints beyond the runtime boundary.


SEAL is one control among many in a firm’s overall security and ethics posture.

16. Where does SEAL run — cloud, on-prem, or something else?


SEAL Legal Runtime is delivered as vendor-hosted judgment infrastructure: a sealed API you route governed requests through, under your own identity and GRC regime.


At a high level:


  • each tenant runs in an isolated environment;
  • no client matter text is required for decisions;
  • only governance anchors, outcomes, and artifact IDs cross the boundary; and
  • clients own their logs, storage, and routing.


This gives firms a clear control boundary: their systems own context and policy; SEAL owns runtime enforcement.