EY's analytics managers were working across VIA, IRL, Symphony, Nexus, and a dozen other risk tools — manually compiling data, switching contexts, losing the thread. RAP was scoped to fix that. It started as a canvas that could hold multiple tools in one place. It ended as something more: an AI-assisted digital twin of the enterprise — a simulation that four very different roles could steer through a single conversation.
The first version of RAP wasn't a digital twin. It was supposed to be one place where an analytics manager could open VIA, IRL, Symphony, Nexus, Cyber, and Supply Chain — all the EY risk tools they were already using — without re-authenticating, re-orienting, and re-scoping every five minutes. The brief was straightforward: stop the toolchain bleed.
But containers for tools have a property nobody quite planned for. Once you put VIA's output next to IRL's output next to a process map in the same canvas, you stop looking at "tools" — you start looking at an assembled view of the enterprise. Exception data from one tool. Control library from another. Process imprint from a third. Held together by a shared scope ("SOX Audit 1245") and a shared timeframe. The canvas, almost accidentally, was a digital twin.
That's the pivot that defines this case study. RAP was scoped as a UI integration project. It became a model-building project. Solving the fragmentation problem and building the digital twin turned out to be the same problem.
Once that pivot was visible, the design vocabulary changed. We weren't designing a dashboard anymore — we were designing the surface of a probabilistic engine. The interface had to carry uncertainty, support what-if exploration, and earn the user's trust in outputs the user did not personally generate. That's a different design discipline, and it's what this case study is really about.
A dashboard shows what happened. A digital twin shows what could. The pivot from one to the other started with a much smaller question — "can we open multiple tools in one place?" — and ended somewhere much bigger.
A risk analyst at the start of a SOX audit has the following on their desk: a SAP transaction extract in one window, EY VIA in a second, the Integrated Risk Library (IRL) in a third, a process map in a fourth, and a spreadsheet pulling it all together in a fifth. Two monitors. Sometimes three. The work isn't analysis — the work is keeping the cross-references aligned across five windows.
This was the day the project started from. The original brief named the pain precisely:
The reframe that changed everything: the integration target wasn't "a unified dashboard." It was a unified model. And the canvas that held multiple tools at once was the substrate that made the model possible.
The first useful piece of research was a framing exercise with the audit and risk team. The questions that surfaced were not about features — they were about epistemology:
The synthesis was that risk analytics has three primary entry points — three different epistemic stances — and the product had to support all three from one interface:
These are three different ways of asking the same model the same kind of question — what shouldn't be here? The canvas had to support all three; the digital twin had to be queryable along all three axes.
The product had to serve four distinct personas:
The temptation in enterprise software is to give each persona their own application. The strategic move with RAP was the opposite: one digital twin, one canvas, one conversational steering interface, persona-specific decision surfaces sitting on top.
The conversational layer absorbed the difference. A CRO asks "What's our concentration risk in the UKI portfolio if regulatory capital tightens?" An Internal Auditor asks "On SOX Audit 1245, flag transactions in the AZ entity that breach materiality." A Controls Manager asks "Which preventive controls have had failed test attempts in the last quarter?" Same engine. Same data topology. Same digital twin. Different questions into it.
The data topology was deliberately polyglot: SAP/Oracle, generic ERP, documents, images, CSV/Excel — because each persona's evidence sat in a different format and the model had to ingest all of it.
Before designing screens, we mapped what the central persona — the Risk Manager — needed the product to be:
Read together, this is a brief for a digital-twin cockpit — not a reporting tool. Connect to my sources, hold the rules, surface what matters, let me act on it, and respect who I am.
Synthesising the working architecture, RAP occupies a position no single EY product had occupied before:
The crucial insight: RAP isn't an app. It isn't a dashboard either. It's a host environment. Other tools live inside it. The client's data flows up into it. The downstream apps consume from it. And in the middle of all that — assembled out of the tool outputs that the canvas holds together — sits the digital twin.
This is the design move that everything else stands on. Before the conversation. Before the heat map. Before the uncertainty visualisation. There had to be a canvas that could hold the analyst's actual workflow.
Three principles defined it.
The right side of RAP isn't a single tile — it's a tileable workspace that can hold multiple tool surfaces at once. The hi-fi shows two panels rendered side by side (Inherent Risk Map + Risk Relations), but the architecture is generalised: any tool surface that respects the RAP integration protocol can appear here. A VIA exception view. An IRL risk-library lookup. A process map overlay. A document evidence panel. Each one can be summoned by the conversation, pinned, resized, and arranged. The four feature tiles on the home screen (Digital Twin, Data Topology, Process Mapping, Dashboard) aren't four features. They're four entry points to the canvas.
When the user pins "SOX Audit 1245" as a scope chip, every tool surface in the canvas inherits that scope. The VIA panel queries against that audit. The IRL panel filters its risk library to risks relevant to that audit. The process map highlights the in-scope process. The user scopes once; the canvas scopes everywhere. This is the move that turns "tools side by side" into "a coherent view of the enterprise." Without shared scope, multiple panels are just multiple windows in a different shape. With shared scope, the panels stop being separate tools and start behaving like organs of a single body.
Risk analysts work on more than one screen — that's empirically how they operate. The canvas had to follow them. The design allows panels to be popped out of the main RAP window, dragged to a second monitor, and continue receiving scope and conversation updates from the primary session. The analyst's two-monitor setup becomes one logical canvas. A heat map pinned to the secondary monitor stays in sync with a conversation happening on the primary. State doesn't fragment when the workspace physically does.
Why this is the foundation, not a feature: without the canvas, the digital twin has nowhere to live. The "twin" isn't a single visualisation that gets rendered into a tile — it's whatever combination of panels the user has arranged to answer their current question, assembled out of multiple tools, held together by shared scope, and following the user across screens. The canvas is the body of the twin.
The user flow is unusual because the onboarding step is the model-build step. You can't start using RAP without first telling it what to simulate — because the canvas needs to know which tools to load, against which entities, with which data sources mapped.
The flow:
This looks like an ordinary flow diagram, but it isn't. In a normal app, "missing inputs" is a form-validation problem. In RAP, missing inputs mean the model isn't ready to simulate yet. The decision diamonds aren't UI gates — they're simulation-readiness gates. The interface refuses to lie by computing on insufficient inputs.
The canvas is the foundation. What sits on top of it are four further design moves. Each maps to a specific property of the simulation underneath.
The home page leads with a chat ("Hey there! What would you like to do today?") rather than a navigation tree. A risk consultant types a multi-clause intent — "Identify and monitor high-impact risks to flag exceptions within transactions posted in SAP processes configured for the UKI business entities of AZ" — and the system clarifies in turn ("On which audit would you like to flag exceptions?"). The user narrows ("SOX Audit 1245"), and the model begins computing ("Sure, setting up the inherent heat map for you"). The conversation is not a chatbot wrapper. It's the way the user instructs the canvas about what to load, what to compute, and what to show.
When the heat map renders, it appears next to the conversation that produced it — not on a new screen. The user can read their own request, the system's clarifying turn, the scope token, and the resulting Inherent Risk Map and Risk Relations side by side. The visualisation is anchored to the conversation that conditioned it. This is a deliberate move against the failure mode of dashboards: a chart with no provenance.
"SOX Audit 1245" doesn't just appear in the chat — it pins as a scope chip and propagates across every panel in the canvas. Multiple chats can run in parallel ("Chat One", "New Chat") and each carries its own scope. The model always knows which slice of the twin it's reasoning over, in which panel, for which conversation.
The bottom navigation exposes four meta-operations on analytics: Customise · Discover · Register · Execute. These are deliberately verbs of user agency over the model — not nouns of content to be consumed. The user is not browsing reports. The user is participating in the model's lifecycle: tuning it, discovering what's inside it, registering new analytics into it, executing runs against it.
Because RAP is a simulation rather than a report, three UX problems arose that have no clean prior art. These are the most important sections of this case study.
A heat map in RAP is not a chart. It's a probability distribution. Every cell encodes severity × likelihood, and the likelihood is computed by the model with confidence bounds. The design question is unforgiving: do you expose the confidence bounds (rigorous, but visually noisy), or collapse them into a single colour (clean, but lies by omission)?
The move: a two-layer visual encoding.
High-confidence cells read as crisp. Low-confidence cells read as softer-edged. The user learns to scan crispness as a proxy for trustworthiness without having to read confidence intervals. The picture carries the uncertainty.
A what-if scenario is fundamentally a comparison: "If I change X, the heat map shifts like this." The temptation is to redraw the heat map every time the user perturbs an input. The better move is to render the delta — a diff layer over the baseline — so the user can see exactly which cells moved, and by how much.
The flow:
The user sees the change, not just the result. A heat map that just refreshed silently is a lie of omission. A heat map that animates the delta is an honest answer. And because the canvas can hold multiple panels at once, the baseline and the perturbed state can sit side by side — the user can run two simulations in parallel and read the diff visually rather than computationally.
A model output is not a decision. A cell that reads "high severity, high likelihood, low confidence" doesn't tell a CRO what to do. The interface has to bridge from model output to recommended action.
The move: every elevated risk cell exposes three follow-up actions in a side panel:
Each follow-up action expands the canvas with another tool surface — which is why the canvas had to come first. Without it, the bridge from prediction to action has nowhere to land.
A model that returns a probability is doing half its job. The interface has to do the other half — turn the probability into a decision someone can defend.
The most important lesson is that the fragmentation problem and the model-building problem turned out to be the same problem. Solving for "multiple tools in one canvas with shared scope and cross-screen continuity" is what produced the substrate for the digital twin. The container isn't a precursor to the model — it is the model's body.
The conversation is how the user conditions the simulation; the heat map is what the simulation returns under that conditioning; the canvas is the workspace in which the conditioning and the return co-exist. These three components are one interaction surface — not a window onto something separate.
The model knows its confidence. The dashboard refuses to. Bridging that gap — finding visual encodings that carry confidence alongside expected value — is squarely a designer's responsibility. It cannot be deferred to the data science team.
The chat in RAP isn't FAQ retrieval. It's the user articulating scope, constraints, and assumptions to a model that then computes — and to a canvas that then assembles panels around the answer. Multi-clause intent, structured clarification, persistent scope tokens, deliberate handoff from "describing" to "looking at."
Four roles. Each with a different decision surface (CRO needs concentration; Auditor needs flags; Controls Manager needs effectiveness). But they all query the same twin through the same canvas. Keep the engine unified; let the conversation route persona to panel combination.
A probability is not a decision. A heat cell is not an action. Designing the bridge — Investigate / Escalate / What-if, each opening another panel into the canvas — is the difference between an AI product that's interesting and an AI product that's useful.