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

Audit response is always reactive. When issues arise, teams dig through logs, query databases, and rely on staff memory. Cronozen solves this at the design level: every decision generates its proof at the moment of creation.

v1 Pipeline: Record → Approve → Seal → Export

The current Proof Pipeline consists of 4 stages:

┌──────────────────────────────────────────────────────────┐
│                    PROOF PIPELINE v1                       │
│                                                            │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌────────┐│
│  │ Stage 1  │──▶│ Stage 2  │──▶│ Stage 3  │──▶│Stage 4 ││
│  │ Record   │   │ Approve  │   │Hash Chain│   │ Export ││
│  │          │   │          │   │ Sealing  │   │        ││
│  └──────────┘   └──────────┘   └──────────┘   └────────┘│
│                                                            │
└──────────────────────────────────────────────────────────┘
      ↑                                            │
  API Call                                   JSON-LD v2
  (SDK / cURL)                            Audit Document

Stage 1 — Record

A decision event is created via API with structured metadata.

await cz.decision.record({
  type: "settlement_created",
  actor: "finance_bot",
  action: "approve_settlement",
  input: { settlementId: "STL-5678", amount: 150000 },
  aiContext: { model: "gpt-4", confidence: 0.92 },
  tags: ["settlement", "finance"]
})

Each event captures:

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.

await cz.decision.approve(event.id, {
  approver: "center_director",
  reason: "Verified against settlement policy v2.1"
})

Once approved, the event transitions from RECORDED → SEALED.

Stage 3 — Hash Chain Sealing

The approved event is linked to the previous event’s hash, forming an immutable chain.

[Genesis]         [Event #1]        [Event #2]
┌───────────┐    ┌───────────┐    ┌───────────┐
│ index: 0  │    │ index: 1  │    │ index: 2  │
│ prevHash: │    │ prevHash: │    │ prevHash: │
│  GENESIS  │◀───│  hash_0   │◀───│  hash_1   │
│ chainHash:│    │ chainHash:│    │ chainHash:│
│  hash_0   │    │  hash_1   │    │  hash_2   │
└───────────┘    └───────────┘    └───────────┘

chainHash = SHA-256(content + previousHash + timestamp)

Key properties:

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.

const report = await cz.evidence.export(event.id)

The export includes:

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)

{
  "@context": "https://schema.cronozen.com/decision-proof/v2",
  "@type": "DecisionProof",
  "decision": { "type": "...", "actor": "...", "action": "..." },
  "approval": { "approver": "...", "approvedAt": "..." },
  "evidence": { "chainHash": "sha256:...", "chainIntegrity": "VERIFIED" }
}

This document is self-contained and can be submitted to auditors independently of the Cronozen platform.

Real-World Example: Settlement Flow

Settlement created (finance_bot)
     │
     ▼
[Event #0] Settlement Created
├─ Actor: finance_bot
├─ Action: create_settlement
├─ Input: { amount: 150000, settlementId: "STL-5678" }
├─ AI Context: { model: "gpt-4", confidence: 0.92 }
├─ Status: RECORDED
└─ Chain: hash_0 (Genesis)
     │
     ▼  (Director reviews and approves)
[Event #0] → SEALED
├─ Approval: { approver: "center_director", reason: "Policy v2.1" }
├─ Chain Hash: sha256:9e2b...
├─ Evidence Level: AUDIT_READY
└─ Immutable — part of hash chain

     │
     ▼  (Audit request)
[Export] → JSON-LD v2 document
├─ Decision + Approval + Chain integrity
└─ Portable, self-contained audit evidence

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.

Getting Started

Architecture

Authentication

Tenant System

AI Agents

Compliance

Guides

Examples

API Reference

Proof Pipeline

Proof Pipeline

The Problem

v1 Pipeline: Record → Approve → Seal → Export

Stage 1 — Record

Stage 2 — Approve

Stage 3 — Hash Chain Sealing

Stage 4 — Export

Real-World Example: Settlement Flow

What This Achieves

Roadmap: v2+ Planned Capabilities

​Proof Pipeline

​The Problem

​v1 Pipeline: Record → Approve → Seal → Export

​Stage 1 — Record

​Stage 2 — Approve

​Stage 3 — Hash Chain Sealing

​Stage 4 — Export

​Real-World Example: Settlement Flow

​What This Achieves

​Roadmap: v2+ Planned Capabilities

Proof Pipeline

The Problem

v1 Pipeline: Record → Approve → Seal → Export

Stage 1 — Record

Stage 2 — Approve

Stage 3 — Hash Chain Sealing

Stage 4 — Export

Real-World Example: Settlement Flow

What This Achieves

Roadmap: v2+ Planned Capabilities