BLK 12Frontier · 🔵🟣 · ≈3 h+ · rubric-scored project

Capstone — modernise a
Galileo-class platform

Everything converges here. You are the architect advising an insurer whose custom core — ledger-first, event-driven, production-proven — is mid-replacement. Propose what the next platform should keep, drop, and add.

LO8 · the full-course synthesis

§1The scenario

◐ Briefing

Client: a PH life insurer running a Galileo-class core: C# microservices, commands through a 3-node private blockchain audit ledger, Kafka to MongoDB read models, ~1.1 M policies, distribution via super-apps (GCash-style), currently migrating to a COTS core (eBao-style) with an ESB translation layer and an ID-mapping table for coexistence.

Board asks: "As we replatform, which ledger capabilities do we keep or rebuild, what new products do they enable, and how do we make our coming AI claims automation regulator-proof? Give us a 3-year architecture."

§2Deliverables (the pack)

#ArtifactContents · draws on
D1Target architecture (1–2 diagrams + narrative)Core platform, audit-ledger decision (keep chain / signed log / ledger DB — argue it), event backbone, AI layer with anchored decisions, payment rails. · M01, 05, 07, 09–11
D2Platform selectionScored matrix (M03 worksheet) for the ledger + any consortium/public legs; one page defending the weights, not just the winner
D3Product proposalOne parametric product (typhoon rider or embedded flight cover) with trigger design, oracle governance, basis-risk disclosure, distribution — and its regulatory questions · M05–06
D4Auditable-AI designDecision-record schema, anchoring rule, escalation policy, regulator replay procedure (Exercise 11.1, matured)
D5Risk register≥10 risks with owner + mitigation — must include: oracle failure, consortium funding (B3i test), key custody, PII/erasure, vendor lock-in, migration coexistence, model drift · M03, 08, 09
D6PoC plan90-day proof scope with success metrics and a kill criterion (what result cancels the programme — write it before you start)

§3Reference architecture (starting point — improve on it)

Core insurer estate COTS core / PASpolicy · claims · billing AI decision layertriage · UW copilots + guardrails Audit ledgerevents + AI decisions,hash-anchored Event streamprojections · analytics ESB / APIssuper-app channels Verifier portalauditor/regulator proofs Oracle networkweather / flight feeds for parametric riders Public L2 legparametric contracts · stablecoin settlement Bank railstokenized deposits / SWIFT fallback Hybrid by design: permissioned audit spine inside; public L2 + oracle legs for parametric products; payment rails chosen per counterparty (M09).
Fig 12.1 Reference sketch. Your D1 should argue with at least one element of it — that's what "reference" means.

§4Scoring rubric

Criterion1 · weak2 · developing3 · solid4 · distinguished
Framework disciplineBlockchain everywhereFramework cited, not appliedEach ledger use passes M05's three questions…and one tempting use case is explicitly killed with reasons
Technical soundnessHand-wavy boxesRight shapes, wrong detailsConsistency, custody, PII, oracle governance all addressed…with failure runbooks and an outbox-grade integration design
Domain fluencyGeneric tech talkSome insurance termsLifecycle, reinsurance, compliance woven through…with regulator-facing artifacts (replay procedure, disclosures)
Evidence useVendor forecasts as factsSome cases citedChoices justified by M08/M09 precedents incl. failures…B3i/fizzy/Contour tests applied to its own weak points
Decision qualityNo trade-offs shownOptions listedClear recommendation + rejected alternatives…plus kill criterion and 90-day falsifiable PoC

Self-score honestly, or better: swap packs with a colleague and score each other. 15+/20 with no criterion below 3 = capstone passed.

§5Submission checklist

✦ After the capstone

You now hold an unusual combination: ledger literacy, insurance domain fluency, the real deployment map across two industries, and an auditable-AI design pattern. Keep the company tracker alive (statuses rot fast in this field), re-run the M03 worksheet whenever a vendor pitches, and be the person in the room who asks the B3i question.

Scenario details generalised from the Galileo dossier. This capstone produces advisory artifacts — real programmes add legal, actuarial and regulator engagement from day one.