Case Management & Claims — standalone architecture

📖 Flow story — what really happens

Two mechanisms here: the event bus (async facts — events announcing something that already happened — via the outbox → Pub/Sub/EventBridge → push-subscription, deduped on event_id) AND the install-gate FIFO work queue (ordered commands — instructions to do something, processed in order — Cloud Tasks / SQS FIFO) — they are not the same thing.

1. The Case API's push-subscription receives MarkedAsSold from the bus (deduped on event_id) and writes an install_job row (status PENDING) to Cloud SQL.
2. It enqueues one message on the install-gate work queue (Cloud Tasks / SQS FIFO) — an ordered command queue, not the event bus — grouped by policy_id so the case installs exactly once, in order.
3. A worker pulls the job and runs the gate: is the account_structure built? underwriting clean? broker valid?
4. PASS → in one transaction it writes account_structure + cope_location rows, flips the policy row to ACTIVE, sets install_job=DONE, and writes an outbox row → the relay publishes PolicyActivated.
5. FAIL → it opens an ops_task row, puts the state-filed temporary cover in effect (binder coverage), and emits InstallGateFailed; transient errors retry, and a poison message (one that keeps failing on every retry) lands in the dead-letter queue for a human.
6. The case is now in-force: Ops (internal, SSO) service coverages, endorsements, billing, and the timeline from the same Cloud SQL.
7. On a loss, FNOL writes a claim row (status OPEN) linked to the policy; photos/docs upload to object storage, only their storage keys (reference IDs, not the files) in claim_media; an outbox row → FNOLReceived on the bus.
8. A VLM analyzes the damage photos and writes a damage score + fraud signal onto the claim; the governed, redacted outcome is written to the decision_log/rag_document store (embedded in pgvector) — closing the loop back to underwriting.