Containers - C4 Level 2

One container view per business capability, plus the shared Platform Infrastructure. Each view zooms in on the containers a capability owns plus the cross-system containers it touches (other capabilities' services, platform rails, externals).

Source of truth

Defined in /root/olly/docs/architecture/workspace.dsl - change the DSL, rerun regen.sh. Each diagram below deep-links into ↗ structurizr.dev.hiolly.com.

Triage & Care

AI-led triage agent (Python / PydanticAI), care pathway service (Go), Triage Chat UI. Touches GrowthBook for narrower levers, Langfuse for LLM trace audit, and Google Gemini (Gemini Flash, europe-west2) for inference.

Membership & Enrolment

Enrolment, eligibility, policy-admin, group-scheme, consent + the Employer Portal. The "who is covered" capability.

Claims & Adjudication

Claim intake + adjudication + prior auth. Cross-system reads to Membership (eligibility) and downstream events to Billing (payouts) and Member Experience (notifications).

Billing & Premium Collection

Invoicing, premium collection, dunning, payouts. Plus document-service for rendered statements + e-sign. Money out goes via Payment Rails. 🚧 Target-state - not yet built: long-term ETL to a Snowflake data lake (the analytics warehouse is an open decision, #171/#183; nothing is wired today).

Provider Network

Directory + credentialing + contracts. Provider Portal for clinics. FHIR sync to Provider EHRs through Mirth.

Brokerage

Broker quote / bind / commission. Broker Portal for distribution partners. Bind issues a policy through Membership & Enrolment.

Member Experience

Consumer touchpoints: Member Portal (PWA), Mobile App (Expo), AI Chat, the member-portal-api BFF, and the notifications layer that fans events into Novu workflows.

Platform Infrastructure

Shared rails every capability uses: nginx + APISIX at the edge, Keycloak for auth, OpenBao for secrets (Transit encryption is a design, not yet wired), Temporal for sagas, Postgres / Valkey / Kafka / OpenSearch for data (one Postgres, single-broker Kafka; Snowflake is a 🚧 target-state warehouse, not deployed), GrowthBook / Novu / Mirth / Scalar for cross-cutting, the Admin Console + MCP Server for ops, and the full OTel-fed observability stack (Tempo / Loki / Prometheus / Grafana / Gatus / Langfuse).

Member Onboarding (MEM-ONB)

Member onboarding is a cross-capability flow, not a capability of its own. It spans Membership & Enrolment (Employer Portal, group-scheme, enrollment, policy-admin which owns the parties table + the surviving link endpoints, and identity which owns verify-pin + mint-with-pin - extracted per #1161), Member Experience (Maat Admin Console, Member Portal, Mobile App, notifications), Platform Infrastructure (nginx, APISIX, Keycloak, Valkey), and two external delivery rails (Gmail SMTP for the emails, Google Identity for id_token verification).

Architecture note. group-scheme is the BFF for Flow 0. The Employer Portal makes a single POST /api/group-scheme/{scheme}/members call with {firstName, lastName, email, planTier}; group-scheme composes everything server-side - mints the party + 5-digit PIN via the identity service (POST /internal/parties/mint-with-pin, which in turn creates the party in policy-admin via POST /internal/parties since identity is DB-free - #1161), issues an individual policy for the member (enrollment, per Epic #219 member-level policy model - every member is on their own policy, not a shared group-master), and triggers the activation email (notifications). FE never fans out; it receives a single envelope. See BP-EmployerAddsEmployee for the sequence.

Four flows share this surface:

• Flow 0 - HR self-serve (PRIMARY): HR signs in to the Employer Portal and adds an employee. group-scheme composes party mint + individual-policy issue + PIN allocation + activation-email trigger as a single server-side transaction. Status today - the frontend/backend contract on POST /schemes/{locator}/members is mismatched (frontend sends {firstName,lastName,email}, backend expects {memberPartyLocator}); no party is created, no email triggered; group-scheme has no policy-admin or notifications client wired. Only the bulk-enrolment path is shipped end-to-end. Hops tagged ⏳ in the diagrams below are aspirational.
• Flow A - Maat PIN (INTERNAL FALLBACK): Maat Admin surface provisions + emails a 5-digit PIN, member enters it, JWT minted via ROPC. This was the primary path before Flow 0; retained as the fallback for edge cases.
• Flow B1 - secondary-email magic link: signed-in member proves they own another email via a 15-min single-use token in Valkey.
• Flow B2 - link-Google: signed-in member links a Google account by presenting a Google-signed id_token verified against Google's JWKS.

Inline C4 Container view (for readers who don't want to spin up Structurizr):

Related:

• Epic #313 - MEM-ONB parent epic on the MVP Journeys board (the top-level ticket this whole surface implements).
• Epic #219 - Member-level policy model - every member gets their own policy linked to the scheme (not a shared group-master). Drives the group-scheme BFF composition.
• Impl ticket #1164 - Flow 0 BFF wire-up (in flight). 4-hop composition (party mint → policy issue → PIN allocate → activation email), FE contract fix, JWT org_locator scoping fix, idempotency middleware, notifications SMTP wire-up.
• Discussion #1160 - MEM-ONB consolidation (surface + relationship audit + Flow A/B1/B2 sequence diagrams in §10).
• Issue #1161 - SRP-extraction: the auth/onboarding surface (verify-pin, mint-with-pin, the Keycloak admin client, the internal-service guard) was pulled out of policy-admin into a dedicated identity service (DB-free: Keycloak + Valkey + a policy-admin POST /internal/parties hop). Parties stay in policy-admin. When PR #1159 merges, the magic-link / OTP / secondary-emails / link-google surface lands in identity too (shares the moved KC admin client).
• Sequence-level views for each flow: BP-EmployerAddsEmployee, BP-MemberOnboarding, BP-SecondaryEmailLink, BP-LinkGoogle.