Skip to main content

​
Proof Pipeline

​
The Problem

AI agents and workflows execute decisions automatically — but those decisions are not recorded in a verifiable, auditable way.
ProblemConsequence
Decision rationale scattered across logsCannot reconstruct during audit
Approval flows unstructuredUnclear responsibility
No data integrity guaranteePost-hoc tampering undetectable
AI involvement opaqueCannot 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.
GuaranteeMechanism
IntegritySHA-256 Hash Chain — mid-chain tampering breaks all subsequent hashes
AccountabilityApproval chain — who approved, when, why
Non-blockingProof failure never blocks business flow (fireProof() pattern)
IdempotencyDuplicate-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:
FeatureDescriptionTarget
6W Auto-extractionAutomatic Who/What/When/Where/Why/How extraction from evidencev2
Voice InputAudio hash (SHA-256) → STT transcription → confidence scorev2
Policy SnapshotPoint-in-time policy version capture and comparisonv2
5 Governance GuardsEvidence level, human review, risk threshold, dual approval, compliance loggingv2
Responsibility GraphTrack all actors (human + AI) involved in a decisionv2
Cross-domain 6W normalizationUnified audit structure across verticalsv3
Multi-approval policiesRoute approvals by amount, risk level, or decision typev2
The DPU Engine page describes the full architectural vision including governance guards. v1 implements the core: record → approve → hash chain seal → export.