Claims Lifecycle

Decision records

Claim package

LiabilityClaimPackageArtifact is the operator's submission to the provider, bundling 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 requires the claim currency to match the bound coverage currency, the claim amount to stay within the coverage amount, the claim event to fall inside the coverage effective window, a single-currency exposure book, and a bond and loss event for the same subject as the bound coverage. Receipt ids are non-empty and unique.

Claim response

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

• Acknowledged: receipt of the package, with no covered amount and no denial reason.
• Accepted: a covered amount in the claim currency, at most the claim amount, with no denial reason.
• Denied: a non-empty denial reason and no covered amount.

A partial acceptance has a covered amount below the claim amount, and the claimant can dispute the remaining balance.

Claim dispute

LiabilityClaimDisputeArtifact is opened by the claimant against a Denied response, or an Accepted one whose covered amount is below the claim amount. Validation requires non-empty opened_by and reason. A fully accepted response admits no dispute.

Adjudication

LiabilityClaimAdjudicationArtifact is the adjudicator's ruling on a dispute:

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

Predeclared adjudication

Two signature-safe fields record the roster binding: decision_rule_ref, the id of the predeclared decision rule or circuit-breaker condition applied, and roster_anchor_ref, the id or hash of the signed roster record used to check the adjudicator. The validate_against_roster policy gate enforces roster membership, an allowed decision-rule set, and that the recorded anchor equals the roster applied. An awarded amount never routes to the protocol treasury; Predeclared Settlement carries the full rules.

Money records

Payout instruction

LiabilityClaimPayoutInstructionArtifact ties the adjudication to a signed CapitalExecutionInstructionArtifact for the 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, so the payout receipt that follows references it.

Only ClaimUpheld or PartialSettlement produces a payout instruction; ProviderUpheld carries no payable amount.

Payout receipt

LiabilityClaimPayoutReceiptArtifact records that the payout executed on the selected settlement method. It carries a CapitalExecutionObservation (observed_at, external_reference_id, and the observed amount) and a reconciliation state:

• Matched: the observed amount equals the payout instruction amount.
• AmountMismatch: the observed amount differs; the operator reconciles or opens a follow-up instruction.

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

Settlement instruction

After a matched payout, the operator may issue a LiabilityClaimSettlementInstructionArtifact to move the resulting position through the broader capital structure. Its 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. Its attached capital_book is subject-coherent and in a single currency.

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, and the amount differs.
• CounterpartyMismatch: at least one observed counterparty differs from the topology.

Reinsurance pass-through

Reinsurance runs as LiabilityClaimSettlementKind::ReinsuranceReimbursement on the settlement instruction. The settlement instruction's payer, payee, and beneficiary roles carry the topology, routed through the configured rail, so chio-market keeps no separate reinsurance registry. The CapitalExecutionRole::Reinsurer role is available for both authority steps and topology bindings.

ClaimDecision and ClaimDenialReason

The compact file_claim path on BoundPolicy resolves to a ClaimDecision:

/// Resolution of a filed claim.
#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
#[serde(tag = "disposition", rename_all = "snake_case")]
pub enum ClaimDecision {
    /// Claim was approved; settlement has been submitted.
    Approved {
        /// Policy the claim was filed against.
        policy_id: String,
        /// Claim identifier.
        claim_id: String,
        /// Actual payable amount (capped at coverage limit).
        payable_amount: MonetaryAmount,
        /// Settlement request and reference returned by the sink. Boxed so
        /// the enum stays cheap to move between the chio-market and
        /// chio-kernel boundaries.
        settlement: Box<ClaimSettlement>,
        /// Human-readable justification for the approval.
        justification: String,
    },
    /// Claim was denied; no settlement was submitted.
    Denied {
        /// Policy the claim was filed against.
        policy_id: String,
        /// Claim identifier.
        claim_id: String,
        /// Machine-readable denial reason.
        reason: ClaimDenialReason,
        /// Human-readable justification for the denial.
        justification: String,
    },
}

A denial names one of nine reasons:

/// Machine-readable denial reason for a [`ClaimDecision::Denied`].
#[derive(Debug, Clone, Copy, Serialize, Deserialize, PartialEq, Eq)]
#[serde(rename_all = "snake_case")]
pub enum ClaimDenialReason {
    /// The policy is cancelled or expired.
    PolicyNotInForce,
    /// The claim currency did not match the coverage currency.
    CurrencyMismatch,
    /// No receipts were provided to support the claim.
    InsufficientEvidence,
    /// A referenced receipt is not in the receipt store.
    EvidenceUnresolvable,
    /// The receipt store could not answer. Distinct from
    /// [`Self::EvidenceUnresolvable`] because the receipt may well exist:
    /// this claim can be retried, and that one cannot.
    EvidenceSourceUnavailable,
    /// The receipt store understood the request and refused it. Retrying
    /// reaches the same refusal, which is what separates this from
    /// [`Self::EvidenceSourceUnavailable`].
    EvidenceRefused,
    /// The receipt store answered and its evidence did not verify.
    EvidenceInvalid,
    /// A referenced receipt's body digest did not match its fingerprint.
    EvidenceDigestMismatch,
    /// The kernel signature on a referenced receipt failed verification.
    SignatureInvalid,
}

The denial vocabulary fails closed: any unresolved receipt id, body-digest mismatch, or kernel-signature failure denies the claim, and approval has no implicit path. The evidence reasons also record why the store could not answer, which separates a claim worth retrying from a settled one: EvidenceSourceUnavailable carries the store's own Unavailable classification forward, while EvidenceRefused and EvidenceInvalid reach the same answer on every attempt (crates/economy/chio-market/src/insurance_flow.rs:386-402).

ClaimEvidence

pub struct ClaimEvidence {
    /// Stable claim identifier chosen by the filer.
    pub claim_id: String,
    /// Policy this claim is filed against.
    pub policy_id: String,
    /// Amount the filer is requesting (may exceed the coverage limit;
    /// payouts are capped at the policy's coverage limit).
    pub requested_amount: MonetaryAmount,
    /// Human-readable description of the incident.
    pub incident_description: String,
    /// Receipts that support the claim. Each one is re-verified against
    /// the kernel's signing key before approval.
    pub supporting_receipts: Vec<ReceiptFingerprint>,
    /// Chain id the settlement should be dispatched on. The insurance
    /// flow itself is chain-agnostic; the settle runtime routes
    /// according to this value.
    pub settlement_chain_id: String,
}

Each supporting receipt is named by a fingerprint as well as its id:

pub struct ReceiptFingerprint {
    /// Stable receipt id (matches the kernel receipt store key).
    pub receipt_id: String,
    /// SHA-256 of the canonical receipt body. Used for tamper-evidence
    /// in the evidence bundle.
    pub body_sha256: String,
}

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

ClaimSettlement and the settlement sink

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

pub struct ClaimSettlementRequest {
    /// Chain identifier the settlement should be dispatched on.
    pub chain_id: String,
    /// Settlement lane. Claim-payout dispatches use
    /// [`INSURANCE_CLAIM_LANE_KIND`].
    pub lane_kind: String,
    /// Capability / policy commitment (the policy id).
    pub capability_commitment: String,
    /// Receipt the claim is anchored to.
    pub receipt_reference: String,
    /// Operator identity dispatching the settlement.
    pub operator_identity: String,
    /// Amount to settle, in minor units + currency.
    pub settlement_amount: MonetaryAmount,
}

The approval path fills those fields from the evidence and the bound policy: the chain id from evidence.settlement_chain_id, the lane from INSURANCE_CLAIM_LANE_KIND, the commitment from the policy id, the reference from the first supporting receipt, and the identity as chio-market:insurance-flow:<agent_id> (crates/economy/chio-market/src/insurance_flow.rs:451-463). The sink returns the reference that completes the settlement record:

pub struct ClaimSettlement {
    /// The request submitted to the settlement sink.
    pub request: ClaimSettlementRequest,
    /// Reference returned by the settlement sink (for example, a tx hash).
    pub settlement_reference: String,
}

The caller implements ClaimSettlementSink to bridge into chio-settle; the six fields on ClaimSettlementRequest map one to one to SettlementCommitment (crates/economy/chio-settle/src/lib.rs:141-148).

Evidence requirements by coverage class

Each provider declares its expected evidence on every jurisdiction policy through required_evidence, a vector of LiabilityEvidenceRequirement, in place of class-specific evidence menus in the Rust types. Operators read the policy reference embedded in the quote request to know what to attach; Liability Coverage lists the requirement vocabulary.

Implementation sources

The package, response, dispute, and adjudication record types live in chio-market/src/claim.rs; the payout and settlement record types live in chio-market/src/settlement.rs. The compact in-process flow is BoundPolicy::file_claim in chio-market/src/insurance_flow.rs. All three share the same denial-reason vocabulary and the same handling of unverified evidence.