ClearState
Architecture

ClearState sits between a proposed decision and its execution.

ClearState determines whether execution is allowed before it happens — and produces a record of why.

What ClearState produces

Each decision is captured as a retrievable record — at the moment it was made.

The record shows what was evaluated, who had authority, and why the decision was allowed or blocked.

Each tab below shows a real decision instance from a different segment — same record structure, different operational context.

Authorization Record
Customs deferment release
#CUSTOMS-REL-2026-05-15-0847
NOT ALLOWED Treasury authorization required before release.
Decision-maker
Customs Broker (delegate)
Operating under delegation §4.2 · Axus Ltd
Decision time
2026-05-15 · 08:47:13 CET
Rulebook version
customs-2026-04
Inputs evaluated
Declaration value
€148,200
Importer EORI
Verified
Importer status
Active · Standard risk
Guarantee utilisation
92% (threshold 85%)
Sanctions screening
Clear
Applied condition
Guarantee utilisation exceeds Treasury-approved threshold. Release requires Treasury authorization before declaration submission.
Operational consequence
  • Declaration held before submission to customs
  • Guarantee breach avoided
  • Escalation routed to Treasury Operations
  • Importer notified of pending authorization
Authorization Record
Cross-border shipment release
#ECOM-REL-2026-05-15-1432
ALLOWED Order released for fulfilment under DDP terms.
Decision-maker
Booking Operator
Operating under delegation §2.1 · Tellus Logistics
Decision time
2026-05-15 · 14:32:08 CET
Rulebook version
ecom-2026-05
Inputs evaluated
Order value
€2,840
Merchant credit limit
€15,000 (€11,200 available)
Destination
DE · DDP terms
Restricted goods
None flagged
Sanctions screening
Clear
Operator delegation
Within authority
Applied rule
Order within merchant credit limit. Destination permitted under DDP terms. No restricted classification. Operator authority confirmed at decision time.
Operational consequence
  • Shipment released for fulfilment
  • Duty and VAT calculation locked at decision time
  • Merchant credit position updated
  • Record retrievable for post-clearance audit
Authorization Record
Pre-trade order authorization
#AIFM-PRE-2026-05-15-1018
NOT ALLOWED Concentration limit would be breached on settlement.
Decision-maker
Portfolio Manager
Acting under Conducting Officer oversight · AIFMD II
Decision time
2026-05-15 · 10:18:47 CET
Rulebook version
aifm-mandate-2026-q2
Inputs evaluated
Fund
Nordic Credit Opportunities II
Proposed position
€4.2M · Brevik Industrier AB
Current issuer exposure
€18.6M
Mandate limit (single issuer)
€20M
Look-through concentration
21.4% (limit 20%)
Sanctions screening
Clear
Applied condition
Look-through concentration would exceed 20% mandate limit after settlement. Conducting Officer authorization required, or trade must be reduced to €2.8M.
Operational consequence
  • Order held before execution
  • Exposure breach prevented at trade time
  • Escalation routed to Conducting Officer
  • Mandate state preserved on record

Records are produced at decision time, not reconstructed afterwards. The records above illustrate the structure — actual records are versioned and preserved at runtime.

Where it fits

Before execution. After intention.

Transaction / payment
Shipment / release request
Credit / underwriting decision
Portfolio / treasury instruction
→
Pre-execution ClearState
→
ALLOWED — execute
NOT ALLOWED — blocked

ClearState does not replace execution systems. It authorizes — or blocks — before they run. ERP, core banking, customs, payments — these receive decisions that have already been authorized.

Most operational systems start after a decision has already been made. They execute, record, or audit — but they do not authorize.

ClearState fills the gap that exists between decision and execution. It is not a replacement for downstream systems. Other systems assume the authorization question has already been answered. ClearState is the layer that answers it.

Rules engines apply rules. Workflow systems route decisions. Audit systems record what happened. None of them determine, before execution, whether the conditions for execution are met.

That is what ClearState does.

Operational source systemsERP · TMS · Core banking · Payments
Decision proposed
Pre-execution authorizationClearState
ALLOWED / NOT ALLOWED + record
Execution systemsCustoms · Payments · Release · Trade
The decision record

Every outcome is captured at the moment of decision.

The record exists at the moment the authorization is issued — with the named authority, the versioned rulebook, and the rule that determined the outcome.

{
  "decision_id": "CS-20260512T091432Z-4X7R",
  "outcome": "ALLOWED",
  "rulebook": "release-policy-v3.2",
  "authority": "Operations Manager (T2)",
  "blocking_rule": null,
  "timestamp": "2026-05-12T09:14:32.081Z"
}
outcome

Binary. ALLOWED or NOT ALLOWED. The same input against the same rulebook produces the same answer — every time.

rulebook

The versioned rulebook active at decision time. Locked at that moment — the record references the exact version that was applied.

authority

The named role whose mandate authorized the decision. Not a system identifier — a named authority in your governance structure.

blocking_rule

Null when ALLOWED. When NOT ALLOWED: the exact rule that blocked execution and what must change to proceed.

How this differs

Most systems start after the decision has been made.

Existing categories each solve part of the problem. None of them authorize execution before it happens — and none of them identify when the rule, authority, or escalation path does not exist.

Capability Audit tools Rules engines AI copilots Workflow / BPM ClearState
Applies rules before execution ✗✓partialpartial ✓
Validates authority before execution ✗✗✗✗ ✓
Stops execution when conditions are not met ✗partial✗partial ✓
Produces a retrievable decision record partial✗✗✗ ✓
Same input produces same outcome — every time ✗partial✗✗ ✓
Identifies when the rule, authority, or escalation path does not exist ✗✗✗✗ ✓
The category boundary

Rules engines assume the rule, the authority, and the escalation path already exist.

ClearState also identifies when they don't. When ownership is unclear, mandate is undefined, or no valid escalation path exists, the system stops before execution and makes the gap explicit. The output is not "the rule was broken" — it is "no one is named to make this decision under these conditions, and here is what would need to be defined."

That is where rules engines, BPM tools, and AI governance platforms cannot follow. They assume the governance is there. ClearState identifies when it isn't.

System properties

What the system guarantees.

Deterministic

Same input. Same rulebook. Same answer.

ClearState applies rules, not probabilities. Given identical input and the same rulebook version, the outcome is always identical. This is a system guarantee, not a design preference.

Versioned

The rulebook is locked at decision time.

Every decision record references the exact version of the rulebook that was active when the decision was made. Changes to the rulebook do not affect historical records.

Attributed

Every decision has a named authority.

The record names the role or individual whose mandate authorized the decision. Not a system log — a named authority in your governance structure, on record at decision time.

Retrievable

The record exists when you need it.

Decisions are retrievable for the full retention period. Pulling a specific decision under audit is one query — not a reconstruction exercise involving emails and meeting minutes.

See evaluation → Regulatory frameworks →