Pre-sale / Underwriting — standalone architecture

📖 Flow story — what really happens

Every cross-flow arrow is the same async handoff — no flow calls another directly. 1. The sending flow commits its data row plus an outbox row in one transaction. 2. A relay publishes the event to the event bus (Pub/Sub on GCP · EventBridge→SQS on AWS). 3. The bus's push-subscription POSTs it to the receiving flow's Cloud Run API, which processes it idempotently (duplicates ignored, deduped on event_id). Synchronous reads (e.g. getProductVersion) are plain request/response.

1. The Underwriting API's push-subscription receives QuoteRequested from the bus (deduped on event_id) and writes a submission row to its own Cloud SQL.
2. It runs the scorecard, fanning out to risk assessors — cat-model peril scores, property characteristics, and the product's risk rules each add a weighted signal; the result is saved as a scorecard_result row.
3. The score routes the case: clean → auto-accept; appetite flag (outside the risk profile this insurer chooses to accept) → refer to a human; hard rule breach (a disqualifying condition no human may override) → decline.
4. The underwriter (or the AI agent within guardrails) decides; the decision is appended to the uw_decision log on WORM storage (tamper-evident), stamped with the model + rule + product_version so it's reconstructable for regulators.
5. The same transaction writes an outbox row; the relay publishes DecisionMade(accept|refer|decline) to the bus.
6. On accept, Pricing's subscription picks it up next. The decision + eventual outcome (access-controlled, personal data removed) is also written to the decision_log/rag_document store and embedded into pgvector, so the agent learns from real decisions.