In Part 1, I argued that convenience tends to eat security. In Part 2, I showed why point-wise safety breaks once time and irreversibility enter the system.
This final post is intentionally practical.
No benchmarks. No alignment claims. Just a small, deterministic gate you can run before an irreversible action.
The problem this gate addresses
Most failures don’t come from a single bad output. They come from executing too early.
Deployments, payments, permission grants, public releases — once executed, uncertainty collapses into reality.
This gate does one thing only: it forces an explicit outcome before execution.
PASS — proceed
DELAY — preserve uncertainty, gather more signals
BLOCK — do not execute
What makes this different
The gate is designed to be:
Deterministic …
In Part 1, I argued that convenience tends to eat security. In Part 2, I showed why point-wise safety breaks once time and irreversibility enter the system.
This final post is intentionally practical.
No benchmarks. No alignment claims. Just a small, deterministic gate you can run before an irreversible action.
The problem this gate addresses
Most failures don’t come from a single bad output. They come from executing too early.
Deployments, payments, permission grants, public releases — once executed, uncertainty collapses into reality.
This gate does one thing only: it forces an explicit outcome before execution.
PASS — proceed
DELAY — preserve uncertainty, gather more signals
BLOCK — do not execute
What makes this different
The gate is designed to be:
Deterministic — same inputs, same outcome
Order-robust — reordering checks may affect cost or latency, but should not flip safe → unsafe
Evidence-preserving — uncertainty is not hidden, it is logged
Delay is treated as a first-class outcome, not a fallback.
30-second demo (CLI)
Clone the repo and run one command: git clone https://github.com/shin4141/decision-os-paper cd decision-os-paper python cli.py examples/decision_request_delay.json
You’ll see a structured verdict like: { "verdict": "DELAY", "reason": "High impact with unresolved uncertainty", "evidence": ["impact=high", "confidence=low"], "next_action": "human_review" }
Change the input scenario and re-run. The behavior is deterministic.
Why this matters
This gate does not predict the future. It does not try to be smarter than the system it protects.
It simply ensures that irreversible actions are never taken while uncertainty is still unresolved.
Safety here is not a moment. It is a trajectory.
Open question
If reordering safety checks can turn a safe outcome into an unsafe one, is the system actually safe — or just lucky?
What invariants should hold before we allow irreversible execution?