Claims Lifecycle

A claim turns a covered loss into a signed payout. chio-market ships two claim surfaces: the artifact-shaped market workflow, where every stage is a separate signed envelope, and the lighter BoundPolicy::file_claim helper that re-verifies receipt evidence and submits a settlement request to a sink. Both end the same way: an externally-observed execution that reconciles back to the capital book.

Artifact Workflow

The artifact workflow advances through seven stages. Each stage is a signed envelope (SignedExportEnvelope) and embeds the prior stage by reference, so the final settlement receipt carries an unbroken signature chain back to the bound coverage.

1. Claim Package

LiabilityClaimPackageArtifact is the operator's submission to the provider. It bundles the evidence the provider needs to evaluate the loss:

pub struct LiabilityClaimPackageArtifact {
    pub schema: String,
    pub claim_id: String,
    pub issued_at: u64,
    pub bound_coverage: SignedLiabilityBoundCoverage,
    pub exposure: SignedExposureLedgerReport,
    pub bond: SignedCreditBond,
    pub loss_event: SignedCreditLossLifecycle,
    pub claimant: String,
    pub claim_event_at: u64,
    pub claim_amount: MonetaryAmount,
    pub claim_ref: Option<String>,
    pub narrative: String,
    pub receipt_ids: Vec<String>,
    pub evidence_refs: Vec<LiabilityClaimEvidenceReference>,
}

Validation enforces that the claim amount currency matches the bound coverage currency, the claim amount does not exceed the bound coverage amount, the claim event falls inside the coverage effective window, the exposure book is not mixed-currency, and the bond and loss event match the same subject as the bound coverage. Receipt ids must be non-empty and unique.

2. Claim Response

The provider replies with a LiabilityClaimResponseArtifact carrying one of three dispositions:

• Acknowledged: receipt of the package; no covered amount yet, no denial reason yet.
• Accepted: covered amount set (cannot exceed claim amount, must match currency); no denial reason.
• Denied: non-empty denial reason; no covered amount.

A response can be a partial accept: the covered amount may be less than the claim amount, which leaves the door open for a dispute on the balance.

3. Claim Dispute

LiabilityClaimDisputeArtifact is opened by the claimant against a denied or partially accepted response. Validation requires opened_by and reason to be non-empty, and the underlying response must be Denied or partially Accepted (where the covered amount is less than the claim amount). A fully accepted response cannot be disputed.

4. Adjudication

LiabilityClaimAdjudicationArtifact is the adjudicator's ruling on a dispute. Outcome is one of:

• ClaimUpheld: claimant wins; awarded amount required (must not exceed the original claim amount).
• ProviderUpheld: provider wins; no awarded amount.
• PartialSettlement: middle ground; awarded amount required and must be strictly less than the claim amount.

5. Payout Instruction

LiabilityClaimPayoutInstructionArtifact ties the adjudication to a signed CapitalExecutionInstructionArtifact for actual fund movement. Validation requires:

• The capital instruction action is TransferFunds.
• The capital instruction source kind is FacilityCommitment.
• The instruction amount equals the adjudication's awarded amount.
• The capital instruction subject matches the claim subject.
• The capital instruction is unreconciled at issuance time so the payout receipt that follows is explicit rather than backfilled.

A ProviderUpheld outcome cannot generate a payout instruction; only ClaimUpheld or PartialSettlement qualify.

6. Payout Receipt

LiabilityClaimPayoutReceiptArtifact records that the payout actually executed on the chosen rail. It carries a CapitalExecutionObservation (with observed_at, external_reference_id, and observed amount) and a reconciliation state:

• Matched: observed amount equals the payout instruction amount.
• AmountMismatch: observed amount differs (operator must reconcile or open a follow-up instruction).

The observation timestamp must fall inside the capital instruction's execution window.

7a. Settlement Instruction

After a matched payout, the operator may issue a LiabilityClaimSettlementInstructionArtifact to move the resulting position around the broader capital structure. Settlement kind is one of:

• RecoveryClearing: clearing a recovered loss back to the source.
• ReinsuranceReimbursement: passing through to a reinsurer.
• FacilityReimbursement: reimbursing the facility commitment.

The instruction includes a role topology (payer, payee, optional beneficiary) drawn from CapitalExecutionRole, an authority chain, an execution window, and a rail descriptor. The capital_book attached must be subject-coherent and not mixed-currency.

7b. Settlement Receipt

LiabilityClaimSettlementReceiptArtifact closes out the settlement. Its reconciliation state is one of:

• Matched: observed amount, payer, and payee all match the instruction.
• AmountMismatch: payer and payee match, amount differs.
• CounterpartyMismatch: at least one observed counterparty differs from the topology.

State Diagram

ClaimDecision and ClaimDenialReason

The compact file_claim path on BoundPolicy resolves to a ClaimDecision:

pub enum ClaimDecision {
    Approved {
        policy_id: String,
        claim_id: String,
        payable_amount: MonetaryAmount,        // capped at coverage limit
        settlement: Box<ClaimSettlement>,
        justification: String,
    },
    Denied {
        policy_id: String,
        claim_id: String,
        reason: ClaimDenialReason,
        justification: String,
    },
}

pub enum ClaimDenialReason {
    PolicyNotInForce,
    CurrencyMismatch,
    InsufficientEvidence,
    EvidenceUnresolvable,
    EvidenceDigestMismatch,
    SignatureInvalid,
}

The denial vocabulary is fail-closed: any unresolved receipt id, any body-digest mismatch, or any kernel-signature failure denies the claim. There is no implicit approval path.

ClaimEvidence

pub struct ClaimEvidence {
    pub claim_id: String,
    pub policy_id: String,
    pub requested_amount: MonetaryAmount,
    pub incident_description: String,
    pub supporting_receipts: Vec<ReceiptFingerprint>,
    pub settlement_chain_id: String,
}

pub struct ReceiptFingerprint {
    pub receipt_id: String,
    pub body_sha256: String,
}

Each fingerprint is re-verified against the kernel signing key via the caller-supplied ReceiptEvidenceSource trait before approval. The requested_amount may exceed the coverage limit; payouts cap at the coverage limit.

ClaimSettlement and the Settlement Sink

On approval, the helper builds a ClaimSettlementRequest (field-compatible with chio_settle::SettlementCommitment):

pub struct ClaimSettlementRequest {
    pub chain_id: String,                // from evidence.settlement_chain_id
    pub lane_kind: String,               // INSURANCE_CLAIM_LANE_KIND ("chio.insurance.claim.v1")
    pub capability_commitment: String,   // policy_id
    pub receipt_reference: String,       // first supporting receipt id
    pub operator_identity: String,       // "chio-market:insurance-flow:<agent_id>"
    pub settlement_amount: MonetaryAmount,
}

pub struct ClaimSettlement {
    pub request: ClaimSettlementRequest,
    pub settlement_reference: String,    // assigned by the sink
}

The caller implements ClaimSettlementSink to bridge into chio-settle; the five fields on ClaimSettlementRequest map 1:1 to SettlementCommitment.

Evidence Requirements by Coverage Class

chio-market does not encode coverage-class-specific evidence menus in Rust types. Instead, each provider declares its expected evidence on every jurisdiction policy via required_evidence (a vector of LiabilityEvidenceRequirement). Operators inspect the policy reference embedded in the quote request to know what to attach. See Liability Market for the requirement vocabulary.

Reinsurance Pass-Through

Reinsurance is supported as a LiabilityClaimSettlementKind::ReinsuranceReimbursement on the settlement instruction stage. chio-market does not maintain a separate reinsurance registry; the topology is captured by the settlement instruction's payer/payee/beneficiary roles and routed through the configured rail. The CapitalExecutionRole::Reinsurer role is available for both authority steps and topology bindings.

Reconciliation Back to Facility and Bond Accounting

The payout instruction draws from a FacilityCommitment source on the capital book; the payout receipt records the rail observation; and an optional settlement instruction routes the resulting position (recovery clearing, reinsurance reimbursement, or facility reimbursement). The capital book is the authoritative source-of-funds ledger, so each successful settlement appears as a Disburse event tied to the facility id and the bond id.

When a claim payout exceeds what the bond can absorb, downstream recovery may invoke the bond's loss lifecycle: a ReserveSlash moves bond capital into the loss bucket, and a WriteOff formalizes the unrecoverable balance. See Credit Facilities & Bonds for the full loss-lifecycle event vocabulary.

Worked Example

An agent action causes a data exposure that meets the DataBreach coverage class for an active bound coverage in us-ny, denominated in USD.

1. Package: the operator submits a LiabilityClaimPackageArtifact with the bound coverage, the agent's exposure ledger, the active bond, and the loss-lifecycle event for the underlying delinquency. Claim amount: $25,000 (2,500,000 USD cents).
2. Response: the provider accepts at $20,000 with a partial-coverage rationale (LiabilityClaimResponseDisposition::Accepted with covered_amount $20,000).
3. Dispute: the operator disputes the $5,000 shortfall (partial accept qualifies for dispute).
4. Adjudication: the adjudicator rules PartialSettlement with awarded_amount $22,500.
5. Payout instruction: a signed CapitalExecutionInstructionArtifact for $22,500 transfer-funds out of the facility commitment, paired with the adjudication.
6. Payout receipt: the rail observes a $22,500 transfer with external reference tx-0xabcd...; reconciliation is Matched.
7. Settlement instruction: the operator issues a FacilityReimbursement settlement to refill the facility commitment from operator treasury.
8. Settlement receipt: the rail observes the reimbursement; reconciliation is Matched; the chain closes.

Next Steps

• Liability Market : the registry and quote-and-bind workflow that produces the bound coverage a claim is filed against.
• Underwriting Risk Taxonomy : the risk inputs that price the original premium and shape the provider's response.
• Credit Facilities & Bonds : the facility and bond accounting that absorbs payouts.
• Settlement Rails : the rails that move the claim payout and any downstream reimbursements.
• Reconciliation : how rail observations close the loop on instructions.