dreichor.io
≡

Most systems can decide.Very few can justify that they were allowed to.

dreichor is a deterministic governance layer that decides whether a system is allowed to act — without deciding what it should do.

Autonomy is easy to build. Governance under uncertainty is not.
dreichor exists to make permission, trust, and responsibility explicit.

  • Produces permission judgments: allow / warn / restrict / block
  • Generates deterministic, replayable explanations
  • Never controls execution
  • Never optimizes outcomes
Check whether your system can explain why it was allowed to act →
This page does not optimize conversion. It optimizes clarity.

Make it about your system

Imagine a system that can place trades, approve claims, trigger alerts, suspend users, or escalate incidents — based on incomplete or delayed information.

  • Who decides when this system is allowed to act under uncertainty?
  • What explicitly prevents action when confidence is insufficient?
  • Can the decision be reconstructed after an incident — deterministically?
  • Where does responsibility live when something goes wrong?
If these questions cannot be answered from the system itself, governance is implicit — and therefore unverifiable.

What dreichor is

  • a decision governance framework
  • deterministic and replayable
  • audit-grade by construction
  • domain-agnostic
  • read-only by design
Practically: dreichor observes decision artifacts and produces deterministic permission judgments with complete, replayable evidence.

What dreichor is not

  • ❌It is not an AI system.
  • ❌It is not a rules engine.
  • ❌It is not a decision optimizer.
  • ❌It is not an execution controller.
  • ❌It is not a kill switch.
These negations are explicit because governance is often misclassified as intelligence or control.

What dreichor actually produces

  • Governance events (facts, not interpretation)
  • Gate results (pass / warn / fail)
  • Aggregated governance decisions
  • Explicit trust state transitions
  • Deterministic explanations (WHY)
  • Full decision traces (WHAT)
  • Replayable proof artifacts
dreichor produces evidence, not actions.

Why governance exists

Autonomy fails at boundaries: uncertainty, partial observability, and conflicting incentives.

Most failures are not logic errors, but missing constraints on when a system is allowed to act.

Trust is usually assumed implicitly instead of earned explicitly.

Trust is not a parameter. Trust is an audit-ready state with explicit transition rules.

Observation without control

dreichor never stops systems, never corrects decisions, and never intervenes in execution.
  • Governance evaluates permission, not behavior
  • Enforcement is the responsibility of the implementing system
  • Responsibility remains where it belongs: with the operator
This separation minimizes liability transfer while maximizing accountability.
If governance must be provable, the core must be deterministic.

CHOR: RAGE → NOISE → MEATSPACE

Read the public architecture document →

RAGE

intent

Pure, deterministic evaluation. No I/O, no clocks, no randomness.

NOISE

controlled deviation

Latency, slippage, partial fills. Still not reality.

MEATSPACE

the external world

Humans, networks, markets. Not deterministic.

Key rule
RAGE, NOISE, and MEATSPACE are strictly separated.
Governance exists outside CHOR and never modifies it.

How governance works

  1. Gates emit local signals (pass / warn / fail)
  2. Signals are aggregated deterministically
  3. Escalation rules define allowed trust transitions
  4. Default is NO CHANGE
  5. No implicit promotion, ever
Time passing is not evidence.

Replay is not debugging. Replay is proof.

  • Same inputs → identical outputs
  • Governance decisions are reproducible
  • Auditors verify behavior, not intent
If it cannot be replayed, it cannot be trusted.

Does your system have explicit governance?

A deterministic 3-question check. No scoring. No profiling. No storage.

Open the wizard →

Public documentation

All architectural guarantees are documented publicly. There is no hidden behavior.

GitHub repository (public)Documentation index (public)

Contact

Contact for evaluation or licensing.

Email is for contact only. No newsletters. No tracking. No marketing automation.