Problem
Korea's social service industry — child developmental rehabilitation, welfare benefits, education centers, health management — still operates on fragmented legacy systems.
| Reality | Consequence |
|---|---|
| Each center adopts separate solutions | Data silos, redundant investment |
| Manual records + spreadsheet management | Audit trail impossible, compliance risk |
| AI adoption attempts | Failure to build trust due to lack of decision rationale |
| Voucher/policy changes | Manual updates, errors, revenue leakage |
The core problem isn't simply "digital transformation." Who verifies the decisions made by AI, how, and why — no architecture existed to answer this question.
The difference between existing approaches and Cronozen:
| Existing Center Management Solutions | Cronozen | |
|---|---|---|
| Architecture | Single-tenant, single-domain | Multi-tenant, multi-domain, 7 verticals |
| AI Decision-Making | Black-box or unsupported | DPU-based evidence chain + 5-layer governance |
| Policy Enforcement | Manual updates | Policy Engine auto-application (4-tier scope) |
| Audit Response | Post-hoc log collection | Real-time hash chain, Audit-Ready state management |
| Data Protection | Basic encryption | 4-level sensitivity classification + consent management |
Solution
Cronozen is a full-stack platform with the Decision Proof Unit (DPU) as its core primitive. For every AI decision, data change, and policy application, it generates cryptographically verifiable evidence units and chains them via hash links to provide tamper-proof audit trails.
Three design principles:
1. Provable Decisions When AI proposes "modify this child's therapy schedule," the rationale, confidence level, risk assessment, and approval path are sealed in a single DPU envelope. Evidence levels are tracked from DRAFT to AUDIT_READY.
2. One Backend, Infinite Context Rehabilitation centers, welfare agencies, education centers, and health management facilities operate on the same infrastructure with their own domains, workspaces, and policies. One codebase, with contexts completely isolated per tenant.
3. Policy as Runtime National, regional, and center-level policies are automatically applied at runtime. When voucher criteria change, the policy engine calculates the impact scope and applies changes immediately via conditional triggers.
Architecture
Overall System Structure
┌─────────────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
│ │
│ withslow.com slowpace.co.kr cronozen.com [+ more] │
│ │ │ │ │ │
│ └───────────┬────┴────────────────┴───────┬───────┘ │
│ │ Domain Router │ │
│ ▼ ▼ │
├─────────────────────────────────────────────────────────────────┤
│ EDGE MIDDLEWARE │
│ JWT Auth · RBAC · Tenant ID · Rate Limit │
├─────────────────────────────────────────────────────────────────┤
│ │
│ APPLICATION LAYER │
│ (Next.js 14 + TypeScript) │
│ │
│ ┌──────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────┐ │
│ │ API │ │ AI System │ │ Policy │ │ Agent │ │
│ │ Routes │ │ │ │ Engine │ │ Orchest.│ │
│ │ │ │ Multi- │ │ │ │ │ │
│ │ REST + │ │ Provider │ │ 4-Scope │ │ 3 Agent │ │
│ │ Server │ │ RAG + NL→SQL │ │ Resolution │ │ Types │ │
│ │ Actions │ │ 6W Extract. │ │ Temporal │ │ │ │
│ └────┬─────┘ └──────┬───────┘ └──────┬──────┘ └────┬────┘ │
│ │ │ │ │ │
│ └───────────┬───┴─────────────────┴───────┬───────┘ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DPU ENGINE (Decision Proof Unit) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────┐ │ │
│ │ │ dpu-core │ │ dpu-pro │ │ dpu-connector │ │ │
│ │ │ │ │ │ │ -prisma │ │ │
│ │ │ Hash Chain │ │ 5 Govern. │ │ │ │ │
│ │ │ Canon. │ │ Guards │ │ DB Adapter │ │ │
│ │ │ Envelope │ │ Compliance │ │ │ │ │
│ │ │ Storage I/F │ │ Resp. Graph │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
├──────────────────────────────┼──────────────────────────────────┤
│ DATA LAYER │
│ │
│ ┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ PostgreSQL │ │ pgvector │ │ Knowledge Base │ │
│ │ 315 Models │ │ Embeddings │ │ RAG Store │ │
│ │ Prisma ORM │ │ Similarity │ │ │ │
│ │ │ │ Search │ │ │ │
│ └──────────────────┘ └──────────────┘ └──────────────────┘ │
│ │
│ Security: 4-Level Sensitivity · Consent Mgmt · Audit │
└─────────────────────────────────────────────────────────────────┘
Layer-by-Layer Details
1. Client Layer — Multi-Domain Routing
Multiple domains converge into a single Next.js application. Edge Middleware analyzes the request's Host header to identify the tenant and injects the corresponding tenant configuration (branding, feature flags, policy scope).
Each domain operates like an independent service, but in reality, it branches from the same codebase through Modular Tenant Config. Adding a new vertical requires no separate server deployment.
2. Application Layer — 7 Verticals, One Runtime
Currently supported 7 verticals:
| Code | Vertical | Description |
|---|---|---|
| Rehab | Child Developmental Rehabilitation | Voucher-based therapy session management |
| Welfare | Welfare Benefits | Benefit application, processing, settlement |
| Edu | Education Centers | Enrollment, curriculum, attendance management |
| Health | Health Management | Health data tracking and analysis |
| Market | Local Commerce | Coupons, promotions, local economy integration |
| Conference | Conferences | Events, seminars, participant management |
| Interior | Interior Design | Space design and construction management |
Each vertical uses a Center as its basic isolation unit. Centers have workspaces where all data, permissions, and policies are scoped.
3. AI System — Multi-Provider + RAG
Not locked into a single AI vendor. OpenAI, Claude, Gemini, and Ollama (local) are selectively used based on context, and each provider's response passes through the same DPU pipeline.
Natural language query ──→ 6W Extraction ──→ NL→SQL ──→ Data Query
│ (Who, What, │
│ When, Where, ▼
│ Why, How) pgvector RAG
│ Context Enhancement
▼ │
Voice Input ──→ Voice Processing ────────┘
│
▼
AI Decision Generation
│
▼
DPU Envelope Sealing
The Auto Decision Engine automatically executes decisions with 90%+ confidence. However, "automatic" doesn't mean "unverified." All automatic decisions are recorded in DPUs and must pass Governance Guards.
4. Agent Orchestrator — 3 Agent Types
| Agent | Role | Trigger Condition |
|---|---|---|
| Morning Routine | Daily schedule optimization, prep notifications | Auto-triggered before daily operations |
| Voucher Renewal | Voucher expiry detection, renewal guidance | Conditional trigger on approaching expiry |
| Emergency Schedule | Emergency schedule changes, substitute therapist assignment | On cancellation/change events |
Agents make independent judgments, but all actions pass through DPUs. This design guarantees both agent autonomy and auditability simultaneously.
5. Policy Engine — 4-Tier Scope Resolution
Policies are defined at 4 tiers. On conflict, Priority-Based Resolution applies:
┌─────────────────────────────────────┐
│ Global │ ← Lowest priority
│ ┌─────────────────────────────────┐│
│ │ Country ││
│ │ ┌─────────────────────────────┐││
│ │ │ Region │││
│ │ │ ┌─────────────────────────┐│││
│ │ │ │ Center ││││ ← Highest priority
│ │ │ └─────────────────────────┘│││
│ │ └─────────────────────────────┘││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘
Key attributes:
- Temporal Validity: Every policy has a time validity range. "March 2026 voucher price change" automatically activates at that point.
- Condition-Based Triggers: Conditional policies like "terminate rehab voucher eligibility when a child exceeds 18 years of age" are evaluated at runtime.
- Conflict Resolution: When center policies conflict with regional policies, priority scores determine which policy applies. This resolution process itself is recorded in the DPU.
Flow
We trace the entire architecture's workflow through a scenario where AI automatically adjusts a therapy schedule at a child developmental rehabilitation center.
Time: 8:30 AM, Therapist A reports sick leave
[1] Event Triggered
Emergency Schedule Agent activated
│
▼
[2] AI Analysis
├─ Query today's session list for the therapist (NL→SQL)
├─ Query each child's therapy history + remaining voucher count (RAG)
├─ Search for available substitute therapists (6W: Who, When, Where)
└─ Generate 3 schedule rearrangement candidates
│
▼
[3] DPU Envelope Created
├─ Evidence Level: PARTIAL (AI suggestion, unapproved)
├─ AI Mode: SUGGESTION
├─ Risk Level: MEDIUM (impacts child therapy continuity)
└─ Linked to hash chain (references previous DPU hash)
│
▼
[4] Governance Guards Passed
├─ [Guard 1] Evidence Level Check → PARTIAL confirmed
├─ [Guard 2] Human Review Required → Yes (MEDIUM or above)
├─ [Guard 3] Risk Threshold → MEDIUM, auto-execution blocked
├─ [Guard 4] Dual Approval → Center director + guardian consent required
└─ [Guard 5] Policy Compliance → Remaining voucher check passed
│
▼
[5] Human Review
Center director notified → Selects 1 of candidates → Guardian consent received
│
▼
[6] DPU State Transition
Evidence Level: PARTIAL → AUDIT_READY
Audit Status: APPROVED
Responsibility Graph: TherapistA(sick)→AI(suggestion)→Director(approval)→Guardian(consent)
│
▼
[7] Execution + Recording
Schedule change applied → Voucher deducted → Notifications sent
Entire process sealed via hash chain
Key observations from this flow:
- AI made the suggestion, but execution authority remains with humans
- Every step is recorded in the DPU, enabling full decision path reconstruction during post-audit
- The Responsibility Graph clearly establishes accountability
- The Policy Engine validates voucher regulations in real-time
Example
What Multi-Tenant Isolation Actually Means
Comparing two centers operating on the same Cronozen infrastructure:
┌──────────────────────┐ ┌──────────────────────┐
│ Seoul A Rehab Center │ │ Busan B Welfare Ctr │
│ Vertical: Rehab │ │ Vertical: Welfare │
│ Domain: withslow.com│ │ Domain: slowpace.co.kr│
├──────────────────────┤ ├──────────────────────┤
│ Policy Scope: │ │ Policy Scope: │
│ Global │ │ Global │
│ └─ Country: KR │ │ └─ Country: KR │
│ └─ Region: Seoul │ │ └─ Region: Busan │
│ └─ Center: A │ │ └─ Center: B │
├──────────────────────┤ ├──────────────────────┤
│ Data: Fully isolated │ │ Data: Fully isolated │
│ AI Models: Shared │ │ AI Models: Shared │
│ DPU Chain: Independent│ │ DPU Chain: Independent│
│ Voucher Policy: Seoul│ │ Benefits Policy:Busan│
└──────────────────────┘ └──────────────────────┘
│ │
└────────── Shared ──────────┘
│
┌──────────────────┐
│ Shared Infra │
│ - DPU Engine │
│ - AI Providers │
│ - Policy Engine │
│ - PostgreSQL │
│ (315 Models) │
└──────────────────┘
Both centers share infrastructure but have completely isolated contexts. Center A's therapy records leaking to Center B is architecturally impossible. Meanwhile, common logic like the DPU Engine and Policy Engine is reused without duplication.
DPU Evidence Level Transitions
Every decision passes through these states sequentially:
DRAFT ──────→ PARTIAL ──────→ AUDIT_READY
│ │ │
│ │ │
▼ ▼ ▼
Draft created Partial evidence Audit response ready
AI suggestion Review in progress All Guards passed
Hash generated Owner assigned Hash chain sealed
This 3-stage transition isn't a simple state machine. At each transition point, a new hash is generated referencing the previous hash, forming a chain. If data is tampered with mid-chain, hash mismatch is detected immediately.
Result
What this architecture achieves:
Quantitative Metrics
| Metric | Value |
|---|---|
| Verticals supported by a single codebase | 7 |
| Data models (Prisma Schema) | 315 models / 8,749 lines |
| AI provider support | 4 (OpenAI, Claude, Gemini, Ollama) |
| DPU Governance Guards | 5-layer verification |
| Policy scope tiers | 4 levels (Global → Center) |
| Data sensitivity classification | 4 grades (PII, PHI, Internal, Public) |
| Auto-execution threshold | 90%+ confidence |
Architectural Guarantees
Auditability Every AI decision, policy application, and data change is recorded in hash-chained DPUs. During post-audit, "why this decision was made, by whom, and on what basis" can be fully reconstructed.
Scalability Adding a new vertical requires only tenant configuration + domain routing + policy scope definition. No separate server deployment or code branching needed.
Compliance Readiness The 4-level data sensitivity classification (PII, PHI, Internal, Public) and consent management system structurally address requirements from privacy laws, medical regulations, and social service legislation.
AI Trustworthiness 5-layer Governance Guards — Evidence Level verification, Human Review requirement, Risk Threshold evaluation, Dual Approval processing, Policy Compliance check — guarantee the balance between AI autonomy and human control.
Vendor Independence Multi-provider AI architecture and local execution (Ollama) support structurally mitigate risks from any single AI vendor's pricing changes or service disruptions.
Next Documents
This Architecture Overview is the first document in the Cronozen Living Technical Spec series. Subsequent documents cover deep-dive designs for each component:
- [02] DPU Deep Dive — Hash chain design, 3-Package architecture, Governance Guard details
- [03] AI Pipeline — Multi-provider strategy, RAG design, Auto Decision Engine
- [04] Policy Engine — Policy conflict resolution, Temporal Validity, conditional triggers
- [05] Multi-Tenant Design — Domain routing, workspace isolation, vertical expansion patterns
- [06] Data Architecture — 315-model design principles, sensitivity classification, consent management
- [07] Security Model — RBAC, JWT, Edge Middleware, audit logging
Cronozen builds a platform where you can ask "why?" about every decision AI makes. Every decision leaves a proof. Every proof tells a story.
blog.cronozen.com | Cronozen Living Technical Spec Copyright 2026 Cronozen. All rights reserved.