SNAPOS.ORGONLINE
|
FRAMEWORKDIP-CORE-1.0 · ACTIVE
|
GCCL v0.1DOI: 10.5281/zenodo.18362037
|
ORCID0009-0000-6493-4599
MANDATE INTEGRITYPROTOCOL ACTIVE
|
█[email protected]
ORCID0009-0000-6493-4599
ZENODODOI-registered publications
GCCL v0.1DOI-registered governance standard
IT-SCHNITTSTELLEGovernance audit · DE
UNITED CODING20+ years production delivery

Systems fail not when they break — but when they continue acting after their mandate has expired.

Framework
ACTIVE
DIP-CORE-1.0 · GCCL v0.1
Mandate Drift
DETECTABLE
DASR v0.5 · 30-day protocol
Failsafe Mode
FAIL-CLOSED
No authority → no execution
Publications
10
DOI-registered · Zenodo
GCCL v0.1
PUBLISHED
DOI: 10.5281/zenodo.18362037

Every dashboard was green. Every control was documented. And still — the system should not have been running.

You are not monitoring failure. You are missing illegitimacy.

SnapOS defines Decision Integrity: the control layer that verifies whether a system is still allowed to execute — not just whether it is executing correctly.

DCF
Decision Closure Framework
Authority · Assumptions · Evidence — must hold continuously
DIP
Decision Identity Protocol
Fail-closed. No mandate → no execution.
DASR
Decision Architecture Stability Review
30-day audit — drift magnitude, velocity, exposure
GCCL
General Capability & Compliance Levels
DOI: 10.5281/zenodo.18362037
SSE
Semantic Stability Engineering
Scientific foundation of Decision Integrity
See Applications → Documented Cases Framework Stack Run Decision Audit ↗ Can you prove continuity after change?
What current systems do not detect

Your system can be correct and still be illegitimate.

If your system makes correct decisions, follows all rules, passes every audit — and still produces the wrong outcome — then you don't have a failure problem.

You have a legitimacy problem. And there is currently no control layer for that.

That is what SnapOS is.

Execution continues after mandate expiration
The authorization that justified the system's operation has changed — but the system has not been notified. Execution continues.
No existing standard detects this
Models optimizing on invalid assumptions
The model's objective remains unchanged. The conditions that justified that objective have silently failed.
Invisible to monitoring
Authority expanding without re-legitimation
Scope drifts beyond what was authorized. No code change. No alarm. No re-validation required.
No re-legitimation trigger exists
Systems remaining correct under broken conditions
Every output is technically correct. Every check passes. The mandate under which those outputs were authorized no longer holds.
That is the gap
The missing control layer

The point where your system
becomes illegible to governance.

Current systems verify correctness. SnapOS verifies whether execution is still legitimate. These are not the same question.
EXECUTION FLOW INPUT DECISION ENGINE / MODEL OUTPUT CURRENT SYSTEM STATE Monitoring OK Compliance OK Performance OK Legitimacy UNKNOWN ← no standard addresses this SNAPOS CONTROL LAYER DASR drift magnitude · velocity · exposure DIP decision identity validation DCF closure · legitimacy check → EXECUTION ALLOWED → EXECUTION STOPPED mandate still valid? mandate expired? WITHOUT SNAPOS System runs Drift increases No signal No stop WITH SNAPOS System runs Drift detected Legitimacy evaluated Execution controlled

Current systems verify correctness. SnapOS verifies whether execution is still legitimate. Without this layer, a system can be fully compliant and still be operating under an expired mandate.

Documented gap — not a claim

Neither NIST AI RMF nor ISO/IEC 42001 requires re-authorization for continued operation.

This is not a theoretical observation. It is the finding of a formal gap analysis — text-derivable obligations only, no implicit interpretations.

The term "authorization" does not appear in the NIST AI RMF Core. ISO/IEC 42001 has no explicit stop obligation in requirement text. Neither standard defines a control that asks: is the system still allowed to operate under its current conditions?

Read the gap analysis (DOI: 10.5281/zenodo.19382604) →
NIST AI RMF 1.0
Monitoring and reviewPRESENT
Risk managementPRESENT
Decommissioning mechanismPRESENT
Mandate re-authorization requirementABSENT
Authorization terminology in CoreABSENT
ISO/IEC 42001:2023
Risk and impact assessmentsPRESENT
Change control mechanismsPRESENT
Performance monitoringPRESENT
Explicit stop / suspend obligationABSENT
Mandate continuity controlABSENT
Failsafe Architecture
Decision Invariants
Witness System
Failsafe
When legitimacy cannot be verified, execution must stop. This is the difference between monitoring failure and preventing invalid execution.
Fail-closed by default — ambiguity triggers halt, not continuation
No silent continuation — every execution requires a valid mandate
Authority rebinding — when conditions change, re-legitimation is explicit
Controlled failure — stopping is governance working as designed
Invariants
Five conditions that must hold for a decision to remain the same decision. Without invariants, drift cannot be distinguished from legitimate evolution.
Identity — defining attributes must remain intact
Continuity — legitimacy persists during execution, not only at approval
Non-equivalence — changed conditions are not the original conditions
Drift independence — drift is detectable independently of output correctness
Witnessability — claims must be anchored in verifiable evidence
Witnesses
No governance claim without a witness. Witnesses distinguish audit from documentation theater — making governance objects verifiable rather than narrative.
Foundational — field definitions, DOI-registered specifications
Normative — formal protocol documents and invariant specifications
Empirical — documented cases with traceable evidence chains
Operational — DriftBench evaluations and DASR audit records
Documented failure modes — mandate drift in production All case analyses →
Stop Execution
Knight Capital
2012 · Automated trading
$440M. 45 minutes. Everything worked. That was the problem. Correct execution under an expired mandate. Every dashboard green.
What DI would have done:flagged mandate mismatch · required re-validation · stopped continuation
Analysis →
Execution Misaligned
Zillow Offers
2021 · Automated acquisition
The model kept optimizing. The assumptions had already died. Silent drift before visible collapse. No signal.
What DI would have done:detected assumption failure · triggered DASR review · halted expansion
Analysis →
Authority Drift
COMPAS
Ongoing · Risk scoring
No code break. No alarm. Authority drifted silently. Scope expanded beyond mandate without re-legitimation.
What DI would have done:enforced scope invariants · required authority rebinding
Analysis →
Mandate Expired
Klarna AI Support
2024–2025 · Customer service AI
Rule compliance = 1. Mandate integrity = 0. Operational, logged, audited. Executing under an expired mandate without re-validation.
What DI would have done:detected mandate expiry · required re-legitimation before continuation
Analysis →
Built from production reality

This is not theory. This is what happens when systems must not drift.

Decision Integrity did not emerge from a research paper. It emerged from repeated failure patterns in real production systems — systems that remained operational after their governing conditions had already changed.

We don't monitor systems. We decide whether they are allowed to continue.

Trading and financial systems
Execution-critical deployments where mandate drift produces irreversible financial consequences
High-risk AI under EU AI Act
Article 9 and 17 compliance: mandate continuity, human oversight, re-legitimation triggers
Customer decision engines
Credit, fraud, customer service AI where operational scope must remain within authorized boundaries
Regulated enterprise environments
Governance-critical infrastructures where stopping execution is a first-class requirement

Assess decision legitimacy in your system.

DriftBench runs a sealed evaluation: policy binding, witness tuples, scope gates, fail-closed behavior. Against your own model endpoint. No data leaves your environment.

Run a Decision Audit ↗