Independent prototype · Synthetic data
Atlas ClaimsClear evidence.
A considered next step.
A claims-workflow prototype that connects queue priorities with inspectable evidence and an explicit next action.
Explore the interface01 / The workflow question
Help the reviewer
find the next action.
Atlas explores how a claims workspace can connect queue priorities, source evidence and a proposed next step. The challenge is to make action easier to understand without making a summary look like an unquestionable decision.
Start with the work
Keep due states, readiness and next actions beside each queue item.
Keep sources available
Let a reviewer inspect what is present and what is missing.
Explain the suggestion
Use explicit demo rules and leave the decision with a human reviewer.
Prototype context: all records are fictional. Role selection and requests are simulated; no real claims or messages are involved.
02 / Layout decisions
Make each queue decision
easier to inspect.
These panels examine the same officer-workspace layout. Three summaries establish the queue conditions; the table aligns related facts; Preview sits alongside the proposed next action.
- Summarise the queue. Needs attention, Due soon and Evidence incomplete form three separate overview cards.
- Keep facts on one row. Claim, status, due date, readiness and next action share a consistent column order.
- Keep inspection close. The Preview control sits beside the suggested action for the same fictional record.
03 / Low to high fidelity
Trace the real workflow,
screen by screen.
The wireframes reconstruct the exact views shown beside them. The queue keeps its top navigation, three summaries and table controls. The evidence view keeps the original scrolled crop and its received and missing source states.
Officer workspace
Evidence review — scrolled view
04 / The officer workspace
A queue with context,
not just a status.
Small summaries orient the reviewer, then the queue carries the detail. Due states, readiness and suggested actions sit in each row; filters and sorting provide direct ways to narrow the work.
The decision: put the reason to inspect a record beside the link that opens it.
05 / Reviewing a record
Move from a suggestion
to its source.
The two real views connect the work queue with the evidence behind a record. The evidence screen exposes source status instead of asking a reviewer to trust a summary alone.
The queue · Compare the fictional records by due state, readiness and next action.
Screen walkthrough · Actual queue and evidence captures from the synthetic-data prototype. Choose a view or press Play.
06 / Missing information
An empty state
is useful information.
Received and missing sources use explicit labels. A missing document remains visible as a gap; the interface does not fill that gap with a convincing-looking mock summary. Source references stay attached to their cards.
The trade-off: summaries can reduce scanning effort, but source status must remain easier to verify than a suggested conclusion.
07 / From interface to rules
The action needs
a reason to be allowed.
A clear button is only one part of a reliable interaction. The request-information rule checks the record and its selected evidence before returning an allowed or rejected result to the interface.
Check the context
Assignment, claim state and record version must match the demo action.
Check the sources
Selections must belong to this claim, be missing and contain no duplicates.
Check the request
The template must exist and permit the selected evidence types.
Why this matters: a visible explanation and an explicit rejection state should agree with the rule that controls the action.
Inspect the implementation evidence
The preserved transition excerpt includes checks for assignment, claim state, stale versions, duplicate selections, missing evidence and template compatibility. These are prototype rules; simulated roles are not production authentication.
08 / Outcome and development evidence
A connected workflow.
Clear boundaries.
The prototype joins queue prioritisation, source review and a simulated request for missing information. The learning was to treat explainability as an interface responsibility: make the suggestion, its sources and its limits visible together.
Recorded test passes
The preserved run is dated 8 September 2026.
Test files
Transition rules, fixtures, queries and related prototype checks.
Real claims
The workflow uses synthetic demonstration data.
Historical development evidence · The counts describe the saved test run, not a newly measured user outcome.
Read the checks and their limits
Read the recorded Vitest run ↗
The prototype was built with AI coding assistance. Passing development tests does not establish production security, insurance compliance or usability with claims professionals. Activity is session-only demonstration data, and no reduction in processing time has been measured.
09 / Next phase
Put the workflow
in front of a reviewer.
The next phase would test whether the interface communicates the right information to someone who understands claims work, then strengthen the areas a local demonstration cannot establish.
A useful suggestion
can explain itself.