Documentation Index
Fetch the complete documentation index at: https://docs.cronozen.com/llms.txt
Use this file to discover all available pages before exploring further.
Proof Pipeline
The Problem
AI agents and workflows execute decisions automatically — but those decisions are not recorded in a verifiable, auditable way.| Problem | Consequence |
|---|---|
| Decision rationale scattered across logs | Cannot reconstruct during audit |
| Approval flows unstructured | Unclear responsibility |
| No data integrity guarantee | Post-hoc tampering undetectable |
| AI involvement opaque | Cannot comply with regulations |
v1 Pipeline: Record → Approve → Seal → Export
The current Proof Pipeline consists of 4 stages:Stage 1 — Record
A decision event is created via API with structured metadata.- Who made the decision (actor)
- What action was taken
- Why (input context, AI reasoning)
- How (AI model, confidence, mode)
Stage 2 — Approve
Human approval seals the event. This is the governance checkpoint.RECORDED → SEALED.
Stage 3 — Hash Chain Sealing
The approved event is linked to the previous event’s hash, forming an immutable chain.- computeChainHash(): Content + previous hash + timestamp → SHA-256 (JSON key sorting canonicalization)
- Tamper detection: Modifying any event breaks all subsequent hashes — immediately detectable
- Per-domain chains: Each domain operates independently, concurrent access uses serializable transactions
Stage 4 — Export
Sealed evidence is exportable as a JSON-LD v2 audit document.- Structured decision record (actor, action, input, AI context)
- Approval chain with timestamps
- SHA-256 hash chain link and integrity status
- Evidence level (
DRAFT→DOCUMENTED→AUDIT_READY)
Real-World Example: Settlement Flow
What This Achieves
Audit response shifts from investigation to lookup. If a sealed event exists, the decision was recorded and approved. The hash chain guarantees no tampering occurred.| Guarantee | Mechanism |
|---|---|
| Integrity | SHA-256 Hash Chain — mid-chain tampering breaks all subsequent hashes |
| Accountability | Approval chain — who approved, when, why |
| Non-blocking | Proof failure never blocks business flow (fireProof() pattern) |
| Idempotency | Duplicate-safe recording via idempotencyKey |
This is compliance-by-design — not reactive compliance, but compliance built into the architecture itself.
Roadmap: v2+ Planned Capabilities
The following features are designed but not yet implemented in v1:| Feature | Description | Target |
|---|---|---|
| 6W Auto-extraction | Automatic Who/What/When/Where/Why/How extraction from evidence | v2 |
| Voice Input | Audio hash (SHA-256) → STT transcription → confidence score | v2 |
| Policy Snapshot | Point-in-time policy version capture and comparison | v2 |
| 5 Governance Guards | Evidence level, human review, risk threshold, dual approval, compliance logging | v2 |
| Responsibility Graph | Track all actors (human + AI) involved in a decision | v2 |
| Cross-domain 6W normalization | Unified audit structure across verticals | v3 |
| Multi-approval policies | Route approvals by amount, risk level, or decision type | v2 |
The DPU Engine page describes the full architectural vision including governance guards. v1 implements the core: record → approve → hash chain seal → export.