Governance Boundary & Coverage FAQ

1. Does SEAL govern every action in our environment?

No.

For the 30-day review, SEAL evaluates one designated filing workflow and one designated final-submit boundary.

Anything outside that written review scope remains outside SEAL coverage, including unrelated workflows, action classes, practice groups, and alternate execution paths.

Coverage is explicit, not implied. SEAL does not claim universal control across the firm.



If the firm later chooses to evaluate or govern another consequential legal action, that action is added only through separate written scope.

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

“Non-bypassable when wired” applies to separately approved controlled enforcement, not to the 30-day observe-only review.

During the observe-only review, SEAL records what Would Have Approved, Would Have Refused, or Routed for Supervision, but the finding does not control whether the production filing proceeds.

If controlled enforcement is later separately approved, the firm and Thinking OS identify a specific workflow path that is wired to require a SEAL outcome before the scoped action proceeds.

That property is scope-bounded.



SEAL does not claim universal non-bypassability across the firm. If another execution path can still complete outside the governed path, that alternate path remains outside SEAL’s claimed control surface.

3. Who decides which actions must go through SEAL?

The firm does.

The firm defines and approves the workflow scope, authority posture, trusted role sources, supervision model, and any conditions that should produce a would-have-refused or supervised-review finding.

During the 30-day observe-only review, SEAL evaluates those configured conditions and records the finding. It does not enforce the production workflow.

If controlled enforcement is later separately approved, the governed outcome may become authoritative only for the agreed wired path.



SEAL does not invent firm policy, legal authority, hierarchy, or professional-responsibility rules.

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

No—not for the 30-day observe-only review.

The review focuses on the firm-controlled workflow boundary immediately before external submission. The firm-controlled system that owns that event supplies SEAL with the agreed structured governance request.

During the review, SEAL records what would have been approved, refused, or routed for supervision without blocking, delaying, or altering the production filing.

If controlled enforcement is later considered, the exact production wiring point must be separately identified so the agreed governed path can require a SEAL outcome before the action proceeds.

SEAL does not replace ECF, the court portal, filing software, DMS, matter systems, IAM, GRC, docketing systems, or routing systems.

5. What happens if someone tries to bypass SEAL?

The answer depends on the operating posture.

During the 30-day observe-only review, an alternate execution path is a coverage finding. SEAL does not claim that it blocks production bypasses during the review.

Under separately approved controlled enforcement, the agreed workflow path can be wired to require a SEAL outcome before the scoped action proceeds.

If the firm discovers another route that can still complete outside that governed path, the alternate route remains outside SEAL coverage until the firm deliberately brings it under workflow control.



SEAL governs the scoped control point. The firm owns the broader workflow environment.

6. What happens if SEAL is unavailable?

During the 30-day observe-only review, SEAL is not a production filing dependency.

If SEAL is temporarily unavailable, the firm’s existing production process remains in control. An affected event may not receive a SEAL finding or decision artifact. Any known observation gap should be treated as part of the review record and examined during the agreed review cadence.

Controlled enforcement is different. A governed request should not silently proceed merely because the authority control is unavailable.

Before any controlled enforcement is activated, availability commitments, fallback procedures, continuity rules, escalation paths, and fail-closed behavior must be separately defined in writing.



Unsafe uncertainty should not become invisible approval.

7. What happens near a deadline?

Deadline pressure does not become permission.

During the 30-day observe-only review, deadline and urgency facts supplied by firm-controlled systems may be preserved in the governed finding and decision artifact. Deadline-sensitive findings remain non-enforcing.

The firm owns:

• deadline calculation and calendaring;
• review timing;
• supervisor selection;
• after-hours procedures;
• fallback and escalation.

No deadline-sensitive refusal condition should move into controlled enforcement until those responsibilities are explicitly defined, including who reviews the event, the review window, what happens if the reviewer is unavailable, and any permitted supervised path.

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

These controls solve different problems.

• IAM / identity systems establish who or what the actor is and what systems or resources it may access.
• DMS / matter / workflow systems establish matter, document, workflow, and institutional context.
• GRC and policy systems hold firm policy, control requirements, and risk posture.
• Model / AI governance addresses whether an AI system belongs in the workflow and how that system is evaluated or supervised.

SEAL sits downstream of those layers, at the moment a scoped legal action is ready to become consequential.

Its narrower question is:

Given the firm’s established governance facts, may this particular actor take this particular action under this authority before the filing leaves the firm?

SEAL does not replace IAM, DMS, GRC, model governance, or lawyer judgment.

Upstream governance decides whether the system belongs in the workflow. Runtime control decides whether a particular action is allowed to bind.

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

SEAL depends on the structured governance facts supplied for the scoped workflow.

It does not make inaccurate source data accurate, and it does not turn missing or contradictory required facts into silent approval.

If required identity, role, matter, docket, action, authority, consent, evidence, or deadline context is stale, missing, mismatched, contradictory, or otherwise not safely evaluable, SEAL records the applicable would-have-refused or supervised-review finding under the configured review posture.

During the 30-day review, that finding does not block, delay, or alter the production filing.



The purpose is to let the firm determine whether its source signals are sufficiently reliable before any controlled enforcement is considered.

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

Decision artifacts are designed to preserve the minimum reviewable evidence needed to understand a governed finding without becoming a copy of the firm’s matter file.

Depending on the scoped workflow, an artifact may show:

• the governed action;
• who or what attempted it;
• the governed finding;
• relevant role or authority posture;
• matter or workflow context;
• policy or rule-basis references;
• high-level reason category;
• runtime posture;
• stable decision or trace references;
• integrity-verifiable evidence references.

SEAL does not require full matter text, model prompts, model traces, privileged strategy, or unrelated legal-advice content merely to conduct the review.

An artifact does not by itself prove that the firm’s policy was legally correct, that upstream data was accurate, that every filing path was governed, or that the filing itself was legally sufficient.

11. Who owns the artifacts and identity data?

The firm remains the source of truth for its identity, roles, policy, authority, and matter context, and the firm owns its decision artifacts as firm business records.

The firm controls the artifacts’ retention, review, privilege, confidentiality, use, and disclosure posture.

Thinking OS retains ownership of SEAL Legal Runtime, its proprietary internals, and implementation IP.

Artifact ownership and artifact custody are not the same thing. Storage location, export, deletion, post-termination access, and verification support are deployment-specific and should be defined in the applicable written agreement.



Thinking OS does not claim ownership of the firm’s legal work, matter data, authority model, identity data, or decision records.

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

The firm should retain control of its decision records according to the retention and custody model agreed for the deployment.

The applicable agreement should define:

• artifact retention;
• export;
• deletion;
• post-termination access;
• post-termination verification support;
• any vendor-operated review support.

Decision artifacts are designed with integrity controls so later review does not depend solely on a live vendor dashboard.

Thinking OS does not claim ownership of the firm’s decision records.



The exact post-termination verification process is a deployment and diligence question, not a blanket public guarantee.

13. Can SEAL return a decision we disagree with?

Yes. SEAL is a control, not a claim that the system is always right.

During the 30-day observe-only review, a questionable finding is a review issue, not a production blocker.

The decision artifact is designed to expose enough governance context for the firm and Thinking OS to determine whether the issue arose from:

• source data;
• authority or role mapping;
• configuration;
• policy ambiguity;
• or a runtime defect.

The firm remains responsible for its own policy, identity, authority, and source-system facts. If Thinking OS identifies a runtime defect materially affecting governed findings, Thinking OS is responsible for coordinating remediation within the agreed scope.



If controlled enforcement is later approved, any formal supervised exception path must be separately defined and authorized. A disagreement does not automatically become an override.

14. How do we expand coverage over time?

Expansion is optional.

The current offer begins with one designated filing workflow and one final-submit boundary.

At the end of the review, the firm may:

• stop;
• continue observing for a defined reason;
• improve signal quality and re-review;
• or consider one narrow controlled-enforcement path under separate written scope.

If the firm later chooses to evaluate another workflow or consequential legal action, that additional scope is considered separately.



The review creates no obligation to expand, and coverage does not grow automatically.

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

During the 30-day observe-only review, SEAL does not operate a supervised override. It may record that an action would have required supervision.

If controlled enforcement is later separately approved, a formal supervised exception path may be configured only where the firm has explicitly defined:

• who may supervise;
• which refusal conditions are eligible;
• what authority is required;
• what reason must be recorded;
• and how the later decision links back to the original refusal.

The original refusal should remain preserved and separately attributable from the later authorized outcome.

Supervision is not a silent bypass.



The firm owns the supervision process and professional judgment.

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

For the 30-day review, SEAL uses the minimum structured governance signals necessary for the scoped authority decision.

Depending on the agreed workflow, those may include:

• actor identity;
• trusted role or group;
• workflow and attempted action;
• client, matter, and docket identifiers where required;
• authority / consent / evidence posture;
• supervision requirement;
• deadline or urgency where material.

SEAL does not require full matter text, complete DMS access, model prompts, model traces, privileged strategy, passwords, raw credentials, private signing keys, or unrelated legal-advice content merely to conduct the review.



Existing firm systems remain the sources of truth. SEAL evaluates the minimum governance facts needed at the final-submit boundary.

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

Decision artifacts are designed to be integrity-verifiable and suitable for qualified review without exposing proprietary runtime internals.

An evaluator can review, as applicable:

• stable decision identity;
• timestamp;
• governed finding;
• relevant context anchors;
• policy or rule-basis linkage;
• trace or correlation reference;
• integrity indicators.

The artifact is intended to help a qualified reviewer determine that a specific governed finding was recorded against specific context and policy posture.

It does not by itself prove legal correctness, source-data accuracy, universal workflow coverage, or court admissibility.



Deployment-specific verification mechanics, retention, export, and post-termination verification support are addressed in written diligence or the applicable agreement.

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

Where the firm’s authority rules and governance policies are versioned and supplied to the scoped runtime, decision artifacts are designed to preserve the relevant policy or rule-basis reference associated with the governed finding.

Material changes to authority rules, role mappings, workflow scope, supervision posture, or policy source should be approved through the firm’s agreed change-control process before taking effect.

New governed findings should reference the policy posture in force at the time.

Historical decision artifacts should not be retroactively rewritten to make them match later policy.



Deployment-specific change authorization, logging, and configuration governance are confirmed in written diligence.

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

During the 30-day observe-only review, SEAL is responsible for evaluating the agreed final-submit requests within the scoped review and producing the associated governed findings and decision artifacts.

The firm’s identity, matter, policy, authority, consent, deadline, and workflow systems remain the sources of truth.

Outside SEAL’s review scope are:

• actions and systems not included in the written review scope;
• alternate execution paths not being observed;
• physical-world activity outside the digital workflow;
• legal correctness and professional judgment;
• inaccurate or compromised upstream source facts that SEAL cannot independently make accurate.

If controlled enforcement is later approved, its control boundary remains limited to the specifically agreed workflow path wired to require a SEAL outcome.



SEAL is one control within the firm’s broader legal, security, workflow, and professional-responsibility environment..

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

The current evaluation deployment model is vendor-hosted SEAL Legal Runtime.

The firm does not need to host SEAL internals or install customer-operated SEAL software for the 30-day review.

The firm-controlled workflow calls SEAL through an authenticated integration surface and receives the governed finding and reviewable decision evidence.

Standard access is hosted, not on-prem or customer-operated, unless something different is separately agreed in writing.

Deployment-specific questions such as region, tenant isolation, artifact custody, availability, security controls, retention, and continuity are addressed through deeper diligence and the applicable agreement.



Hosted does not mean the firm gives up ownership of policy, authority, legal work, or decision records.

21. Does a SEAL approval mean the filing is legally correct?

No.

During the 30-day observe-only review, a Would Have Approved finding means that the request satisfied the firm’s configured authority conditions under the governance facts supplied for the scoped action.

It does not mean that the filing is legally correct, strategically wise, ethically sufficient, jurisdictionally proper, or professionally advisable.

Lawyers and supervisors remain responsible for legal judgment and professional obligations.



Approval means “authorized under configured conditions,” not “legally correct.”

22. What does the 30-day observe-only posture actually mean?

During the 30-day review, SEAL evaluates the designated final-submit workflow and records what Would Have Approved, Would Have Refused, or Routed for Supervision.

Those findings are reviewable and evidence-producing, but they are non-enforcing.

No production filing is blocked, delayed, or altered during the review.

At the end of the review, the firm may stop, continue observing for a defined reason, improve signal quality, or consider one narrow controlled-enforcement path under separate written scope.



Nothing moves into controlled enforcement automatically.