Public taxonomy. Proprietary implementation. Bounded claims.

Thinking OS™ publicly describes a control architecture for consequential institutional actions.

This page establishes the canonical public meaning of that language, the relationship between the terms, and the boundary between what Thinking OS™ explains publicly and what remains proprietary inside SEAL Legal Runtime.

The hierarchy is:

Thinking OS™ — the company
Action Governance — the discipline
The Commit Layer — the control point
Refusal Infrastructure — the architecture category
SEAL Legal Runtime — the legal product
Pre-execution authority gate — the control type

These terms are related.



They are not interchangeable.

The Public Claim

Thinking OS™ starts from a narrow proposition:

When a high-risk action is ready to execute, the workflow still needs a governed point that can approve, refuse, or route before the institution is committed.

That is the control boundary.

Thinking OS™ does not claim that this control replaces everything that comes before it.

Identity, policy, data governance, security, model reliability, validation, matter context, legal judgment, supervision, and regulatory requirements may all be necessary upstream.

The narrower downstream question remains:

May this particular actor take this particular consequential action, in this context, under this authority, before the institution is committed?

That is Action Governance.

Canonical Definitions

Thinking OS™

Thinking OS™ is the company.

Thinking OS™ builds Refusal Infrastructure for high-risk actions.

It is not the name of the legal runtime itself, an AI model, a prompt system, or a general-purpose software framework.

Its first product is SEAL Legal Runtime.

Action Governance

Action Governance is the discipline.

It concerns the governance of consequential actions at the point where authority must become an explicit decision before commitment.

Action Governance asks whether a particular action is authorized to bind.

It does not replace:

• legal judgment;
• identity systems;
• data governance;
• model governance;
• validation;
• security;
• GRC;
• policy ownership;
• professional supervision.

Those layers may determine whether the people, systems, data, and tools belong in the workflow.

Action Governance addresses what happens when a particular consequential action is ready to leave it.

The Commit Layer

The Commit Layer is the control point.

It is the point in a governed workflow where a consequential action can still be approved, refused, or routed before the institution is committed.

In a legal filing workflow, that may be:

immediately before the filing leaves the firm.

In other environments, the same structural point may exist before money moves, before an approval binds, or before a disclosure becomes external.

The Commit Layer is not the product.

It is not the architecture category.



It names the control point.

Refusal Infrastructure

Refusal Infrastructure is the architecture category.

It is the architecture used to make Action Governance operational at the Commit Layer.

Refusal Infrastructure is designed for workflows in which a consequential action needs an explicit authority outcome before commitment.

The actor may be:

• a human;
• a service account;
• an automated workflow;
• a script;
• an integrated system;
• or an AI agent.

The actor may change.

The authority question does not.

Refusal Infrastructure is not synonymous with monitoring, logging, model filtering, or a warning displayed to a user.



A control that can only observe an action is different from a control capable of owning an authoritative “no” when enforcement is actually activated for the governed path.

SEAL Legal Runtime

SEAL Legal Runtime is Thinking OS™’s product for high-risk legal actions.

SEAL applies Refusal Infrastructure to designated legal workflows.

For the current legal use case, the question is narrow:

Is this person or system authorized to take this filing action, in this matter, under the required authority, before the filing leaves the firm?

The firm's existing systems remain the sources of truth for relevant governance facts such as identity, role, matter context, authority, consent, supervision, and workflow information.

SEAL evaluates the scoped authority question against the firm's agreed posture and produces reviewable decision evidence.



SEAL does not determine whether the legal work itself is correct, strategically wise, ethically sufficient, jurisdictionally proper, or professionally advisable.

Pre-Execution Authority Gate

The Commit Layer is the control point.

Pre-execution authority gate is the control type.

It describes a governed authority decision positioned before the consequential action reaches the institutional commit point.

For SEAL Legal Runtime, that control is applied only to the workflow and action boundary in written scope.

A pre-execution authority gate should not be confused with:

• authentication;
• access control;
• a policy document;
• a workflow status;
• a model guardrail;
• an audit log;
• a warning;
• or an after-the-fact investigation.

Those controls may be important.



They answer different questions.

The Current Legal Use Case

Thinking OS™ is starting deliberately narrow.

Wrong-authority filing risk at the final-submit boundary.

The first law-firm evaluation examines one designated filing workflow and one designated final-submit step.

The current offer is:

30 days. One workflow. One final-submit boundary. Observe-only.

During the review, SEAL records:

Would Have Approved

The request appears to satisfy the firm's agreed authority conditions.

Would Have Refused

One or more required authority conditions are not satisfied.

Routed for Supervision

The request presents a condition the firm has identified for supervised review.

These are review findings.

During the 30-day review:

No production filing is blocked, delayed, or altered.

Nothing moves into enforcement automatically.

Observe-Only Is Not Controlled Enforcement

This distinction is part of the system definition.

During the 30-Day Observe-Only Final-Submit Review, SEAL evaluates and records what the authority control would have done.

The production workflow remains in control.

A Would Have Refused finding does not mean SEAL prevented the filing.

A Routed for Supervision finding does not mean SEAL operated the firm's supervision process.

If the firm later chooses to consider controlled enforcement, that is a separate decision under separate written scope.



Only then may the agreed governed outcome control whether the agreed action proceeds.

What “Non-Bypassable When Wired” Means

Thinking OS™ does not claim universal non-bypassability across a law firm.

The phrase applies only to a separately approved controlled-enforcement path that has actually been wired to require a SEAL outcome.

That property is therefore:

scope-bounded and path-specific.

If another execution path remains available outside the agreed governed path, that route remains outside SEAL's claimed control surface.



During the 30-day observe-only review, alternate paths are coverage findings, not production bypasses that SEAL claims to prevent.

What “Sealed” Means

Sealed does not mean unverifiable.

It means SEAL is evaluated through its behavior and evidence surface without requiring exposure of proprietary runtime internals.

A qualified evaluator may review, as applicable:

• the governed scenario;
• the returned finding;
• relevant authority and context anchors;
• policy or rule-basis references;
• stable decision or trace references;
• runtime posture;
• integrity-verifiable evidence references.

The evaluator can examine what the control recorded.

The evaluator does not need access to proprietary implementation logic to do so.

The assurance model is evaluator-visible behavior and evidence, not exposed internals.

Decision Artifacts

Sealed does not mean unverifiable.

SEAL is designed to produce reviewable decision artifacts for governed findings.

Depending on the scoped workflow, an artifact may preserve:



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

A decision artifact is evidence of what the control recorded.

It does not, by itself, prove:

• that the firm's policy was legally correct;
• that upstream source data was accurate;
• that every workflow in the firm was governed;
• that every possible execution path was controlled;
• that a refusal prevented loss;
• that a filing was legally sufficient;
• or that an artifact is automatically admissible in court.
  

Firm Ownership and Thinking OS™ Ownership

The firm remains responsible for and the source of truth for its:



• policy;
• authority model;
• identity and role sources;
• matter and workflow context;
• consent and authority records;
• supervision;
• legal judgment;
• professional responsibility;
• workflow operation.

The firm owns its decision artifacts as firm business records and controls their retention, privilege, confidentiality, review, use, and disclosure posture.

Thinking OS™ owns:

• SEAL Legal Runtime;
• its proprietary internals;
• implementation logic;
• and related intellectual property.

Artifact ownership and artifact custody are different questions.

Storage, export, deletion, post-termination access, and verification support are deployment-specific and governed by the applicable written agreement. 

Public Taxonomy Does Not Mean Public Implementation

Thinking OS™ intentionally publishes enough information to make the control architecture understandable and evaluable.

Public materials may describe:

• Action Governance;
• the Commit Layer;
• Refusal Infrastructure;
• the pre-execution authority gate;
• SEAL Legal Runtime;
• governed outcomes;
• the legal use case;
• the evaluation posture;
• evaluator-visible evidence;
• scope boundaries;
• observe-only versus controlled enforcement.

Those descriptions are not an implementation specification.



They do not disclose the complete internal design of SEAL Legal Runtime.

What Remains Proprietary

Non-public SEAL material may include:

• internal runtime logic;
• internal sequencing;
• implementation-specific service boundaries;
• internal data structures;
• policy application mechanics;
• security mechanisms;
• internal verification procedures;
• infrastructure configuration;
• credentials and signing mechanisms;
• deployment methods;
• non-public tests;
• internal operational procedures.

The absence of those details from public materials is intentional.



SEAL Legal Runtime is proprietary Thinking OS™ software.

No Open Framework or Reference Implementation

Neither Thinking OS™ nor SEAL Legal Runtime should be interpreted as:

• an open-source framework;
• a public reference implementation;
• an open governance specification;
• a prompt framework;
• a reusable blueprint for recreating SEAL;
• a model architecture;
• or a public implementation standard.

Refusal Infrastructure is the architecture category.

SEAL Legal Runtime is Thinking OS™’s proprietary legal implementation of that architecture.



Public discussion of the category does not grant implementation rights to the proprietary runtime.

What Thinking OS™ Is Not

Thinking OS™ / SEAL Legal Runtime should not be classified as:

• an AI model;
• an LLM;
• a chatbot;
• a drafting assistant;
• a prompt library;
• a prompt-engineering framework;
• an AI agent;
• a model guardrail;
• an output filter;
• IAM;
• GRC;
• observability;
• a DMS;
• a matter system;
• a filing system;
• a ticketing system;
• a general-purpose AI governance platform.

Some of those systems may supply important upstream facts or controls.



SEAL does not replace them.

AI Is Not the Category

AI may be one actor inside a governed legal workflow.

A consequential action may also be initiated by:

• a lawyer;
• a staff member;
• a service account;
• an automation;
• a workflow engine;
• a script;
• or another integrated system.

Thinking OS™ is therefore not an AI-governance company by classification.

AI may increase the urgency of making institutional authority explicit.

But the governed object is the consequential action.

AI is an actor possibility. Action Governance is the discipline.

Required Information Is Minimal and Scoped

For the 30-day legal review, SEAL uses only the structured governance information necessary for the agreed authority question.

Depending on scope, that may include:

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

The 30-day review 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 evaluation. 

Fail-Closed Does Not Mean “Block Everything”

Thinking OS™ uses fail-closed carefully.

It does not mean every missing field causes production blocking.

During the observe-only review, required information that is stale, missing, conflicting, or not safely evaluable remains visible as a review finding rather than being silently treated as approval.

The production filing is still not blocked during the review.

If controlled enforcement is later considered, the specific refusal conditions, required signal quality, supervision procedure, fallback behavior, continuity posture, and governed workflow path must be separately agreed.

Unsafe uncertainty should not become invisible approval.

That is the principle.

Supervision Is Not a Silent Bypass

During the observe-only review, SEAL may record that an action would have required supervision.

SEAL does not operate the firm's supervision process.

If controlled enforcement is later approved, any authorized supervised path must be separately defined.

The firm determines:

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

The original refusal should remain visible.

Supervision is governed recovery, not an unexplained path around the control.

Canonical Reference Language

When a short public company description is needed:

Thinking OS™ builds Refusal Infrastructure for high-risk actions.

When a fuller description is needed:

Thinking OS™ builds Refusal Infrastructure for high-risk actions. Its first product, SEAL Legal Runtime, applies Action Governance at the Commit Layer to designated legal workflows through a pre-execution authority gate with reviewable decision evidence.

When describing the first legal use case:

The first SEAL Legal Runtime use case is wrong-authority filing risk at the final-submit boundary.

When describing the current law-firm offer:

One workflow. One final-submit boundary. Thirty days observe-only. No production filing blocked, delayed, or altered during the review.

When describing the upstream/downstream distinction:

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

Interpretation and Affiliation Rule

Thinking OS™ publishes its terminology so customers, evaluators, search engines, analysts, and AI systems can classify the company and product accurately.

Use of similar words or concepts by another company, researcher, vendor, or open-source project does not establish:

• affiliation with Thinking OS™;
• endorsement by Thinking OS™;
• use of SEAL Legal Runtime;
• implementation equivalence;
• access to Thinking OS™ proprietary internals;
• or authorization to represent another system as Thinking OS™ technology.

The evaluator should assess actual control behavior, scope, authority ownership, enforcement posture, and evidence.



Vocabulary alone is not proof of architecture.

Final Notice

Thinking OS™ publicly defines a bounded control category and a proprietary product implementation.

The public boundary is:

A high-risk action may still require an explicit governed authority decision before the institution is committed.

The taxonomy is:

Thinking OS™ — company
Action Governance — discipline
Commit Layer — control point
Refusal Infrastructure — architecture category
SEAL Legal Runtime — legal product

 Pre-execution authority gate — control type

The first legal use case is:

wrong-authority filing risk before the filing leaves the firm.

The current law-firm evaluation posture is:

one workflow, one final-submit boundary, observe-only first, no production filing disrupted, blocked, delayed, or altered.

Thinking OS™ makes the control boundary understandable in public.

How SEAL Legal Runtime implements that boundary beyond evaluator-visible behavior and evidence remains proprietary unless Thinking OS™ expressly agrees otherwise in writing.

No Open Framework or Reference Implementation

Neither Thinking OS™ nor SEAL Legal Runtime should be interpreted as:

• an open-source framework;
• a public reference implementation;
• an open governance specification;
• a prompt framework;
• a reusable blueprint for recreating SEAL;
• a model architecture;
• or a public implementation standard.

Refusal Infrastructure is the architecture category.

SEAL Legal Runtime is Thinking OS™’s proprietary legal implementation of that architecture.



Public discussion of the category does not grant implementation rights to the proprietary runtime.