Problem
In the public service sector, too many systems cannot answer the question: "Was this judgment legitimate?"
When welfare centers approve vouchers, rehabilitation centers record therapy sessions, and local commerce platforms settle coupons — every decision should be auditable. But reality differs.
Structural flaws in most current systems:
| Problem | Consequence |
|---|---|
| Judgment rationale scattered across logs | Cannot reconstruct during audit |
| Policy versions not recorded | Cannot verify against "standards at that time" |
| Approval flows are unstructured | Unclear accountability |
| No data integrity guarantee | Post-hoc tampering undetectable |
| AI involvement is opaque | Cannot respond to regulations |
Audit response is always post-hoc. When incidents occur, dev teams dig through logs, query databases, and rely on staff memory. This process takes weeks, and the results have low reliability.
Cronozen solves this problem at the design level. A structure where proof is created simultaneously with every decision — that is the Proof Pipeline.
Solution
The Proof Pipeline is a proof generation engine composed of a 5-stage pipeline.
The core principle is simple: A decision and its proof must be created simultaneously. Not as a post-hoc report, but within the very transaction where the judgment occurs, the proof is created alongside it.
This pipeline outputs DPUs (Decision Proof Units). A single DPU is a complete proof package for one decision. Who judged, under what policy, on what basis, and if AI was involved — how it was involved — all contained in a single sealed unit.
Before / After Comparison:
| Aspect | Before (Legacy System) | After (Proof Pipeline) |
|---|---|---|
| Audit response time | Weeks (log reconstruction) | Instant (DPU query) |
| Policy tracking | "It was probably this policy" | Policy Snapshot reproduces exact standards |
| Accountability | Unclear (log interpretation needed) | Explicit via Responsibility Graph |
| Data integrity | No guarantee | SHA-256 Hash Chain |
| AI governance | None | AI Mode + Risk Threshold integration |
| Evidence grading | Binary (exists or not) | DRAFT → PARTIAL → AUDIT_READY 3-stage progression |
Architecture
The Proof Pipeline's 5 stages execute sequentially. If any stage fails, DPU creation is rejected, and the failure itself is recorded.
┌─────────────────────────────────────────────────────────────┐
│ PROOF PIPELINE │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Stage 1 │──▶│ Stage 2 │──▶│ Stage 3 │ │
│ │ Evidence │ │ Policy │ │ Guard │ │
│ │Collection│ │ Matching │ │Validation│ │
│ └──────────┘ └──────────┘ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Stage 4 │──▶│ Stage 5 │ │
│ │Hash Chain│ │ Audit │ │
│ │ Sealing │ │ Ready │ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
↑ │
Input Sources DPU Output
(User / AI / (Sealed, Chained,
Voice / System) Audit-Ready)
Each Stage's Role:
Stage 1 — Evidence Collection
All proofs begin with evidence. This stage collects and structures data from various sources.
- Input sources: Direct user input, system events, AI analysis results, voice input
- 6W Extraction: Automatically extracts Who, What, When, Where, Why, How from all evidence
- Data sensitivity classification: Automatic 4-level classification — PUBLIC, INTERNAL, PII, PHI
- Voice input: Audio hash (SHA-256) generation → STT transcription → Transcription confidence score recording
6W extraction is the core design of the Proof Pipeline. Whether from welfare case records, pharmacy exchange transactions, or coupon usage logs — everything is normalized into the same 6W structure. This enables cross-domain integrated auditing.
6W Structure (Common to all DPUs)
┌───────────────────────────────────────┐
│ Who │ Actor name, role, ID │
│ What │ Action, description, category│
│ When │ Timestamp, timezone │
│ Where │ Location, system, context │
│ Why │ Reason, policy ref, evidence │
│ How │ Method, tools, AI involvement│
└───────────────────────────────────────┘
Stage 2 — Policy Matching
Once evidence is collected, it's matched against active domain policies.
- Policy scope: Global → Country → Region → Center hierarchy
- Temporal validity: Verified by validFrom and validUntil time ranges
- Condition-based actions: Automatically triggers follow-up actions when policy conditions are met
- Conflict resolution: Multiple policies in the same domain resolved by priority
- Performance optimization: Policy rules are indexed for fast matching
The important point is that a snapshot of the matched policy is created at this stage. Policies may change over time, but the Policy Snapshot recorded in the DPU permanently preserves "the policy at the time of judgment." Even if an audit comes 6 months later, the exact policy version applied can be precisely reproduced.
Stage 3 — Guard Validation (5 Governance Guards)
This is the gateway of the Proof Pipeline. Five independent Guards perform sequential validation, and if any one fails, DPU creation is rejected.
5 Governance Guards
═══════════════════════════════════════════════════════
Guard 1: Evidence Level Guard
┌─────────────────────────────────────────────────┐
│ DRAFT ──────▶ PARTIAL ──────▶ AUDIT_READY │
│ (internal ref) (partial proof) (audit-ready) │
│ │
│ Checks minimum Evidence Level required by policy│
│ PHI data → AUDIT_READY enforced │
└─────────────────────────────────────────────────┘
Guard 2: Human Review Guard
┌─────────────────────────────────────────────────┐
│ Enforces human review for sensitive judgments │
│ - Reviewer ID + role + approval time required │
│ - Approver role must match policy-defined role │
└─────────────────────────────────────────────────┘
Guard 3: Risk Threshold Guard
┌─────────────────────────────────────────────────┐
│ LOW ─── MEDIUM ─── HIGH ─── CRITICAL │
│ │
│ HIGH/CRITICAL → AI AUTONOMOUS mode blocked │
│ CRITICAL → Minimum 2-person approval enforced │
└─────────────────────────────────────────────────┘
Guard 4: Dual Approval Guard
┌─────────────────────────────────────────────────┐
│ When policy requires 2+ approvals: │
│ - First approver + second approver both required│
│ - Self-approval prevention │
└─────────────────────────────────────────────────┘
Guard 5: Compliance Logging Guard
┌─────────────────────────────────────────────────┐
│ Auto-records all Guard failures to audit log │
│ - Failure reason, attempter, time, policy code │
│ - DENIED logs cannot be deleted │
│ → Attempts to bypass Guards become evidence │
└─────────────────────────────────────────────────┘
═══════════════════════════════════════════════════════
Why the Guard structure matters: The mere existence of a DPU proves all 5 Guards were passed. An auditor can confirm policy compliance just by the DPU's existence.
Stage 4 — Hash Chain Sealing
Evidence that passes all Guards is linked to the Hash Chain and sealed.
Hash Chain Structure (Independent chain per domain)
════════════════════════════════════════════
[Genesis DPU] [DPU #1] [DPU #2]
┌───────────┐ ┌───────────┐ ┌───────────┐
│ index: 0 │ │ index: 1 │ │ index: 2 │
│ prevHash: │ │ prevHash: │ │ prevHash: │
│ GENESIS │◀───│ hash_0 │◀───│ hash_1 │
│ chainHash:│ │ chainHash:│ │ chainHash:│
│ hash_0 │ │ hash_1 │ │ hash_2 │
│ policy: │ │ policy: │ │ policy: │
│ snapshot_0│ │ snapshot_1│ │ snapshot_2│
└───────────┘ └───────────┘ └───────────┘
chainHash = SHA-256(content + previousHash + timestamp)
════════════════════════════════════════════
Key operations at this stage:
- computeChainHash(): Combines current DPU content + previous DPU hash + timestamp to generate a new hash. Applies SHA-256 after JSON key sorting (canonicalization) to ensure consistent hashing regardless of data ordering
- generatePolicyHash(): Separately hashes a snapshot including the matched policy's version, settings, and sensitivity level
- createDPUEnvelope(): Packages all evidence, policy snapshots, and hash chain links into a single tamper-proof unit
Hash Chains operate independently per domain. The welfare domain chain and the pharmacy domain chain don't interfere with each other, while Serializable transactions prevent chain index collisions during concurrent access.
Stage 5 — Audit-Ready Output
The sealed DPU is stored in an immediately auditable state.
- Audit status tracking: PENDING → PASSED / DENIED / FLAGGED
- Responsibility Graph: Tracks the roles and accountability scope of all actors (human + AI) involved in the decision as a graph
- verifyHashChain(): Verifies integrity of the entire chain at any time — if any record is tampered with, all subsequent hashes become inconsistent
- verifyDPUWithOriginalPolicy(): Compares the Policy Snapshot recorded in the DPU with the current policy to re-verify compliance by "the standards of that time"
Flow
The complete flow of a single judgment being converted to a DPU in a real operational environment:
User Action (or System Event)
│
▼
┌─────────────────────────────────────────┐
│ Stage 1: Evidence Collection │
│ │
│ Input source check │
│ ├─ Text input → Direct structuring │
│ ├─ System event → Auto capture │
│ └─ Voice input → SHA-256 hashing │
│ → STT transcription │
│ → Confidence scoring │
│ │
│ 6W Extraction │
│ ├─ Manual │
│ ├─ LLM auto-extraction │
│ └─ Voice-based extraction │
│ │
│ DataSensitivityLevel classification │
│ └─ PUBLIC / INTERNAL / PII / PHI │
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Stage 2: Policy Matching │
│ │
│ Search active policies by domain │
│ ├─ effective_from ≤ NOW │
│ ├─ effective_until ≥ NOW (or null) │
│ └─ Sort by priority │
│ │
│ Policy Snapshot creation │
│ └─ Policy code, version, settings, │
│ sensitivity → SHA-256 hash │
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Stage 3: Guard Validation │
│ (5 Governance Guards - see above) │
│ All must PASS → proceed │
│ Any FAIL → reject + log │
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Stage 4: Hash Chain Sealing │
│ │
│ Previous chain hash retrieval │
│ Canonicalization │
│ computeChainHash() │
│ createDPUEnvelope() │
│ Seal (immutable from this point) │
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Stage 5: Audit-Ready Output │
│ │
│ Save to decision_proof_units table │
│ Record AI decision log │
│ Record audit log │
│ Build Responsibility Graph │
│ Status: AUDIT_READY │
└─────────────────────────────────────────┘
Example
Domain 1: Rehabilitation Center — Therapy Session Proof
A therapist records a 40-minute session for child patient Kim (age 7). The Proof Pipeline automatically extracts 6W, matches the voucher policy, passes all 5 Guards, seals the hash chain, and outputs an AUDIT_READY DPU — all within the same transaction as the session record.
Domain 2: Welfare Center — Benefits Approval Proof
An AI system recommends approving a welfare benefit application with 92% confidence. The Policy Snapshot captures the current benefit eligibility criteria, the Guard Validation checks evidence completeness, risk level, and policy compliance. Human review is triggered because the amount exceeds the center's auto-approval threshold.
Domain 3: Local Commerce — Coupon Settlement Proof
A merchant submits a batch of 47 coupon redemptions for settlement. Each transaction generates a DPU with the coupon policy snapshot, verification of coupon validity period, and the settlement amount calculation trail. The hash chain links all 47 DPUs sequentially for batch audit capability.
Result
The Proof Pipeline transforms audit response from a reactive scramble into a proactive guarantee. The key design achievement: proof is a byproduct of operations, not an additional burden.
Every judgment, every transaction, every AI decision — automatically generates its own auditable proof. When the auditor asks "was this legitimate?", the answer is already sealed, chained, and waiting.
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 ← Current document