Claims Processing — Industry-Specific Implementations

Audience: Product, operations, architects, and implementation teams deploying claims processing for specific industries and players. Status: As of 2026-11-09 — documents what exists, what is configured, and what remains to be built. Substrate: Sovereign OS / Community Weave Platform — canonical claim primitive, truth_edge graph, PoCE (s131-s150), scope governance (s142), record federation (s184), APF (s230), NATS KV lookups (SOVEREIGN_LOOKUPS, SOVEREIGN_SCENARIOS, SOVEREIGN_TEMPLATES), Apache Camel (:8181), Kestra (:8180), solver-gateway (:3070).

1. Overview — One Claims Engine, Many Verticals

The Sovereign OS claims processing system is generalised by design: a single claim primitive, one guarded lifecycle state machine (draft → submitted → validating → approved/rejected → disputed → settled/cancelled), declarative guard policies (quorum, separation of duties, evidence, external verdicts, execution proof), and PoCE-signed receipts for every transition. No bespoke tables are created; every claim type is a CNS-typed claim record with truth_edge relationships to subjects, providers, adjusters, garages, and other principals.

This document set provides industry-specific configurations — CNS types, lookup values, guard policies, panel roles, SLA windows, intake maps, and worked examples — for the following verticals:

Guiding principle across all verticals: Optimizers propose, claim gates authorize, never settle or pay. The solver-gateway (:3070) may recommend crew routing, vendor selection, or basket splits, but a named human approver must confirm via PoCE before any money moves or any claim is settled.

2. Core Claims Primitives (Shared Across All Verticals)

2.1 Lifecycle State Machine (8 States)

Allowed transitions (hardcoded in fn::claim_processing::_validate_transition, s282):

• draft → submitted, cancelled
• submitted → validating, rejected, cancelled
• validating → approved, rejected, disputed
• approved → settled, disputed
• rejected → disputed, cancelled
• disputed → validating, cancelled
• settled → (none)
• cancelled → (none)

2.2 Guard Stages (Evaluated in Order)

Any failing stage refuses the transition with a 4xx validation error; nothing advances silently.

2.3 Canonical Claim Mapping (All Verticals)

3. Industry Implementations

See each industry document for CNS types, lookup values, guard policies, panel roles, SLA windows, and worked examples:

• Real Estate Claims — defect/snag tracking, service charge disputes, construction warranty, HOA assessments
• Healthcare Claims — medical claims, prior authorization, pharmacy claims, HIPAA/FHIR boundaries
• Government Claims — benefit claims, compensation claims, community tickets, cross-agency governance
• Commerce Claims — order claims, refund claims, warranty claims, escrow-backed settlement
• Construction Claims — project delay, milestone payment disputes, defect rectification, expert sign-off
• Insurance Claims — motor, home, liability, catastrophe claims with provider panels

4. Players in Claims Processing

Each vertical involves distinct players with different capabilities, attestations, and permissions:

• Insurer / Carrier — risk bearer, panel organisation role, reinsurer notice
• Third Party Administrator (TPA) — claims handling on behalf of insurer, adjudication, vendor management
• Broker / Agent — first notice of loss intake, distribution, policy placement
• Service Provider — garage, clinic, contractor, repair shop — performs work, provides evidence

See each player document for capabilities, attestation requirements, lease TTLs, and panel eligibility rules.

5. Playbooks (Concrete Implementations)

Specific, runnable claim processing patterns:

• STP Fast-Track Auto Claims — straight-through processing for small auto claims, solver-assisted, minimal human touch
• Medical Claims — HIPAA/FHIR — HIPAA-compliant medical claims, prior authorization, PHI scrubbing, FHIR/EDI interoperability via Camel
• Homeowners Claims — multi-party asset governance, catastrophe screening, escrow until proof, expert sign-off

6. Appendices

• CNS Type Hierarchy — complete CNS URI registry for all claim types across all verticals
• Gap Analysis — identified gaps between current implementation and target claims processing capability

7. Architectural Honesty Limits (Applied to All Verticals)

Per AGENTS.md — Sovereign OS / Cosmic Circuit mandates and the Honesty Invariants (D-15):

1. No bespoke tables. All claim entities map to claim, truth_node/truth_edge, resource/resource_edge, integration_entity. No motor_claim, medical_claim, snag_defect, or service_charge_dispute tables.
2. Declarative-first. Lookups, thresholds, packs, maps live in NATS KV (SOVEREIGN_LOOKUPS, SOVEREIGN_SCENARIOS, SOVEREIGN_TEMPLATES). Runtime never reads disk.
3. Fail closed. Infrastructure errors → 502/503/422/throw. Never synthetic "OPTIMAL", "APPROVED", or deterministic fallbacks.
4. No smoke code. No mocks, synthetic fixtures-as-truth, dummy coordinates, or hardcoded card/metric values.
5. Machines propose, claim gates authorize. Solver recommendations never settle or pay; a named human approver confirms via PoCE.
6. No hardcoded metrics. Dashboards render live data or honest skeleton/empty states.
7. PoCE audit. Every critical state transition produces a cryptographically verifiable receipt.

8. How to Use This Set

• Architects: Start with the CNS Type Hierarchy and the relevant industry document.
• Product / Ops: Read the industry document for your vertical, then the relevant playbook.
• Implementation: Deploy strata in order, seed CNS types and lookups via scripts/seed-nats-kv-declarative.mjs, configure panel roles and SLA windows in NATS KV, then test with the claims readiness probe (GET /v1/claims/processing/readiness).
• Compliance / Audit: Review Honesty Invariants and the Gap Analysis.