> ## 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

> How decisions become tamper-proof evidence — from recording to audit-ready export

# 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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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`)

```json theme={null}
{
  "@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`                         |

<Info>
  This is **compliance-by-design** — not reactive compliance, but compliance built into the architecture itself.
</Info>

***

## 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     |

<Note>
  The DPU Engine page describes the full architectural vision including governance guards. v1 implements the core: record → approve → hash chain seal → export.
</Note>