The full architecture shows the whole platform at once — which is a lot. In practice you'd implement one flow at a time. So here each business flow is designed as a standalone service with its own minimal stack (start with the smallest proven stack: Vercel + Cloud Run + Cloud SQL), and every other flow is a black box reached only through the event-contract spine. Each page shows that flow's own architecture, what it owns, and how it interfaces with the rest — so you can pick up just one (e.g. "build Product Design") and integrate later.
Or see the maturity ladder — the same platform grown stage by stage, from a one-week MVP to a multi-region, AI-enabled system.
Capture the property & product selection, prefill from data sources, kick off a quote.
Business analysts & actuaries author products + rules, versioned by date. Downstream flows mostly read it; it rarely changes.
Scorecard + the accept/refer/decline decision; the policy-config state machine + audit.
Rate the risk, freeze the premium (write-once ledger), hand off to billing.
Async (runs in the background after purchase) install gate → active policy; servicing; FNOL (First Notice of Loss)/claims.
Property prefill, climate cat-model (CAT = catastrophe), VLM (Vision-Language Model — reads claim & inspection photos), RAG (Retrieval-Augmented Generation)/AI-agent (drafts cited underwriting recommendations) — called by flows as black-box services.
Every vendor's API in/out + indicative cost, the tiered call waterfall, our storage tables + TTL/event refresh criteria, and the field → provision/option mapping.
Black-box rule: a flow never reaches into another flow's database. It only emits/consumes the versioned events on the spine (carrying shared IDs that match records across flows — join keys like policy_id). So "Product Design" can be built, deployed, and scaled on its own, and Underwriting just sees "give me product version X effective on date D." (How product versioning works ↗)
Start minimal, grow: every flow begins as serverless Cloud Run + a single Cloud SQL database. You add a read replica, a CDN, a queue, or event-sourcing only when that flow's load demands it — not up front. This is the opposite of over-engineering.