ClearState — Decision Demo

ClearState — Pre-execution decision layer

ClearState — a pre-execution decision authorization layer.

Click any scenario below to see it in action. Each shows a real decision, the rulebook that must be true, the binary output — and, when authorized, an audit-ready record that is retrievable and deterministically reproducible.

▷ Quick tour (≈3 minutes)

First time here? Take a guided walk-through. Each tour shows Step 1 decisionability, the binary output, and — for AI / financial scenarios — how an LLM would handle the same question.

Choose scenario:

Filter by sector:

Each scenario shows: the situation · the input · the rulebook · the binary output · and, when ALLOWED, the audit-ready Authorization Record. Switch to Production above to see how this works at scale.

Input

→

ClearState

→

🔒 Execution

"ClearState stops decisions that cannot be defended — before they are taken." Each decision gets a clear yes/no answer, and a record you can retrieve and reproduce later.

Decision

More context — buyer, trigger, personal risk, moment of pain, consequence today

1 · Input — what we have

The facts currently available

What ClearState does not do

ClearState does not figure out who is responsible for a decision. It requires that responsibility is already defined. If no one with the right authority is named for this decision, ClearState stops it — before any rule or policy is even checked.

Rulebook — what must be true to authorize this decision

Defined in advance · cited to source

Step 1 · Decisionability Can this decision be taken at all?

Not yet evaluated — input completeness, mandate presence, responsibility assignment will be checked first.

Step 2 · Rules & mandate evaluated only if Step 1 passes

3 · Output — binary result

Binding reason · referenced documents · authorization record

Click Evaluate to check the input against the rulebook.

3-week pilot — on your historical decisions

Concrete output: what would have been allowed, what would have been blocked, and why — across your actual historical decision data. Ready-to-review Authorization Records on real cases. €7 500–15 000.

What you keep after the pilot. The RIL specification of your own policies, mandates and rules — in deterministic, machine-readable form — is yours permanently. Historical EDGABLE / NOT EDGABLE outputs and Authorization Records are yours as documented analysis.

What ClearState retains. The decision authorization pipeline — the runtime that evaluates new decisions deterministically against the specification — is licensed by ClearState. Continued deterministic authorization on future decisions requires a license.

No lock-in. No surprise. If you choose not to license, you walk away with full ownership of the specification and the historical analysis. The pipeline does not continue running.

Why this matters — personal exposure

At scale — what the production view shows

Sample stream illustrating the pattern at scale. Click any row to expand the record inline.

⌕ Retrieve a decision by ID

Paste any Decision ID, Transaction ID or Subscription ID from an Authorization Record. The same record is retrieved by reference — what an auditor, regulator, LP or appellant would do five years from now.

This sample stream illustrates how ClearState's authorization layer would look at scale. Each row is a decision evaluated against its rulebook, with a clear yes/no answer — and, when authorized, a signed record (Authorization Record) you can retrieve later. Click any row to expand the record inline.

Show decisions for:

Top binding reasons — why decisions were blocked

Decision volume by type

Live decision stream

Time	Decision ID	Type	Subject	Outcome

Glossary

ClearState's internal terminology. Used here for technical audiences (architects, engineers, patent counsel). External communication uses Plain mode — switch via the Plain / Technical toggle in the top bar.

SP1Substitution Point 1

The patent-protected pre-processing layer that prepares an incoming decision request for evaluation. Normalizes inputs, applies referential substitutions, and enforces input completeness before passing the decision to REM.Patent: SE 2515467-5 covers the SP1 substitution mechanic specifically.

REMRisk & Exposure Mapping

The decisionability gate. Determines whether a decision can be taken at all — independent of whether it should be taken. Verifies input completeness, mandate presence, and explicit responsibility assignment.Plain mode label: "Decisionability". REM fails → STOP. No rules are evaluated.

RILRisk Instruction Layer

The rule and mandate evaluation layer. Forces every rule to be specified in binary, machine-readable form before activation. If a rule cannot be specified binarily, that is the customer's responsibility to resolve before RIL can run.The forcing function is itself a commercial value proposition — most policies are not yet binary.

CRSLClear Risk State Layer

The verified, signed authorization gate. The only layer that authorizes execution. Output is binary: EDGABLE or NOT EDGABLE. Produces the Authorization Record.Plain mode label: "Output". Nothing executes downstream without CRSL authorization.

Decisionability

Whether a decision can be taken at all — regardless of whether it should be taken. Decisionability fails if input is incomplete, mandate is absent, or responsibility is undefined. Distinct from "permissibility", which is a Step 2 / RIL question.

Mandate

A defined, versioned, owned authorization to make a category of decision within stated bounds. A mandate has: a name, a version, a locked-at timestamp, an owner (function and role), an approver, and an approval date. ClearState binds every rule to a mandate at evaluation time.

Accountability chain

The retrievable record of who owns each rule, mandate, and policy that applied to a decision. Includes mandate owner and approver, policy owner and approver, active delegation level, and the named decision-maker at the moment of decision. The chain is what distinguishes ClearState from a rule engine.

Deterministic replay

The property that re-evaluating the same input against the same rulebook version always produces the same output, with the same input hash. Replay produces a new event (new ID, new timestamp) but identical decision content. Distinct from LLM behavior where same input may produce different outputs across runs or model versions.

Binding reason

When a decision is NOT ALLOWED, ClearState surfaces exactly one reason — the highest-priority failed condition. Distinct from rule-engine error reports that list all failures. The single binding reason makes the block defensible and actionable.

Authorization Record

The signed, retrievable record of an ALLOWED decision. Contains decision ID, timestamp, outcome, authority, rulebook version, input hash, and accountability chain. Retrievable by reference for the retention period (typically 7 years). The block event for NOT ALLOWED is also retrievable.

EDGABLE / NOT EDGABLE

The internal binary outcome from CRSL. EDGABLE = decision authorized to execute. NOT EDGABLE = decision not authorized; execution is blocked.Plain mode labels: "ALLOWED" / "NOT ALLOWED".

Pilot

A 3-week engagement on the customer's historical decision data. Produces: (1) the RIL specification of the customer's own policies, (2) Authorization Records on historical decisions, (3) breakdown of allowed / blocked / why. Pilot fee €7 500–15 000, with 50% credited toward license if the customer continues.