Commit Layer Evaluation Guide

How to Evaluate “Non-Bypassable When Wired” Without Exposing Non-Public Implementation Details

Public reference for evaluator-visible properties of Refusal Infrastructure

operating at the Commit Layer.

Reference Page — For auditors, insurers, regulators, procurement, and technical evaluators. Status: v1.0 public reference.

Scope: Commit Layer evaluation properties (not binding mechanisms).

Why This Page Exists

A Commit Layer is a control point.


Calling something a Commit Layer does not prove that the governed execution path actually depends on the authority decision made there.


For a serious evaluator, the questions are narrower:


  • Where is the actual institutional commit point?
  • Is the authority control in the path capable of causing that consequence?
  • What does “non-bypassable when wired” mean for that scoped path?
  • What happens when the authority conditions are not satisfied?
  • What reviewable evidence shows what the control decided?
  • Which paths are explicitly outside the governed surface?


This page defines the publicly testable control properties and evidence surfaces an evaluator can inspect without access to non-public runtime internals.

“Before execution” is not enough. The control must sit in the path that actually binds the institution.

Evaluation Posture vs. Controlled Enforcement

The same authority decision can be evaluated under different operating postures.


Observe-only evaluation

The runtime evaluates the governed action and records what would have been approved, refused, or routed for supervision, while production remains nonblocking.


Controlled enforcement

For a separately agreed wired path, the governed outcome becomes authoritative for whether the scoped action may complete.


Non-bypassability as an enforcement property applies to the controlled wired path. Observe-only evaluation tests the decision behavior and evidence without claiming production blocking.

When To Read This Page

If you’re evaluating a “Commit Layer” or pre-execution authority gate and you’re asking:


  • Where does enforcement bind (i.e., where can the system still refuse before an irreversible step)?
  • How is “non-bypassable when wired” defined—and what’s in scope vs out of scope?
  • What evidence exists per decision (Approve / Refuse / Supervised Override)?
  • Can artifacts be verified independently (without trusting vendor logs or narratives)?
  • Is this runtime enforcement or conceptual governance—and how would an audit / insurer review test it?


This page is the public reference for those questions. It defines the externally testable properties of the Commit Layer and the minimum evidence surface required to treat “non-bypassable” as a system property—not a slogan.


Scope note: We do not publish tenant-specific binding mechanisms, deployment configurations, or wiring details in public materials. Those are validated in controlled evaluations with qualified reviewers.

Definitions

Commit Layer

The control point immediately before a consequential action becomes binding.


The Commit Layer identifies where the authority decision must sit.

It is not the architecture itself.


Pre-Execution Authority Gate

The control type applied at the Commit Layer to determine whether a scoped action may proceed under the required authority conditions.


Refusal Infrastructure

The architecture that makes Action Governance operational at the Commit Layer.


Thinking OS™ implements this architecture in legal through SEAL Legal Runtime.


Non-Bypassable When Wired

A scope-bounded control property.


For a designated path operating under controlled enforcement, the action cannot effectively complete through that governed path without the required authority outcome.


This does not imply universal control over workflows or execution paths that have not been wired through the governed boundary.


Coverage Map

A high-level inventory showing which workflow/action paths are governed and which remain explicitly out of scope.

The Evaluator’s Checklist

External testable properties (what must be true)


Property 1 — An identifiable institutional commit boundary exists


An evaluator should be able to determine:

  • the scoped governed action;
  • the system or workflow that owns the consequential action;
  • the point immediately before that action becomes binding;
  • whether the authority control is actually positioned before that point.


Examples:

before the filing leaves
 before the approval binds
 before money moves
 before the disclosure goes out


For controlled enforcement, the evaluator should also be able to establish that the scoped path cannot effectively complete without the governed authority outcome.


Property 2 — Bounded Governed Outcome Semantics


For the scoped action, the authority control should return a defined governed outcome rather than an ambiguous advisory result.


In SEAL Legal Runtime, those outcomes are:

  • Approve
  • Refuse
  • Supervise / authorized supervised path


An evaluator should be able to distinguish:

  • a governed refusal from a technical error;
  • a supervised path from an informal bypass;
  • the baseline governance outcome from any later authorized exception.


Property 3 — Fail-Closed Governance Under Unsafe Uncertainty


Required governance context that cannot be safely established should not become an implicit governance approval.


An evaluator should be able to inspect cases involving, for example:

  • missing or conflicting identity/role;
  • missing authority or consent;
  • invalid or mismatched evidence;
  • unsupported scope;
  • malformed required context.


Mode distinction

In observe-only mode, the baseline governance refusal is preserved as a reviewable nonbinding finding.

In controlled enforcement, the agreed failure posture can prevent effective completion or require the configured supervised path.


Property 4 — Scope-Bounded Non-Bypassability


Non-bypassability is a property of the wired execution path, not a claim of universal control.


For a workflow under controlled enforcement, the evaluator should be able to establish:

  1. The governed path is identifiable.
  2. The actual consequential action is known.
  3. The authority control sits before effective completion of that action.
  4. The action cannot complete through that governed path without the required governed outcome.
  5. Alternate paths not wired through the control are explicitly out of scope.


Public evaluation should focus on observable behavior and scope, not the internal binding mechanism.


Evidence may include:

  • scoped action/workflow description;
  • coverage map;
  • governed request/outcome evidence;
  • downstream execution or no-execution evidence where applicable;
  • explicit out-of-scope disclosure.


Property 5 — Reviewable Decision Evidence


A governed outcome should produce a reviewable decision record sufficient for a qualified evaluator to understand what the control did.


Representative elements may include:

  • stable decision identity;
  • timestamp;
  • governed outcome;
  • relevant authority and context anchors;
  • policy or rule-basis linkage;
  • reason category;
  • trace/correlation reference;
  • integrity indicators.


The public evidence surface should be sufficient to connect a specific governed request to a specific governed outcome without exposing proprietary runtime logic.


In SEAL Legal Runtime, this is implemented through integrity-verifiable decision artifacts.


Property 6 — Independent Integrity Review


A qualified evaluator should have a repeatable way to review the integrity of the decision evidence without requiring access to internal runtime logic.


The evaluator should be able to confirm, using the supported verification procedure:

  • the decision/artifact identity;
  • the governed outcome;
  • relevant context anchors;
  • policy/version linkage where supplied;
  • integrity indicators;
  • consistency between the governed outcome and the reviewable evidence surface.


The goal is trust-minimized review, not exposed internals.



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

What Can Be Demonstrated

Public materials describe the control properties.

Evaluation demonstrates behavior.


In a vendor-controlled evaluator environment


Qualified reviewers may inspect scenarios demonstrating:

  • governed approval and refusal behavior;
  • supervised paths as distinct governed outcomes;
  • decision artifact generation;
  • scoped downstream alignment;
  • integrity review;
  • explicit governed vs out-of-scope coverage.


In the first law-firm design-partner review


The posture is observe-only.


The firm reviews what SEAL would have approved, refused, or routed without production blocking.


Any buyer-environment controlled enforcement claim requires separate scope, wiring review, continuity review, and written agreement.

Evidence Reviewers Can Request

A repeatable evaluation package may include:



  • representative redacted approval/refusal/supervised artifacts;
  • scoped workflow and action definition;
  • coverage map;
  • evaluator-visible outcome evidence;
  • integrity-verification note;
  • observe-only / enforcement posture statement;
  • explicit limitations and out-of-scope paths.


Relationship to Independent Assurance

This page is a public evaluation reference, not an independent audit, penetration test, certification, SOC 2 report, or production-readiness warranty.


Its purpose is to make the scoped control claims and evidence surfaces precise enough for qualified reviewers to test.


Independent security, operational, or assurance assessments should be treated as separate diligence work.

Supervised Paths Must Remain Governed

Supervision should not become a shadow bypass.


An evaluator should expect a supervised or override outcome to preserve enough evidence to determine:

  • the underlying or baseline outcome;
  • the authorized actor or authority path;
  • the reason for the supervised decision;
  • linkage between the original decision and the later outcome;
  • the final governed result.


The firm owns the supervision workflow.


SEAL records the governed decision and evidence; it does not create tickets, select supervisors, or operate the firm's workflow.

What Thinking OS™ Publishes

Publicly available


  • control model and taxonomy;
  • scoped evaluation properties;
  • governed vs out-of-scope coverage posture;
  • representative decision-record examples;
  • evaluator-visible proof;
  • integrity-review properties.


Non-public


  • tenant-specific implementation details;
  • exact execution wiring;
  • deployment configuration;
  • security mechanisms;
  • internal runtime logic;
  • policy application mechanics;
  • internal data structures and protocols.


Non-public matters may be addressed through controlled diligence where appropriate.

The Truth Test

A credible claim of “non-bypassable when wired” should let a qualified evaluator answer four questions:


  1. What exact consequential action is governed?
  2. Where is the control relative to the path that actually commits that action?
  3. Under controlled enforcement, can that wired path effectively complete without the required governed outcome?
  4. What reviewable evidence demonstrates the outcome and the declared scope?


Anything not wired through that governed path must remain explicitly out of scope.

The question is not whether a system contains governance logic.
The question is whether the thing capable of causing the consequence can ignore the governed “no."