← Atlas Journey · Docs

Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.

Atlas system context against the supplied reference

Status: reference comparison, amended 2026-09-30. This page describes accepted Atlas decisions and distinguishes code that exists from planned migrations. It does not adopt the reference diagram's vendors, actors, or infrastructure. ADR 0008, ADR 0009, ADR 0010, and the schema/transport amendment remain authoritative.

The supplied diagram has a useful sequence: actor, experience UI, experience API, workflow, integration, and systems of record. Atlas keeps those responsibilities, but places them differently. Its first deployment target is a locally certified prototype using synthetic records; cloud promotion follows that gate. The diagram below shows the selected Atlas boundaries, not a claim that every planned journey is implemented.

flowchart LR

    A[Customer / employee / manager / reviewer / employer admin] -->|HTTPS| UI[React 19 + TypeScript + Vite SPA]

    UI -->|Same-origin HTTPS tRPC and auth| EDGE[Local Caddy gateway]

    EDGE --> BFF[TypeScript + Fastify BFF]

    TB[TypeBox boundary schemas: planned] --> BFF

    BFF <-->|OIDC code + PKCE; server session| IAM[Keycloak + TOTP MFA]

    CMS[Contentful bilingual published content] -->|Versioned definitions| REL[Release compiler and registry]

    REL --> BFF

    BFF <-->|REST present; supported gRPC commands planned| BPM[Camunda 8 BPMN]

    BFF -->|Owner commands, outbox, queries| SOR[Modular synthetic business owners]

    SOR --> PG[(PostgreSQL records and sessions)]

    SOR --> ADAPT[Private legacy and payment simulators]

    SOR --> DOC[Private versioned document storage]

    DOC --> SCAN[ClamAV scan gate]

The local case and private evidence slice are delivered; product-specific simulators, TypeBox adoption and gRPC migration are still being built or planned as marked. The BFF assembles each server-driven screen from the case's pinned Contentful release, its authorized business data, and Camunda's task state and logical form reference. React renders that model. Contentful owns field definitions and declarative validation; Camunda does not own a competing JSON form schema or submitted answers. See the form contract and workflow contract.

Reference boxAtlas alignmentCurrent position
Member, employee and managerCustomer/employee and manager experiences use distinct business contexts under one login.In scope.
Dependent as portal actor; broker/adminDependents and beneficiaries are business relationships. Delegated dependent transactions and broker access are outside the approved demo. Employer benefits administrator and insurer reviewer are separate roles.Do not infer portal access from the reference.
React 18 shell and responsive PWAAtlas uses React 19, TypeScript and Vite. It targets responsive screens; offline service-worker behavior is not selected.SPA exists; do not label it a PWA yet.
Camunda JSON dynamic form engineThe Atlas SDUI renderer consumes BFF screen models compiled from Contentful. Camunda selects a logical task screen and actions. Autosave belongs to the draft owner.Bilingual drafts and a generic case/RFI path exist.
Contentful GraphQL, layout and assetsContentful is the authoring source for bilingual form/content definitions. The BFF imports a versioned release. Private evidence is never a Contentful asset.Contentful SaaS is selected; Atlas currently uses delivery/management APIs, not a GraphQL contract.
CloudFront, WAF and S3The local gateway is loopback Caddy. A hosted static UI plus one cloud VPS is selected after local certification; the static host, edge protection and VPS provider are not chosen.No AWS or edge-vendor commitment.

[Private setup detail omitted.]

MuleSoft Experience APIs and integration fabricA TypeScript/Fastify BFF and private adapters own experience aggregation and simulated system mapping. PostgreSQL-backed operations/outbox provide durable delivery.MuleSoft/CloudHub is deferred to a later phase.
Java 21 / Spring Boot BFFAtlas selected TypeScript/Fastify. Logical business owners can share a deployable backend without losing record boundaries.No Spring Boot service.
BFF schemas and internal RPCTypeBox is selected for code-owned JSON Schema contracts. gRPC is selected for suitable private adapters. ADR 0013 selects tRPC over HTTPS for the React-to-SDUI BFF boundary.ADRs 0011 and 0012 are accepted; TypeBox, private gRPC and tRPC migration require implementation evidence.
OPA policy engine and RedisKeycloak supplies identity; owner modules enforce current business permissions and field allowlists. PostgreSQL stores sessions and owner records.Neither OPA nor Redis is part of the selected prototype.
Camunda 8 BPMN, DMN, workers, Operate/TasklistCamunda owns process/task state. Atlas serves its own authorized task UI. Product BPMN, workers, timers and recovery grow by slice. DMN, Optimize and a user-facing Tasklist are not approved prerequisites.Generic case and RFI BPMN run locally; broader journeys remain open.
Fineos, SkyGen, GIFS, Member 360, OneInc and enterprise document storeAtlas has synthetic, persistent business owners; broader simulated legacy/payment paths are being built. Documents use a private versioned store and real ClamAV scan gate.No connection to named enterprise systems or real money.
Anypoint MQ, gateway policies, AWS ECS, multi-AZ, CDK and named DevSecOps vendorsAtlas uses an owner outbox and idempotent contracts. Local Docker Compose precedes a single-VPS prototype. CI, observability, backup/restore and security checks remain acceptance work; no named AWS or tool subscription is implied.Production HA and autoscaling are outside prototype scope.

Misalignments to decide, if Atlas should move closer to the reference

  1. Actor scope. Should brokers or dependent representatives gain portal transactions? The accepted role matrix currently defers them. Adding either changes authorization and test scope across journeys.
  2. Decision policy. Should a later phase use Camunda DMN or a separate policy engine for product eligibility? Current fictional rules live in the authoritative business modules; the generic case makes no product decision. A rules engine should be chosen only when the product slices show a real authoring/versioning need.
  3. Hosted edge and operations. The reference assumes AWS CloudFront/WAF/S3, ECS, multi-AZ and a named DevSecOps stack. Atlas's approved prototype uses local certification and then a hosted static UI with one VPS. #45 Choose hosted provider and budget is the owner gate for the provider; the later promotion gate must prove the real HTTPS, cookie, upload and recovery route.

These are discussion points, not blockers for the current synthetic case, evidence, or recovery slices. The existing record ownership diagram predates the BFF decision and still names MuleSoft as the experience mediator; read this page with the later ADRs for the current implementation.