Governance Boundary & Coverage FAQ

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 authority gate, such as file, send, approve, disclose, submit, or commit a binding legal step.
• Out-of-scope: actions and systems that never pass through that gate.

Coverage grows as you wire more high-risk actions through SEAL.
Coverage is explicit, not implied. 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 configured so the governed path requires SEAL, the governed action should not proceed without a SEAL outcome.

That outcome is:

• approve,
  
• refuse, or
  
• supervised override.

This is scope-bounded.

SEAL does not claim universal non-bypassability across the firm. It only governs workflows that have been wired through the gate.

If an action can still execute outside SEAL, that path is out of scope until the firm brings it under workflow control.

3. Who decides which actions must go through SEAL?

Legal, risk, and operations leaders define which actions are high risk and should be governed.

Those actions are brought into SEAL only through agreed pilot or enforcement scope.

SEAL enforces the firm’s configured authority model.

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

4. Does SEAL need to integrate directly with ECF or the court portal?

No — not for the first observe-only evaluation.

The first pilot evaluates the firm-controlled workflow boundary before external submission. SEAL receives a structured intent to act and records what it would have approved, refused, or routed for supervision.

Production enforcement is a separate decision. If the firm later wants enforcement, the exact wiring point is scoped with the firm or workflow vendor so the governed path requires a SEAL outcome before the filing proceeds.

SEAL does not replace the filing system, court portal, matter system, DMS, GRC platform, or routing engine.

5. What happens if someone tries to bypass SEAL?

Within governed workflows, bypass attempts should be treated as governance exceptions, not acceptable shortcuts.

Depending on the firm’s configured control design, the governed action may be refused, routed for supervision, or recorded as an out-of-policy attempt.

If the firm discovers an out-of-band execution path, that path is outside SEAL coverage until it is brought under workflow control.

SEAL governs the gate. The firm owns the broader workflow discipline around that gate.

6. What happens if SEAL is unavailable?

In observe-only mode, SEAL does not block production users. It records what it would have approved, refused, or routed.

In controlled enforcement, the design posture is no silent degradation.

If SEAL cannot safely evaluate a governed request, the runtime should refuse or route for supervision instead of silently allowing an unevaluated action to proceed.

Operational SLAs, continuity procedures, fallback paths, and escalation rules belong in the written agreement and the firm’s business-continuity planning.

Unsafe uncertainty should not become invisible approval.

7. What happens near a deadline?

Deadline pressure should not become permission to bypass governance.

If a governed request is refused near a deadline, SEAL is designed to:

•  preserve the refusal,
• surface the deadline context, and
• support a firm-owned escalation path.

The firm owns the:

•  supervisor path,
• after-hours review posture,
• fallback procedure, and
• routing destination.

Deadline-sensitive refusal categories should not move into controlled enforcement until the firm has defined who reviews them, how quickly they must be reviewed, and what fallback procedure applies.

8. 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 layer:

The Commit Layer — 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.

9. What if our authority, role, or matter data is incomplete?

SEAL depends on the structured signals the firm provides for the governed workflow.

It does not make inaccurate source data accurate.

In observe-only mode, stale roles, missing authority, inconsistent matter context, unclear consent, or incomplete supervision signals become review findings, not production blockers.

That is one reason the first pilot starts observe-only. The firm can see whether its authority signals are ready before any refusal category moves into controlled enforcement.

The firm decides whether signal quality is ready for enforcement.

10. 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 the minimum governance context needed to reconstruct who acted, what kind of governed action was attempted, what decision was returned, and when.

They are not intended to function as full matter files, prompt archives, or strategy records.

Artifacts are intentionally narrow: just enough to support accountability, review, and evidentiary use.

A decision artifact is designed to show the decision reference, actor and action context, governed workflow or matter context, returned outcome, relevant policy or rule-basis reference, high-level reason category, time of decision, and integrity-verifiable artifact reference.

11. Who owns the artifacts and identity data?

You do.

You own both the authority sources and the resulting evidence surface. Identity and roles come from your IdP / SSO and governance systems. Sealed artifacts are designed for client-controlled audit retention and evidentiary use, subject to the deployment and retention model agreed with the client.

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

12. Can we still use or verify artifacts if we stop using SEAL?

Decision artifacts are designed for client-controlled retention with integrity controls.

The firm’s retention, export, post-termination access, verification support, and artifact review rights should be defined in the written agreement.

Thinking OS™ does not claim ownership of the firm’s identity data, matter context, or decision artifacts.

Any post-termination verification support, export process, or vendor-operated review support should be expressly defined in the written agreement.

13. Can SEAL return a decision we disagree with?

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 informal bypasses:
• 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.

14. How do we expand coverage over time?

Coverage typically grows in three steps:

1. Define high-risk actions by practice area, workflow, or action class
2. Wire those actions through SEAL’s pre-execution authority 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.

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

Supervised override is a governed outcome, not a backdoor.

An override is only available where the organization has explicitly defined a supervisory path for that action class. Both the original refusal and the override outcome are recorded so the firm can show who accepted responsibility, when, and under which governance posture.

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

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

For a first evaluation, SEAL needs enough structured governance signals to evaluate the governed action. Those signal families usually include:

• who is acting and in which role,
  
• what action is being attempted,
  
• what workflow or legal environment is involved,
  
• consent, authority, or required evidence posture,
  
• deadline or urgency context where relevant, and
  
• applicable policy or rule-basis reference where available.

SEAL does not require:

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

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

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

Sealed artifacts are designed to be integrity-verifiable and suitable for independent review under client-controlled audit and retention arrangements.

Verification support is designed to help clients and approved reviewers assess whether artifacts are attributable to a governed decision and protected against alteration after issuance, subject to the agreed retention and verification model.

Public materials describe evaluator-visible properties and evidence surfaces; verification, retention, and control-boundary details are discussed in confidential technical review when appropriate.

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

Where the client’s authority rules and governance policies are versioned, SEAL artifacts are designed to reference the applicable policy set or rule-basis used for the governed decision.

That may include:

• 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.

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

In scope:

• enforcing the governed path for actions routed through the SEAL gate,
• evaluating identity, consent, authority, and workflow signals supplied for the governed request, and
• producing a reviewable record of approvals, refusals, and supervised 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.

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

Deployment model, isolation posture, and control-boundary details are discussed in confidential technical review.

Publicly, the important point is simpler:

SEAL is designed to sit at the execution boundary for governed workflows and produce client-controlled, reviewable decision artifacts, while keeping internal runtime details non-public.

Clients evaluating SEAL should expect clear answers on:

• deployment scope and isolation posture
• where governed requests are evaluated
• where decision artifacts are retained
• how client-controlled review and evidentiary use are supported

Specific environment and deployment details are handled under diligence, not in public-facing documentation.