Problem
When organizations hear about DPU (Decision Proof Unit) and hash-chain-based audit trails, a natural question arises: "How does this actually work in our daily operations?"
Theory is necessary, but adoption decisions are driven by concrete scenarios. This document presents three real-world use cases from distinct domains — rehabilitation, welfare, and local commerce — to demonstrate how Cronozen's architecture solves practical problems.
Each use case follows the same structure:
- Before: How the current system handles the scenario
- After: How Cronozen's DPU + Policy Engine transforms the process
- Audit Scenario: What happens when an auditor questions this decision months later
Use Case 1: Rehabilitation Center — Voucher Session Management
Scenario
A child developmental rehabilitation center manages 120 children's therapy sessions. Each child receives government-funded voucher sessions (typically 8-16 sessions/month). The center must track session completion, therapist assignments, and voucher consumption accurately.
Before (Legacy System)
| Task | Current Method | Problem |
|---|---|---|
| Session recording | Paper logbook + Excel entry | Transcription errors, delayed entry |
| Voucher tracking | Manual count per child | Over-billing risk, underutilization |
| Therapist assignment | Whiteboard + verbal | No audit trail for changes |
| Schedule changes | Phone calls + manual update | Lost change reasons, no notification |
| Audit response | Pull paper files + reconstruct | Weeks of effort, incomplete records |
After (Cronozen)
Every therapy session generates a DPU:
Therapist completes session
│
▼
DPU automatically created:
├── 6W: Who(therapist Kim), What(speech therapy 40min),
│ When(2026-03-03 10:00), Where(Room 3),
│ Why(voucher KR-2026-V-4521), How(direct session)
├── Policy Snapshot: Current voucher rate + session duration rules
├── Evidence: Session notes, attendance confirmation
├── Hash Chain: Linked to previous session DPU
└── Governance Guards: All 5 passed → AUDIT_READY
When a schedule change occurs (e.g., therapist sick leave):
Emergency Schedule Agent triggered
├── AI generates 3 rearrangement candidates
├── DPU created with Evidence Level: PARTIAL
├── Guard 2 (Human Review): Required → Center director notified
├── Director approves Option B + Guardian consents
├── DPU transitions: PARTIAL → AUDIT_READY
└── Responsibility Graph: TherapistA(sick) → AI(suggestion) → Director(approval) → Guardian(consent)
Audit Scenario
Government auditor asks: "Was session KR-2026-S-8847 properly conducted?"
System instantly returns the complete DPU: session details, therapist credentials, voucher status at that time, policy version applied, and the entire approval chain. Audit resolved in minutes, not weeks.
Use Case 2: Welfare Center — Benefit Approval Process
Scenario
A welfare center processes 300+ benefit applications monthly. Applications involve income verification, eligibility checks against multiple criteria, and tiered approval workflows based on benefit amount.
Before (Legacy System)
| Task | Current Method | Problem |
|---|---|---|
| Application intake | Paper forms + data entry | Incomplete submissions, re-entry errors |
| Eligibility check | Manual criteria matching | Inconsistent application of rules |
| Approval workflow | Physical signature routing | Bottlenecks, lost documents |
| Policy changes | Email notification to staff | Delayed adoption, version confusion |
| Audit trail | "Approved" stamp + initials | No decision rationale, no policy version |
After (Cronozen)
AI-assisted processing with full DPU trail:
Application submitted
│
▼
AI Analysis (Auto Decision Engine)
├── Income verification: 94% confidence
├── Eligibility match: 8/8 criteria met
├── Benefit tier: Level 2 (monthly KRW 350,000)
├── Confidence Score: 91%
│
▼
Policy Engine
├── Active policy: Welfare-2026-Q1-v2
├── Amount threshold: < KRW 500,000 → single approval sufficient
├── Regional override: Busan region adds disability priority
├── Policy Snapshot: Frozen at this moment
│
▼
DPU Created
├── AI Mode: RECOMMENDATION
├── Risk Level: LOW
├── Guards: All passed
├── Evidence Level: AUDIT_READY
└── Responsibility Graph: Applicant → AI(analysis) → CaseWorker(review) → System(approval)
Audit Scenario
Inspector asks: "Why was applicant Park approved for Level 2 benefits when the income threshold changed in Q2?"
DPU shows: Policy Snapshot was Welfare-2026-Q1-v2 (pre-change). All 8 eligibility criteria were met under Q1 standards. The policy hash confirms the frozen version. Decision was legitimate at the time of approval, regardless of subsequent policy changes.
Use Case 3: Local Commerce — Coupon Settlement
Scenario
A local commerce activation program distributes digital coupons to stimulate neighborhood businesses. Merchants redeem coupons and submit settlement requests. The platform must verify coupon validity, prevent double-redemption, and provide settlement proof.
Before (Legacy System)
| Task | Current Method | Problem |
|---|---|---|
| Coupon distribution | Paper/SMS codes | Sharing, duplication risk |
| Redemption verification | Manual code entry + check | Human error, slow processing |
| Double-use prevention | Spreadsheet tracking | Race conditions, missed duplicates |
| Settlement | Monthly batch with bank transfer | Disputes, reconciliation overhead |
| Fraud detection | Manual spot checks | Late detection, minimal coverage |
After (Cronozen)
Coupon redeemed at merchant
│
▼
Real-time verification
├── Coupon validity: Active, within date range
├── Usage check: First use confirmed (no double-redemption)
├── Merchant eligibility: Registered and active
├── Transaction DPU created instantly
│
▼
Settlement batch (daily)
├── Aggregate DPUs for settlement period
├── Each transaction has hash-chained proof
├── Settlement amount auto-calculated
├── Policy: Coupon-2026-March-v1 snapshot preserved
└── Batch DPU: Links all individual transaction DPUs
Audit Scenario
Municipal auditor asks: "Verify that merchant Lee's March settlement of KRW 2,340,000 is accurate."
System returns: 47 individual transaction DPUs, each with coupon code, redemption timestamp, customer verification hash, and policy snapshot. The batch settlement DPU links all 47 and shows the calculation trail. Hash chain integrity: PASSED. Complete verification in seconds.
Result
Cross-Domain Impact
| Metric | Rehabilitation | Welfare | Commerce |
|---|---|---|---|
| Audit response time | Weeks → Minutes | Weeks → Minutes | Days → Seconds |
| Decision traceability | Partial → Complete | None → Complete | Partial → Complete |
| Policy compliance proof | Manual → Automatic | Manual → Automatic | Manual → Automatic |
| Fraud/error detection | Post-hoc → Real-time | Post-hoc → Real-time | Spot-check → Real-time |
The common thread across all three domains: DPU transforms audit from a reactive burden into a built-in guarantee. Proof is generated automatically as a natural byproduct of operations — not as additional paperwork.
Cronozen Living Technical Spec Series #1 System Architecture — Why AI governance needs a monorepo #2 DPU Engine Concept — Leaving proof with every decision #3 Proof Pipeline — 5-stage proof pipeline #4 Use Cases — Real-world applications ← Current document