Refusal Infrastructure at the Commit Layer

Control Objectives & Evaluation Criteria (2026 v1.0)

A public reference for evaluating pre-execution authority controls

in scoped high-risk workflows

Who this is for: technical evaluators, procurement teams, risk leaders, auditors, insurers, regulator-facing reviewers, and institutional teams evaluating consequential workflow controls.


Status: Public evaluation reference.


Scope: Evaluator-visible control objectives and evidence surfaces. This page is not a regulatory standard, implementation specification, security architecture, deployment guide, or substitute for legal, technical, or professional diligence.

Canonical Classification

Action Governance — the discipline

The Commit Layer — the control point before commitment

Refusal Infrastructure — the architecture being evaluated

Pre-execution authority gate — the control type operating at that point

SEAL Legal Runtime — Thinking OS™’s product applying this architecture to high-risk legal actions


These terms are related.

They are not interchangeable.

Why This Page Exists

A technical evaluator should not have to rely on category language alone.


The relevant question is not:


Does a vendor say it has governance?


The relevant questions are:


  • What exact consequential action is being governed?
  • Where does that action become binding?
  • Is the authority control actually in the path capable of causing that consequence?
  • What authority and context does the control evaluate?
  • What happens when required conditions are not satisfied?
  • Which workflows are governed and which remain explicitly out of scope?
  • What operating mode is active?
  • What reviewable evidence shows what the control actually decided?


This page provides a common evaluation structure for those questions.


It is intentionally focused on observable properties and evidence surfaces,

not non-public implementation mechanics.

Evaluation Posture Matters

A pre-execution authority control can be evaluated under more than one operating posture.


Those postures must not be confused.


Observe-Only Evaluation


In observe-only mode, the runtime evaluates the governed action and records what would have been approved, refused, or routed for supervision.


The production workflow remains nonblocking.


The evaluator should therefore distinguish:


  • the governance decision;
  • the runtime mode;
  • the final runtime outcome;
  • whether the governance outcome was binding;
  • whether execution was attempted;
  • what evidence was produced.


A governance refusal in observe-only mode is a real governance finding.


It is not a claim that the production action was blocked.


Controlled Enforcement


Under separately scoped controlled enforcement, the governed outcome can become authoritative for the wired execution path.


For that posture, the evaluator may ask whether the actual committing path can effectively complete without the required governed outcome.


Controlled enforcement requires separate workflow scope, authority mapping, signal-quality review, escalation and continuity review, technical diligence, and written agreement.


Observe-only tests the control without production blocking. Controlled enforcement makes the governed outcome authoritative for the agreed wired path.

The Eight Evaluation Domains

1. Commit-Point Identification


Evaluation objective


Determine what exact consequential action is governed and where that action becomes binding.


A credible evaluation should identify:


  • the governed action class;
  • the workflow in which it occurs;
  • the institutional consequence created by the action;
  • the point immediately before that consequence occurs.


Examples may include:


  • before a filing leaves the firm;
  • before an approval binds;
  • before money moves;
  • before a disclosure goes out;
  • before a destructive change completes;
  • before another consequential action commits the institution.


The evaluator should be able to answer:


Where is the exact point at which the institution can still say no?


And:


Is the authority control positioned before the path that actually causes the consequence?


“Before execution” is not enough as a claim.


The control must be evaluated relative to the path that actually binds the institution.


Evidence an evaluator may review


  • scoped workflow description;
  • defined governed action;
  • commit-point description;
  • evaluator-visible flow or control map;
  • documented action boundary.


Deep dive: Commit Layer Evaluation Guide →

2. Scope & Coverage


Evaluation objective


Determine which wired paths are governed and which remain explicitly outside scope.


Refusal Infrastructure does not imply universal control over every workflow or system in an environment.


A credible evaluation should make clear:


  • which workflow is in scope;
  • which governed action classes are covered;
  • which actors or roles are included;
  • which execution path is wired through the authority control;
  • which alternate or unwired paths remain outside the governed surface.


The evaluator should be able to answer:


What exactly is governed?


and:


What is not governed yet?


Coverage should be explicit rather than implied.


Scope rule


Only workflows wired through the governed path are in scope.


Additional coverage is created by deliberately bringing additional consequential paths under governance.


It is not created by making broader claims about the environment.


Evidence an evaluator may review


  • coverage statement or map;
  • scoped workflow inventory;
  • in-scope action classes;
  • declared out-of-scope paths;
  • pilot or deployment scope documentation.



3. Authority Inputs


Evaluation objective


Determine what trusted governance facts inform the authority decision and where those facts originate.


The authority control should not invent institutional facts merely to complete a decision.


Depending on the workflow, relevant signals may include:


  • actor identity;
  • trusted role or group;
  • attempted action;
  • matter, account, domain, jurisdiction, or workflow context;
  • authority or consent posture;
  • required evidence;
  • supervision requirements;
  • timing, deadline, or urgency where material.


Existing institution-controlled systems remain the sources of truth for those facts.


That may include identity, policy, matter, workflow, authority, evidence, or other systems appropriate to the scoped action.


The evaluator should be able to answer:


  1. What facts does the authority decision depend on?
  2. Which institution-controlled sources establish those facts?
  3. What happens when a required fact was not supplied?


Missing information should remain missing.


It should not be silently inferred, backfilled, or transformed into governance approval simply to complete the request.


Evidence an evaluator may review


  • minimum signal map;
  • request-shape examples;
  • authority/context fields represented in decision evidence;
  • declared/not-declared handling;
  • source-of-truth responsibility statement.

4. Governed Outcomes


Evaluation objective


Determine whether the control returns explicit governance outcomes rather than advisory warnings or ambiguous technical states.


For SEAL Legal Runtime, the governed authority outcomes are:


Approve

The scoped action satisfies the configured authority conditions.


Refuse

The scoped action does not satisfy the required authority conditions.


Supervise

The scoped action requires an authorized supervised path before it may proceed under an enforcement posture.


These are governance outcomes.


They should remain distinguishable from:


  • technical errors;
  • transport failures;
  • internal warnings;
  • logging labels;
  • downstream workflow status.


The evaluator should be able to answer:


What did governance actually decide?


That answer should remain visible even when the operating mode changes what happens downstream.


Supervision is not a silent bypass


Where a supervised or formal override path is supported, the evaluator should be able to distinguish:


  • the original governance outcome;
  • the authorized supervision or exception path;
  • the accountable actor;
  • the final governed result.


The institution remains responsible for its supervision workflow, reviewer selection, escalation, and professional judgment.

5. Unsafe Uncertainty


Evaluation objective


Determine whether missing, conflicting, invalid, or otherwise unsafe required governance context can become silent governance approval.


A credible Refusal Infrastructure implementation should not convert unresolved authority uncertainty into an implicit “yes.”


Examples may include:


  • missing trusted identity or role;
  • conflicting authority context;
  • missing required consent;
  • invalid or mismatched evidence;
  • unsupported workflow or action scope;
  • malformed required governance context;
  • unavailable information required for the governed decision.


The evaluator should ask:


When the runtime cannot safely establish the required authority conditions, what governance outcome is preserved?


Mode distinction


In observe-only mode:


a refusal can remain a reviewable nonbinding governance finding.


Under controlled enforcement:


the agreed failure posture may prevent effective completion or require an authorized supervised path.


“Fail closed” should therefore be interpreted carefully.


It means unsafe uncertainty does not become silent governance approval.


It does not mean every observe-only refusal production-blocks the action.


Evidence an evaluator may review


  • refusal scenarios;
  • missing/ambiguous context tests;
  • reason families;
  • runtime-mode indication;
  • governance-vs-runtime/binding interpretation.


6. Operating Posture


Evaluation objective


Determine whether the evaluator can clearly distinguish what governance decided from what the runtime actually did under the active operating mode.


For a serious evaluation, the following questions should be independently answerable where applicable:


  1. What did governance decide?
  2. What runtime mode was active?
  3. What was the final runtime outcome?
  4. Did the governance outcome bind the action?
  5. Was execution attempted?
  6. What evidence supports that interpretation?


This distinction is especially important in observe-only evaluation.


For example:


Governance may return Refuse while the final production path remains nonblocking because observe-only mode is active.


That is not a contradiction.


It is the expected separation between:


governance truth and enforcement posture.


The evaluator should reject artifacts or reports that collapse those two truths into one ambiguous status.


Evidence an evaluator may review


  • runtime mode;
  • governance decision;
  • final runtime outcome;
  • binding-effect field or equivalent evaluator-visible indication;
  • downstream/execution posture where supplied;
  • decision-alignment information where applicable.

7. Scope-Bounded Non-Bypassability


Evaluation objective


Determine whether, under controlled enforcement, the actual wired committing path can effectively complete without the required governed outcome.


Non-bypassability is a property of the scoped wired path.


It is not a claim of universal control.


For the governed execution path, an evaluator should be able to establish:


  1. the consequential action is clearly identified;
  2. the wired execution path is identifiable;
  3. the authority control is positioned before effective completion;
  4. the committing path depends on the required governed outcome under enforcement;
  5. alternate paths not wired through that boundary remain explicitly out of scope.


The relevant question is:


Can the thing capable of causing the consequence ignore the governed “no”?


If the answer is yes for the path being represented as controlled, then the non-bypassability claim has not been established for that path.


Observe-only limitation


Observe-only mode does not claim production non-bypassability.


It allows the institution to evaluate:


  • the authority decision;
  • the evidence surface;
  • signal quality;
  • refusal patterns;
  • supervised-review findings;
  • workflow fit


before deciding whether controlled enforcement should be activated.


Evidence an evaluator may review


  • governed-path description;
  • coverage map;
  • evaluator-visible decision behavior;
  • scoped downstream alignment;
  • controlled-enforcement evidence where actually in scope;
  • explicit limitations.


Deep dive: Commit Layer Evaluation Guide →


8. Decision Evidence


Evaluation objective


Determine whether the governed outcome produces reviewable, integrity-verifiable decision evidence sufficient to reconstruct what the control evaluated and returned.


A decision record should help a qualified evaluator understand, where applicable:


  • what governed action was attempted;
  • who or what attempted it;
  • what governance outcome was returned;
  • which authority or context anchors were relevant;
  • what policy or reason surface was represented;
  • what runtime or binding posture applied;
  • what stable decision or correlation reference remains;
  • whether the supported integrity review validates the record as presented.


The evidence surface should support later review without requiring disclosure of proprietary runtime logic.


What the artifact does not prove by itself


A decision artifact does not, by itself, establish:


  • that the institution’s policy was legally correct;
  • that the upstream identity or matter data was accurate;
  • that every workflow in the environment was governed;
  • that no unwired execution path existed;
  • that a refusal prevented financial loss;
  • that the runtime is production-ready for a particular buyer environment;
  • that the artifact is legal advice, regulatory approval, or a professional judgment.


Its narrower role is to preserve reviewable evidence of the governed decision.


Public implementation boundary


Thinking OS™ publicly describes evaluator-visible decision evidence and integrity properties.


It does not publish complete artifact schemas, cryptographic mechanisms, key-management design, storage architecture, or proprietary runtime internals.


Deep dive: Verifier Note →

How to Read the Evaluation as a Whole

A strong evaluation should not rely on one passing scenario.


It should examine the control across multiple dimensions:


  • ordinary approval;
  • refusal;
  • supervised-review requirement;
  • missing or conflicting authority context;
  • observe-only nonbinding findings;
  • coverage and out-of-scope paths;
  • decision evidence;
  • controlled-enforcement behavior only where that posture is actually in scope.


The objective is not to prove that the runtime solves every governance problem.


The objective is to determine whether a narrow control claim is real:


For this scoped action boundary, can the institution obtain an explicit governed authority decision before commitment, understand the operating posture, and review credible evidence of what the control did?

What This Evaluation Does Not Replace

This control-objectives reference does not replace:


  • security diligence;
  • architecture review;
  • penetration testing;
  • business-continuity review;
  • legal review;
  • professional-supervision review;
  • customer-specific integration review;
  • production-readiness validation;
  • SLA or support diligence;
  • independent assurance;
  • contractual allocation of responsibility.


A product can satisfy the control objectives described here and still require substantial buyer-specific diligence before production enforcement is appropriate.

Evaluator Routing Guide

Different questions deserve different evidence.



If your question is:

“Is the authority control actually in the path that binds?”

→ Read the Commit Layer Evaluation Guide

“What does ‘non-bypassable when wired’ actually mean?”

→ Read the Commit Layer Evaluation Guide

“What can the decision artifact legitimately prove?”

→ Read the Verifier Note

“What claims should I challenge the vendor on?”

→ Read Truth Tests — How to Evaluate SEAL

“How does this differ from IAM, GRC, and model guardrails?”

→ Read How SEAL Compares: IAM, Guardrails, and GRC

“How can a law firm evaluate this without disrupting legal work?”

→ Read How SEAL Evaluation Works

Evaluator Summary Checklist

A reviewer should be able to answer all of the following:


  • What exact consequential action is governed?
  • Where does that action become binding?
  • What workflows or execution paths are actually in scope?
  • What paths remain explicitly out of scope?
  • What trusted authority and context inputs inform the decision?
  • What governed outcome did the control return?
  • What happens when required governance context cannot be safely established?
  • What operating mode was active?
  • Did the governance outcome bind?
  • Was execution attempted, where that fact is relevant and supplied?
  • Under controlled enforcement, can the wired committing path effectively complete without the required governed outcome?
  • What reviewable decision evidence exists?
  • What does that evidence prove?
  • What does it explicitly not prove?
  • Which remaining questions require controlled technical, security, legal, or operational diligence?

If those questions cannot be answered clearly, the control claim is not yet sufficiently legible for serious evaluation.


Common Evaluator Questions

Q1. Can we begin without

disrupting legal work?

A. Yes.


SEAL’s first law-firm evaluation is observe-only.



The runtime records what would have been approved, refused, or routed for supervision while production remains nonblocking.


Controlled enforcement is considered only later under separate written scope.

Q2. Does Refusal Infrastructure replace IAM, GRC, model governance, or matter systems?

A. No.



Those systems remain important upstream controls and sources of institutional truth.


Refusal Infrastructure owns a different downstream control point:


whether a particular consequential action may proceed under the required authority conditions before commitment.

Q3. What information does the authority control require?

A. Only the structured governance signals required for the scoped decision.


Depending on the workflow, that may include actor, trusted role/group, workflow, action, matter/context identifiers, authority or consent posture, required evidence, supervision, and deadline or urgency.


The exact minimum signal set is workflow-dependent.

Q4. What does fail-closed mean?

A. It means unresolved required governance uncertainty does not become silent governance approval.


In observe-only mode, that can appear as a nonbinding refusal finding.


Under controlled enforcement, the separately agreed failure posture may prevent effective completion or require an authorized supervised path.

Q5. What does “non-bypassable when wired” mean?

A. It is a scope-bounded enforcement property.


For the specific execution path wired through the authority control under controlled enforcement, the action should not effectively complete through that path without the required governed outcome.



It does not imply control over unwired paths elsewhere in the environment.

Q6. What can decision evidence prove?

A. Decision evidence can help a qualified evaluator reconstruct what governed action was evaluated, what outcome was returned, what relevant authority/context was represented, and what runtime or binding posture applied where supplied.


It does not by itself prove legal correctness, universal workflow coverage, upstream source accuracy, or buyer-specific production readiness.


For a deeper treatment, see the Verifier Note.

Final Evaluation Principle

Refusal Infrastructure should not be evaluated by how much proprietary implementation detail a vendor is willing to expose.


It should be evaluated through bounded, evaluator-visible claims.


For a scoped high-risk action, the evaluator should be able to determine:


what was governed, where the authority decision sat, what outcome was returned, whether that outcome bound under the active posture, what paths remained outside scope, and what reviewable evidence supports the claim.


That is the purpose of this reference.

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

Action Governance is the discipline.
The Commit Layer is the control point before commitment.
Refusal Infrastructure is the architecture.
Pre-execution authority gate is the control type.
SEAL Legal Runtime is the product applying this architecture to high-risk legal actions.


For public evaluation only. Not legal advice, a regulatory standard, an implementation specification, or proof of buyer-specific production readiness.