# ClaimAnchor™ — CIO Architecture & Integration Specification
## Enterprise Evidence Provenance Layer for Insurance Claims
### Integration Boundary Model v1.1 · ICPO X Inc. · June 2026 · Confidential

---

## Purpose

ClaimAnchor provides an independent, cryptographically verifiable chain-of-custody record for insurance claim documents at the point of submission.

It does not replace claims systems. It operates as an external, non-invasive evidence provenance layer that attaches to insurance submission workflows at the document ingress boundary — generating a cryptographic fingerprint and independently verifiable timestamp anchored to Bitcoin prior to system-of-record ingestion. It introduces no dependency on core claims systems, does not alter workflow execution, and functions as a parallel evidence layer consumed by SIU, compliance, audit, and legal functions.

**CIO positioning:** *"An external evidence integrity layer. Regulatory-grade audit augmentation. Claims submission provenance control."*

---

## 1. Logical Architecture

```
┌──────────────────────────────────────────────────────────────────────┐
│                    EXTERNAL SUBMISSION ECOSYSTEM                     │
│  Agencies · MGAs · Portals · Email · Mobile Upload · API Partners   │
└───────────────────────────────┬──────────────────────────────────────┘
                                │  (1) Document selected for submission
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                    CLAIMANCHOR INGESTION GATEWAY                     │
│                  (Independent Evidence Boundary Layer)               │
│                                                                      │
│  • SHA-256 fingerprint generation                                    │
│  • Pre-transmission timestamp capture                                │
│  • Metadata binding (agency, claim ID, doc type)                    │
│                                                                      │
│  ┌──────────────────────────────┐  ┌───────────────────────────────┐ │
│  │ Bitcoin Anchoring Layer      │  │ Arweave Evidence Storage      │ │
│  │ (immutable timestamp proof)  │  │ (optional full payload)       │ │
│  └──────────────────────────────┘  └───────────────────────────────┘ │
│                                                                      │
│  OUTPUT: ClaimAnchor Certificate (verifiable proof object)           │
└───────────────────────────────┬──────────────────────────────────────┘
                                │  (2) Submission continues unchanged
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                     CLAIMS INTAKE / TRANSPORT LAYER                  │
│      Email relay · API gateway · Clearinghouse · Portal ingestion    │
└───────────────────────────────┬──────────────────────────────────────┘
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                    SYSTEMS OF RECORD (CORE STACK)                    │
│  Guidewire · Duck Creek · Vertafore · Custom Claims Platforms        │
│                                                                      │
│  Stores: document copy · workflow state · adjuster actions           │
└───────────────────────────────┬──────────────────────────────────────┘
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                DOWNSTREAM CONSUMERS OF EVIDENCE                      │
│  SIU · Compliance · Legal · Audit · Litigation · Regulators          │
│  (Consumes ClaimAnchor Certificate as independent truth layer)       │
└──────────────────────────────────────────────────────────────────────┘
```

---

## 2. Trust Boundary Model

This is the CIO-grade justification for why ClaimAnchor exists as a separate layer rather than an extension of existing systems.

| Layer | Trust Domain | Risk of Manipulation | ClaimAnchor Role |
|---|---|---|---|
| Submission source (Agency / MGA) | External / untrusted | High | Observed, not trusted |
| Claims system (Carrier) | Internal trusted system | Medium — internal override possible | Not dependent on |
| **ClaimAnchor layer** | **Independent public infrastructure** | **Very low — Bitcoin + Arweave** | **Neutral witness / truth anchor** |

**Key architectural principle: ClaimAnchor is the only layer not controlled by any party participating in the claim lifecycle.**

Existing systems create timestamps and audit trails within environments controlled by participating parties — even immutable internal logs, WORM storage, and evidentiary controls remain inside that party's architecture. ClaimAnchor's timestamp exists on a public network controlled by no one. That distinction is the architectural basis for its evidentiary independence.

---

## 3. Integration Contract

### 3.1 Core Contract

ClaimAnchor is invoked at the document ingress edge **before** system-of-record commit.

```
Document → Hash → Anchor → Certificate → System-of-record ingestion continues
```

**Integration point:** Document egress boundary — after document finalization by the submitting party, before transmission into the carrier/MGA ingestion channel. This is the legal and evidentiary moment of custody transfer.

| Placement | Evidentiary Value | Why |
|---|---|---|
| Document creation (too early) | Low | Just versioning internal drafts — weak chain-of-custody |
| **Document egress (correct)** | **Highest** | Proves what the submitting party sent and when — legal custody transfer moment |
| Post-ingestion into claims system (too late) | Medium | Dependent on carrier logs — loses independence |

---

### 3.2 Technical Interface

**Endpoint:** `POST /v1/anchor`

**Request:**
```json
{
  "document_hash": "sha256",
  "submission_context": {
    "agency_id": "string",
    "claim_id": "string",
    "document_type": "invoice | EOB | photo | report | other"
  },
  "timestamp_mode": "pre_ingestion"
}
```

**Response:**
```json
{
  "certificate_id": "string",
  "bitcoin_tx": "string",
  "block_height": "int",
  "arweave_id": "string",
  "document_hash": "sha256",
  "verified": true
}
```

---

### 3.3 Event Semantics

| Event | Meaning |
|---|---|
| `document_selected` | Submission intent created |
| `document_fingerprinted` | Hash generated before system ingestion |
| `anchor_committed` | Bitcoin transaction broadcast |
| `certificate_issued` | Proof object returned to submitting system |
| `claims_ingestion_continues` | No workflow interruption |

---

## 4. Deployment Topology

### Mode A — Edge Proxy (Low Integration Friction)
**Target:** Independent agencies, pilots

```
Agency → ClaimAnchor → Carrier email / API
```
- No carrier change required
- No claims system modification
- Integration surface: submit@claimanchor.com · web portal · browser extension
- Fastest adoption path

### Mode B — Middleware Integration (MGA Layer)
**Target:** MGAs, Vertafore / AMS360 / custom MGA stacks

```
AMS / MGA platform → ClaimAnchor API → Carrier system
```
- REST API or webhook embedded in submission pipeline
- Adds compliance and SIU visibility layer
- No carrier-side changes required

### Mode C — Core Claims Plugin (Enterprise / Carrier)
**Target:** Guidewire / Duck Creek enterprise environments

```
Guidewire / Duck Creek ingestion pipeline
            ↓
     ClaimAnchor interceptor (pre-storage middleware)
            ↓
     System-of-record commit + certificate binding
```
- Java/.NET plugin OR microservice middleware
- Optional Kafka/event-stream hook for ingestion pipeline
- Full enterprise adoption; SIU and audit embedded consumption

---

## 5. Failure Modes

**This section determines procurement viability.**

| Failure Mode | System Impact | Mitigation |
|---|---|---|
| ClaimAnchor service unavailable | Submission continues without interruption | Non-blocking architecture — claim workflow never waits on ClaimAnchor |
| Blockchain anchoring delay | Certificate issued asynchronously | Queue-based commit; hash proof valid independently of Bitcoin confirmation timing |
| Arweave storage delay | Hash-level proof still valid | Storage decoupled from truth — the Bitcoin anchor is sufficient for evidentiary purposes |
| Duplicate document submission | Multiple certificates valid per version | Versioned hashing — each version has its own independent certificate |
| Metadata mismatch | Audit flag only | No ingestion block; compliance review triggered without disrupting claims workflow |

> **Critical design principle: Claim submission is never dependent on ClaimAnchor availability.**

This is the answer to the CIO's first procurement question: *"What happens if your service goes down?"* The answer is: nothing changes in the claims workflow. ClaimAnchor is additive, not load-bearing.

---

## 6. Data Ownership Model

| Asset | Owner |
|---|---|
| Original document | Agency / MGA |
| System-of-record copy | Carrier |
| Claim workflow state | Carrier system |
| ClaimAnchor certificate | Public infrastructure record |
| Bitcoin timestamp | Distributed network — no owner |
| Arweave record | Decentralized storage network — no owner |

---

## 7. Security & Compliance

**ClaimAnchor does not:**
- Store Protected Health Information (unless explicitly configured for full payload mode)
- Replace claims systems or modify workflow execution
- Act as fraud adjudicator or fraud detection system
- Create custody over original documents

**ClaimAnchor does:**
- Create immutable proof-of-existence at the moment of submission
- Provide third-party verifiable timestamps on public infrastructure
- Eliminate internal system dependency for authenticity disputes

**PHI handling principle:** ClaimAnchor is designed to operate in hash-only mode by default. No Protected Health Information is required for core functionality. Any full payload storage (Arweave) is explicitly disabled by default in regulated deployments and enabled only under a signed BAA and documented configuration. ClaimAnchor can function as a zero-PII evidence system.

CIO translation: *"The system is fully functional without ever processing regulated data."*

For organizations in HIPAA-adjacent contexts (medical stop-loss, health claims, gap insurance covering medical costs), ClaimAnchor accepts anonymized or tokenized claim identifiers in place of raw claim IDs, preserving full provenance functionality with zero PHI exposure. A Business Associate Agreement (BAA) is available for enterprise deployments where metadata handling requires formal documentation.

---

## 8. Buyer-Function Alignment

| Function | How They Use ClaimAnchor | Value Statement |
|---|---|---|
| SIU | Instant verification of original submission state — no reconstruction | "We no longer reconstruct truth. We verify it." |
| Claims Operations | Eliminates version disputes and document ambiguity from the claims lifecycle | "Which version is correct — answered in 60 seconds." |
| Compliance / Legal | Audit trail converted from internal logs to externally verifiable evidence | "We convert your audit trail into evidence no one can challenge." |
| CIO / IT | External trust anchor — minimal integration surface, no core system modification | "Adjacent to every workflow. Modifies none of them." |

---

## 9. System Requirements

**No requirements for:**
- Claims system modification (Mode A and B)
- Carrier system integration (Mode A)
- Data migration
- Workflow redesign

**Optional:**
- API key provisioning (MGA / enterprise)
- Event streaming integration (Kafka / webhook)
- Certificate metadata stored in claims system fields
- BAA execution (HIPAA-adjacent environments)

---

## 10. Procurement Classification

CIOs will not categorize this as "blockchain infrastructure." It will be evaluated as one of:

- External evidence integrity layer
- Regulatory-grade audit augmentation system
- Claims submission provenance control
- SIU evidence pre-certification system

That classification determines whether it is funded from SIU budget, compliance budget, or enterprise risk infrastructure budget. The correct positioning for procurement is the third — enterprise risk infrastructure — because it compresses costs across all four budget lines simultaneously.

---

## 11. Deployment Path

| Phase | Mode | Target | Timeline |
|---|---|---|---|
| 1 — Agency pilot | Email proxy | Independent agencies | Days |
| 2 — MGA integration | API middleware | MGAs, AMS vendors | Weeks–months |
| 3 — Carrier plugin | Platform plugin | Guidewire / Duck Creek carriers | Quarters |
| 4 — Platform standard | Network-wide | Distribution platforms | Strategic |

---

*ClaimAnchor™ · CIO Architecture & Integration Specification · v1.1 · June 2026 · ICPO X Inc.*
*Nothing herein constitutes legal, financial, or compliance advice.*
*BTC anchoring currently operates on Bitcoin testnet. Production mainnet deployment prior to commercial launch.*