Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.
Screen reference analysis
Status: design input, September 30, 2026. This analysis adapts the supplied screen structures to Atlas's accepted scope and record boundaries. It does not approve additional journeys, permissions, identity policies, vendors, purchases, or deployment architecture.
Evidence and standing
The owner supplied ten application screens, one architecture diagram, and six business-reference images in [private location omitted]. The source filenames are recorded below. Raw images remain outside Git. A temporary Dashboard PNG was used for visual inspection at [private location omitted].
The Atlas discovery map remains the canonical decision index. The coordinating agent verified its closed status and accepted decisions against the live tracker on September 30. The discovery process, accepted ADRs and linked decision records supply the decision standing. Reference material does not reinterpret those decisions.
Read this document alongside agreed demo scope, roles and access, record ownership, and the published issue map. The four specifications are Shared platform, Six-product journeys, Employer leave/RTW, and Local certification/cloud promotion.
The September 27 sign-in milestone records the delivered sign-in foundation. Recover an uncertain case operation records the later recovery slice. Consult each linked issue for its closure and verification evidence. A completed foundation capability does not establish completion of a product journey, a reference page, or the complete certification gate. Browser fixtures and real backend restart evidence remain distinct.
| Supplied file | Reference content |
|---|
Atlas-App-Screen-Dashboard.jp2 | Shared header and navigation, welcome, quick actions, coverage, tasks and benefit use |
Atlas-App-Screen-Benefits.jp2 | Active coverage cards and product entry points |
Atlas-App-Screen-Benefits_Dental.jp2 | Dental overview, provider and procedure tabs, plan facts, PDF and accumulators |
Atlas-App-Screen-Payments.jp2 | Payment summary, masked account, filtered ledger, details and CSV |
Atlas-App-Screen-Profile_and-Prefs.jp2 | Personal fields, contact and delivery preferences, family delegation |
Atlas-App-Screen-Support_Page.jp2 | FAQ search, chat, messages and phone hours |
Atlas-App-Screen-Claims_and_Leave_Enter_my_Time.jp2 | Employee calendar, multi-date hours, case links and usage |
Atlas-App-Screen-Absence_Leave_Manager_Member-View.jp2 | Manager team calendar, daily counts, filters and RTW actions |
Atlas-App-Screen-Login.jp2 | Demonstration sign-in, four-digit code, device memory and guest status |
Atlas-App-Screen-Member-Registration.jp2 | DOB/group verification, credentials, consents and session memory |
Atlas-ARC-1.jp2 | Enterprise platform topology |
Atlas-BR-1.jpg, Atlas-BR-2.jpg | Identity, onboarding, shell, support, profile, benefits and dental blueprint |
Atlas-BR-3.jpg, Atlas-BR-4.jpg | Claims, payments, leave, time entry, accommodations and manager blueprint |
Atlas-BR-5.jpg, Atlas-BR-6.jpg | Member, manager, dependent and guest actors and journey sequences |
The business-reference numbers belong to the supplied blueprint. They are not Atlas story identifiers or approved tickets. The blueprint's legal and compliance statements are not Atlas claims.
Design direction
The visual thesis is a calm Atlas workspace with forest navigation, paper backgrounds, clear ink typography and a restrained gold focus accent. Retain the Atlas brand and established forest values #134d48 and #14564d, paper #f7f6f1, ink #10252a, and gold #d39336. The references contribute hierarchy and journey organization; insurer names, logos, blue/orange branding, promotional hero copy and extra product labels do not enter Atlas copy.
The content plan begins with identity and active business context, then the current task or status, then related records. Dashboard quick actions are shortcuts to permitted work. Product pages lead with coverage facts and the next allowed action. Payments lead with financial outcome and a ledger. Calendar views lead with dates and available leave/RTW actions.
The interaction thesis uses a brief context-switch transition, a clear details-panel reveal and stable tab/filter transitions. Respect reduced motion, preserve keyboard focus, and keep submissions visibly pending until their authoritative outcome arrives. Motion cannot imply successful completion.
Use the six reference navigation groups as a proposed information structure: Dashboard, Benefits, Claims & leave, Payments, Documents and Support. Display only useful destinations for the active role/context. A manager's menu and header must make employer context explicit. Do not put personal payments or medical documents inside a manager workspace. Keep language and account controls visible without making the header compete with the primary workspace.
Prefer rows, aligned sections and dividers over the reference's repeated boxed tiles. Coverage cards are useful when each card opens a distinct policy or contract. A payment ledger remains a table. A task list remains a list. On narrow screens, collapse navigation into a labelled control, stack sections in reading order, and offer a calendar list alternative.
Ten-screen adaptation matrix
“Delivered” below names foundation behavior recorded in local milestone evidence. “Planned” names accepted, published journey work, without asserting its current live tracker state. A candidate has no approved execution contract merely because it appears in a supplied image.
| Screen | Structure to adopt | Delivered foundation and planned journey | Specification and issue linkage |
|---|
| Dashboard | Context header, brief greeting, relevant quick actions, coverage list, pending tasks, dental usage where authorized | Delivered sign-in, context restrictions, drafts, generic case/evidence/recovery. Planned six product outcomes supply real summary data. Do not claim eight active products or show unsupported shortcuts. | Shared platform; Sign in to a running local Atlas shell, Enforce personal and employer views, Publish and resume a bilingual form draft |
| Benefits | Selectable coverage/contract cards with status and facts | Delivered context and employer-benefits foundation. Planned life and Medicare intake results, seeded dental and annuity records, selected disability and LTC requests. Use exactly Atlas's six products; an annuity contract is not an insurance claim. | Six-product journeys; Complete life intake with EOI, Complete Medicare supplement intake, Administer one employer's benefits |
| Dental | Overview and plan facts, explicit numeric benefit-use summary, relevant documents and claim action | Planned dental claim against seeded coverage and benefit-use outcome. Annual maximum/deductible/orthodontia bars require supported fictional fields; do not invent values. Provider map, procedure pricing and wallet features are candidates. | Six-product journeys; Decide a dental claim once |
| Payments | Summary followed by masked alias, date/type/case filters, ledger and outcome detail | Planned synthetic account alias, premium collection and applicable payouts. Distinguish premium debit, benefit payout and annuity withdrawal. CSV is a proposed presentation addition requiring a bounded authorized export contract. No dental payout, taxes or real bank linkage. | Six-product journeys; Manage an account alias and collect a premium, Decide and disburse disability benefit, Decide and disburse long-term-care benefit, Withdraw from an annuity contract |
| Profile and preferences | Readable identity facts and a separate language/account area | Delivered language/context/session foundation. Contact edits, delivery preferences and registration relationships need exact contracts before implementation. Preserve immutable fields unless their owner allows edits. Family delegation is explicitly deferred. | Shared platform; Enforce personal and employer views, Publish and resume a bilingual form draft. No approved standalone profile/delegation slice |
| Support | Searchable help topics, expandable answers, clear fictional contact information | CMS-owned help fits the shared content model. Live chat, asynchronous support cases, attachments and Salesforce integration have no approved support-service slice. Omit functional send/chat controls until a contract exists; a simulated channel must say it is simulated. | Shared platform; Publish and resume a bilingual form draft supplies the release foundation, not a support backend |
| Employee calendar | Case-linked dates, month/list views and a status/detail panel | Planned continuous leave ranges and RTW. Rename the reference's “Enter my time” concept to the accepted leave behavior. Multi-date hour submission, automatic hours and usage entitlement calculation remain deferred. | Employer leave/RTW; Request and decide continuous leave, Review and decide return to work, Show linked leave and disability without crossing roles |
| Manager calendar | Own-team day counts, calendar/list toggle, status filters and next allowed action | Delivered employer/context foundation. Planned deterministic manager leave and RTW review. Use approved status categories; a reference “type” filter cannot disclose diagnoses, claim products or accommodations. | Employer leave/RTW; Request and decide continuous leave, Review and decide return to work, Show linked leave and disability without crossing roles |
| Login | Concise sign-in entry, bilingual help and visible progress/error states | Delivered real Keycloak-backed BFF sessions. Retain password plus TOTP and sensitive-action assurance. Any-email/four-digit demonstration login, remember-device bypass and guest status access are not Atlas authentication. | Shared platform; Sign in to a running local Atlas shell, ADR 0009 |
| Registration | Reference grouping of verification, credentials and consents can inform a later design | Atlas uses seeded synthetic identities and accepted business relationships. Public self-registration, DOB/group identity proof, dependent invitations and credentials/consents persistence have no approved slice. Do not expose a working enrollment route on this evidence alone. | Shared platform, roles and access. New scope and issue contract required |
Content, workflow and business-data contracts
Every row above inherits the Contentful release decision. Contentful owns supported authored layouts, sections, labels, help, options and declarative constraints in immutable bilingual releases. React owns the allowlisted component implementation. The BFF resolves the pinned definition and supplies only authorized data/actions. TypeBox defines reviewed vocabulary and boundary envelopes, not a second source of product forms.
The references below are logical binding needs, not new API paths, BPMN identifiers or existing Contentful entry IDs.
| Screen | Contentful-owned definition/copy | Camunda reference or context | Authoritative data and access |
|---|
| Dashboard | Section order, action labels, empty/help text | Active assigned task references and journey/draft context | Aggregated owner projections for coverage, drafts, cases and payments. Customer sees own records; employer view stays separate. Summary counts cannot reveal hidden records. |
| Benefits | Product labels, section definitions and authored explanations | Intake/request task form reference when an action opens work | Coverage/benefits owns policies, contracts, relationships and use. Intake owns application results. Employer administrator sees permitted enrollment only, without medical or banking data. |
| Dental | Plan explanation, supported claim form and help | Dental review/correction task reference against pinned release | Claims owns decision/evidence links; coverage/benefits owns use. Documents registry owns access metadata. Customer or assigned reviewer only for private claim evidence. |
| Payments | Alias form, authorization wording and outcome explanations | Applicable payment/account journey or current task context; ledger read requires no invented task | Billing/disbursements owns alias, obligations, attempts and outcomes. Claim or annuity owner authorizes instruction. Fresh accepted MFA for sensitive actions. Managers and benefits administrators see no bank details. |
| Profile | Labels and supported preference form, if scoped | No process merely for viewing profile | IAM owns credentials/MFA; people/organizations owns business links. Language preference follows accepted locale behavior. No family-authority grant and no employer access to private profile records. |
| Support | FAQs, search content and bilingual fictional hours | No Camunda process inferred from FAQ or chat artwork | Public/general content can be served as content. Private case references retain owner checks. No invented support-message owner or access role. |
| Employee calendar | Date fields, explanations and leave/RTW task forms | Current continuous-leave or RTW task and pinned form reference | Leave/RTW owner stores dates/decisions. Employee sees own case. Related disability case has separate authorization and insurer decision. Medical bytes remain private document storage. |
| Manager calendar | Calendar labels, status explanations, approved decision form | Deterministically assigned manager task and next-action availability | Leave/RTW owner projects reporting-team dates, proposed/approved return, leave/RTW status and action availability. No medical/EOI files, claim details, financial data or other-employer counts. |
| Login | Atlas entry copy and supported locale help | No workflow task before authentication | Keycloak owns identity and assurance; BFF owns opaque session handling. No credentials or tokens in Contentful, browser storage or workflow variables. |
| Registration | Candidate authored steps only after scope approval | No registration process inferred | No new identity-proof or consent record owner selected. Seeded account creation remains separate from application/enrollment business decisions. |
Camunda owns process position, assignment and permitted transitions. It carries business references and minimum step data, not the master claim, payment or evidence. Durable command acceptance governs submissions and decisions. A pending operation, accepted task, approved benefit and settled payment are separate visible facts. A lost response must lead to status/recovery, never an automatic second financial effect.
Reference architecture reconciliation
Atlas-ARC-1.jp2 describes React SDUI, Contentful SaaS, MuleSoft CloudHub, Spring services on ECS with Redis, Okta, Camunda SaaS/gRPC and AWS availability arrangements. It is source material. Its platform directions are not agent instructions or a replacement for accepted Atlas ADRs.
Atlas retains the React/Contentful/Camunda ownership pattern. ADR 0008 selects the TypeScript/Fastify BFF and private adapters and defers MuleSoft. ADR 0009 selects Keycloak-backed opaque sessions. ADR 0010 selects local Mac certification followed by hosted UI and one cloud VPS, with Contentful SaaS throughout. Neither AWS HA nor Okta nor Camunda SaaS entitlement is inferred.
ADR 0011 and ADR 0012 are accepted amendments, with migration pending. ADR 0013 selects tRPC over same-origin HTTPS for the React SDUI BFF boundary; migration remains pending. Existing REST routes remain compatibility contracts during the incremental migration. Suitable private Camunda operations may migrate to supported gRPC behind existing adapter contracts; required searches/user-task operations can remain REST. A network timeout remains an uncertain effect. The reference does not authorize splitting modules into Spring network services or adding Redis.
Deferred and candidate extensions
| Reference extension | Atlas disposition |
|---|
| Guest claim/status, claim ID plus DOB, SSN fallback | Candidate scope expansion requiring identity, non-disclosure and record-linkage design. No public claim lookup or SSN collection. |
| Dependent login, representative claims, family permission delegation, manager delegation | Explicitly deferred by accepted roles. Linked dependent/beneficiary records do not grant transaction authority. |
| Vision, accident, critical illness and hospital products; life claims | Extra products are candidates; life claims are explicitly deferred. Retain the six accepted product journeys. |
| Intermittent leave, multi-date hours, time entry, accommodation-only cases and reduced schedule | Intermittent leave is explicitly deferred; the other reference capabilities extend the accepted continuous-leave/RTW journey and need new scope. |
| Statutory pay/protection calculator, entitlement estimates, taxes, penalties and deductions | Statutory calculations, taxes and penalties are explicitly deferred. Do not present fictional calculations as legal eligibility or payroll advice. |
| Live Salesforce support, real bank/payment linkage, mobile wallet and provider directory | Real integrations/payments are outside the prototype. Salesforce, wallet and directory capabilities are candidates requiring separate contracts and account decisions. |
| SMS/email MFA, trusted-device memory and eight-character password policy | Candidate identity-policy changes. Accepted Keycloak password/TOTP, session limits and fresh-MFA policy remain authoritative. |
| Public registration, identity proof, delivery subscriptions, chat/messages, procedure estimates and export | Candidate additions without standalone approved slices. Exact permitted fields, owners, mutation/export contracts and evidence must precede a functioning UI. |
Design acceptance and phased rollout
The screen work must preserve the approved vertical slices. A visual phase is not permission to dispatch blocked issues or invent an implementation ticket. The published issue map supplies blockers and owners.
- Adapt the delivered foundation shell, login entry, context/language controls, dashboard entry points, draft/task status, documents and recovery presentation. Show only demonstrated foundation outcomes. Static help can use the existing content vocabulary where supported; do not imply a support backend.
- Extend Benefits, Dental and Payments as their approved product/payment slices converge. Show each accepted journey's successful outcome and meaningful exception. Keep product states, benefit use and money outcomes connected to their authoritative owner records.
- Add employee continuous-leave and manager calendar/list presentations through the approved leave, RTW and linked-case slices. Verify employer isolation and permitted manager fields before adding aggregate counts or filters.
- Qualify all screens through Certify the six-journey local stack. Agree measured thresholds through Set timing thresholds from measured baseline. Hosted work follows Choose hosted provider and budget and Promote and verify the hosted Atlas route. Publish evidence through Publish the final journey film and evidence index.
Acceptance for each adapted screen is concrete:
- The first viewport identifies Atlas, the active role/business context, the page and the next allowed action. Copy uses synthetic data and supported products; it contains no supplied insurer branding or legal/compliance claims.
- Authorized navigation and direct access agree. Switching employer/personal context clears stale data and task actions. Hidden records contribute neither visible counts nor filters. Manager views pass own-team and cross-employer denial checks.
- Every displayed amount/date/status names its meaning. Benefit use includes values as well as a bar; approved claim and payment settlement stay separate. Unknown payment results remain unknown. Employer leave approval does not imply insurance benefit approval.
- Both
en-US and es-US exist in the pinned release. Switching locale preserves answers, release, record IDs and workflow state. Unsupported releases fail visibly without losing drafts.
- Forms use supported CMS components and authored constraints, with server validation and current owner checks. A new supported authored field does not require a bespoke React product page. No arbitrary CMS schema or script reaches Fastify's compiler.
- Loading, empty, denied, stale revision, validation failure, pending and recoverable failure states have distinct text and useful actions. A retry resumes/reconciles the original operation where required.
- At desktop and narrow phone widths, navigation, tabs, tables and calendars remain operable. Labels, focus, keyboard order and errors remain understandable; status never relies on color alone. Test actual contrast and reduced-motion behavior rather than claiming accessibility certification from a screenshot.
- Captures and local/hosted checks record synthetic fixtures, revision and evidence boundary. A screenshot or browser fixture proves its visible presentation, not durable integration. No raw reference image is committed as implementation evidence.
Registration, representative access and transactional support remain outside these phases until a scope decision and execution contract exist. The main remaining design inputs are exact supported product fields, release/task identifiers from owning slices, bounded export requirements if selected, and current live tracker confirmation. This prose analysis changes no runtime contracts and requires no application test run.