Problem
When organizations adopt AI, decision speed increases. But they can no longer answer one fundamental question:
"Why was this decision made, on what basis, and under whose approval?"
Consider an automated voucher approval system. AI analyzes applications, scores them, and issues approvals. Six months later, an audit questions a past approval. But the policy applied at that time has already been changed three times, the person in charge has left the company, and the AI model has been updated. Reconstructing the decision rationale is practically impossible.
The structural limitations of most current systems are as follows:
| Problem | Current State | Real Impact |
|---|---|---|
| No decision rationale | Only "approved" logged | Cannot justify during audit |
| No policy version tracking | Only current policy exists | Cannot verify past decision legality |
| AI judgment is a black box | Only model output stored | Context of confidence scores lost |
| Unclear accountability | Only approver ID logged | Decision chain untraceable |
| No integrity guarantee | Regular DB records | Post-hoc tampering undetectable |
This problem isn't solved by simply logging more. The decision itself must be designed as a provable unit.
Solution
Cronozen designed the concept of DPU (Decision Proof Unit).
A DPU is a proof structure that bundles input data, applied policies, AI judgment rationale, approval workflows, and hash chains into a single sealed unit for each decision. It captures all context at the moment a decision is made, enabling verification of the decision's legitimacy under identical conditions at any future point.
The three core design principles of DPU:
1. Point-in-Time Capture
A DPU stores a snapshot of the policy in effect at the moment the decision is made. Even if policies change later, you can always verify whether that decision was legitimate by the standards of that time.
2. Hash Chain Integrity
Every DPU references the hash of the previous DPU, forming a sequential chain. If any record in the chain is tampered with, all subsequent hashes become inconsistent and detection is immediate. It borrows blockchain principles while eliminating blockchain's cost and complexity.
3. Governance Guards
A series of validation steps must be passed before a DPU can be created. Evidence level, human review, risk thresholds, dual approval — all policy-defined conditions must be met before the DPU is sealed.
┌─────────────────────────────────────────────────┐
│ DPU (Decision Proof Unit) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │ Input │ │ AI │ │ Policy │ │
│ │ Evidence │ │ Output │ │ Snapshot v2.3 │ │
│ └──────────┘ └──────────┘ └───────────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │ Approval │ │ Risk │ │ Chain Hash │ │
│ │ Chain │ │ Level │ │ Link │ │
│ └──────────┘ └──────────┘ └───────────────┘ │
│ │
│ ═══════════════════════════════════════════════ │
│ Sealed Envelope | Hash: a7f3... | Immutable │
└─────────────────────────────────────────────────┘
Architecture
The DPU system consists of three independent layers. Each layer has clear responsibility boundaries and is designed to operate without external dependencies.
Layer Structure
┌─────────────────────────────────────────────────────────┐
│ DPU Pro Layer │
│ │
│ Governance Guards · Compliance Engine · Audit │
│ Policy enforcement · Regulatory status · Accountability│
├─────────────────────────────────────────────────────────┤
│ DPU Core Layer │
│ │
│ Hash Chain · Canonicalization · Envelope · Policy │
│ Pure computation · Zero dependencies · Deterministic │
├─────────────────────────────────────────────────────────┤
│ Connector Layer │
│ │
│ Storage Adapter Interface → Prisma / PostgreSQL │
│ Database agnostic · Implementation swappable │
└─────────────────────────────────────────────────────────┘
DPU Core — Pure Computation Engine
DPU Core is a pure computation engine with zero external dependencies. This design choice is intentional.
- Hash Chain Operations: Each DPU takes the hash of the previous DPU as input, forming a sequential chain. Chain integrity can be independently verified at any point.
- Canonicalization: Ensures that identical data always produces the same hash regardless of system, time, or environment. Prevents hash mismatches caused by JSON key ordering, whitespace, or encoding differences.
- Policy Hash: Hashes the policy document itself to guarantee integrity. Comparing the policy hash at creation time with the current policy hash immediately reveals whether the policy has changed.
- Envelope Generation: Packages all components into a single sealed unit. After sealing, any content modification is immediately revealed by hash mismatch.
The reason Core has no external dependencies is clear: proof reliability depends on computational determinism. The same input must produce the same output anywhere, anytime, and external library version changes must not alter hash results.
DPU Pro — Governance Layer
DPU Pro is the layer that enforces organizational governance rules on top of Core. Five Governance Guards execute sequentially, and if any one fails, the DPU is not created.
Request ──→ Guard 1 ──→ Guard 2 ──→ Guard 3 ──→ Guard 4 ──→ Guard 5 ──→ DPU Sealed
│ │ │ │ │
Evidence Human Risk Dual Additional
Level Review Threshold Approval Verification
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
On fail On fail On fail On fail On fail
Halt Halt Halt Halt Halt
Guard 1 — Evidence Level Verification
Evaluates evidence completeness in three levels:
| Level | Meaning | DPU Creation Allowed |
|---|---|---|
DRAFT |
Draft level, key evidence missing | Limited per policy |
PARTIAL |
Some evidence secured, supplementation needed | Conditional per policy |
AUDIT_READY |
Complete evidence for audit response | Allowed |
Guard 2 — Human Review Verification
When policy mandates human review of AI judgments, it verifies review completion. Required review level varies by AI operating mode (AIMode):
| AI Operating Mode | Description | Human Review Requirement |
|---|---|---|
RECOMMENDATION |
AI presents recommendations only | Low |
ANALYSIS / CLASSIFICATION |
AI performs analysis/classification | Medium |
DRAFT_GENERATION |
AI drafts documents | Medium |
PREDICTION |
AI performs predictions | High |
AUTONOMOUS |
AI decides autonomously | Highest — human approval mandatory |
Guard 3 — Risk Threshold Verification
Verifies that the decision's risk level falls within the policy-permitted threshold. Classified into four levels: LOW, MEDIUM, HIGH, CRITICAL, evaluated in combination with data sensitivity levels (PUBLIC, INTERNAL, PII, PHI).
Guard 4 — Dual Approval Verification
Verifies that two or more approvers have signed off on high-risk decisions. Structurally prevents risks from single-approver judgment errors.
Connector Layer — Storage Abstraction
DPU Core defines an interface called DPUStorageAdapter. Implementing this interface is the Connector's responsibility. Currently, a Prisma + PostgreSQL implementation is provided, and Core has no knowledge of Prisma's existence.
DPU Core Connector Database
│ │ │
│ save(envelope) │ │
│ ─────────────────────→ │ │
│ │ INSERT INTO │
│ │ decision_proof_units │
│ │ ──────────────────→ │
│ │ │
│ verify(id) │ │
│ ─────────────────────→ │ │
│ │ SELECT + Hash Check │
│ │ ──────────────────→ │
│ result │ record │
│ ←───────────────────── │ ←────────────────── │
Thanks to this design, even if PostgreSQL is replaced with MongoDB, DynamoDB, or a file system, not a single line of Core or Pro layer code needs to change.
Flow
We trace the complete flow from a single application to DPU sealing in an automated voucher approval system.
[1] Application Received
│
▼
[2] Auto Decision Engine Analysis
├── Document completeness score calculation
├── Applicant credibility evaluation
├── Policy compliance verification
└── Aggregate confidence score calculation
│
▼
[3] Branching Decision
├── Confidence ≥ 90% ──→ Auto-approval path
└── Confidence < 90% ──→ Human review escalation
│
▼
[4] Policy Snapshot Creation
└── Capture and freeze current policy
│
▼
[5] Governance Guards Sequential Execution
├── [G1] Evidence Level: AUDIT_READY confirmed ── PASS
├── [G2] Human Review: Policy check for auto-approval ── PASS
├── [G3] Risk Threshold: LOW confirmed ── PASS
├── [G4] Dual Approval: Exempt (low risk) ── PASS
└── [G5] Additional Verification ── PASS
│
▼
[6] DPU Envelope Creation
├── Integrate input data + AI judgment + policy snapshot
├── Reference previous DPU hash for chain linking
├── Apply canonicalization then generate hash
└── Seal
│
▼
[7] Storage and Linking
├── Record in decision_proof_units table
├── Record AI judgment history in ai_decision_logs
├── Record audit log in decision_proof_audit_logs
└── Link dpu_id to source entity
The key point in this flow is Step [4] — Policy Snapshot. When an audit questions this decision 3 months later, the system verifies legitimacy against the snapshotted policy from that time, not the current policy.
Example
Consider a scenario where an internal audit examines a voucher case auto-approved 6 months ago.
Audit Question: "Was this approval compliant with the policy at that time?"
Legacy System Response:
Auditor: "Please explain approval case KR-2025-08-1847 from August 2025."
Staff: "Let me check the logs... It just says 'approved'."
Auditor: "What policy was applied at the time?"
Staff: "We have the current policy, but the one from that time... it's difficult to verify."
Auditor: "What was the AI's basis for judgment?"
Staff: "We cannot determine that."
→ Result: Audit finding, corrective action required
DPU-Based System Response:
Auditor: "Please explain approval case KR-2025-08-1847 from August 2025."
System Query Result:
┌─ DPU #1847 ──────────────────────────────────────────┐
│ │
│ Decision: Voucher Auto-Approval │
│ Date: 2025-08-14 09:23:17 KST │
│ │
│ ■ AI Judgment │
│ Mode: RECOMMENDATION │
│ Confidence: 94.2% │
│ Factors: Doc completeness 97% · Applicant trust 91%│
│ · Policy compliance 95% │
│ │
│ ■ Applied Policy │
│ Policy v2.1 (hash: b4e2...) │
│ Current policy: v3.0 (hash: d8a1...) │
│ Policy change detected: Yes — but v2.1 compliant │
│ │
│ ■ Governance Guards Results │
│ Evidence Level: AUDIT_READY ✓ │
│ Human Review: Exempt (RECOMMENDATION mode) ✓ │
│ Risk: LOW ✓ │
│ Dual Approval: Exempt (low risk) ✓ │
│ │
│ ■ Hash Chain │
│ Previous: DPU #1846 (hash: 7c9f...) │
│ Current: a7f3e2... │
│ Chain Integrity: PASSED │
│ │
│ ■ Audit Status │
│ Compliance Status: PASSED │
│ Audit Status: PENDING → Ready for review │
│ │
│ ■ Responsibility Graph │
│ Application → Auto Decision Engine → Guard Check → │
│ DPU Sealed → System Auto-Approval │
│ │
└───────────────────────────────────────────────────────┘
→ Result: Instantly proven compliant under Policy v2.1. Audit passed.
Result
Summary of the changes DPU Engine brings to organizations:
Quantitative Impact
| Metric | Before DPU | After DPU |
|---|---|---|
| Audit response time | Days to weeks | Instant query |
| Past decision re-verification | Practically impossible | Auto-verification via policy snapshot |
| Data tampering detection | Impossible | Immediate via hash chain |
| AI judgment traceability | Only result values exist | Full recording of mode, confidence, factors |
| Accountability tracking | Only approver ID logged | Full chain tracked via Responsibility Graph |
Design Principles Realized
Provability — Every decision is sealed with its context at creation time. A technically complete answer to "why was this decision made" is always available.
Tamper Evidence — Hash-chained DPUs report inconsistencies across the entire chain if even a single record is tampered with. It doesn't prevent tampering — it makes tampering impossible to hide.
Temporal Independence — Even if policies change, staff leave, or AI models are updated, past decisions' legitimacy is independently verified via the snapshot from that time.
Storage Agnosticism — Core proof logic is not tied to any specific database. Starting with PostgreSQL, it flexibly adapts to organizational infrastructure changes.
Roadmap
DPU Engine is currently at v0.1.0. Core concept implementation is complete, and the next phase plans include a real-time chain verification dashboard, multi-tenant policy management, and external auditor integration API.
DPU is not a log. It is a proof.
A log records "what happened." A DPU proves "why this decision was justified." This difference is what separates explanation from proof during an audit.
Cronozen Living Technical Spec Series #1 System Architecture — Why AI governance needs a monorepo #2 DPU Engine Concept — Leaving proof with every decision ← Current document