From a Digital Twin to a Phygital Twin.

First, where this fits

Before you can optimize a process, you have to discover it.

If you've spent any time around enterprise automation, you already know the big names — UiPath, Automation Anywhere, Blue Prism on the RPA side, and Celonis on the process-mining side. They're genuinely powerful, and I'm not here to knock them.

But here's the thing I keep running into. RPA is brilliant once you already know the steps — you hand it a defined procedure and it runs it tirelessly. Process mining is brilliant once your work already lives in clean system logs — it reads an ERP's event table and reconstructs the flow. Both of them quietly assume the hard part is already done: that somebody, somewhere, has written the process down.

In most companies, nobody has. The real workflow doesn't live in one tidy system — it's scattered across a dozen web apps, a pile of spreadsheets, a thread of emails, and a ton of tribal knowledge that only exists in people's heads. The analyst who knows to re-check margin before pricing goes out. The planner who always pings product when a supplier slips. None of that is documented anywhere. There is no process map — and you can't mine logs for a process that was never logged in the first place.

So before optimization, simulation, or any of the fun stuff, there's an unglamorous first step almost everyone skips: discovery. You have to surface what the process actually is — bottom-up, from how work really happens — instead of pretending a top-down diagram already exists.

That discovery step is exactly where the big platforms get expensive and heavy — long deployments, connectors, six-figure licenses. And that's the gap I want to talk about. Because the browser the whole company already works in turns out to be the perfect place to watch real work unfold — which means we can now build a much lower-cost, custom alternative that discovers the process bottom-up, then opens the door to optimizing it. That's what the rest of this post is about.

How it works

How it actually works, start to finish

These five steps work for basically any process. To keep it concrete, I'll run one example all the way through — a company deciding whether to launch a new product.

The real journey · interactive

Four roles, lots of steps, even more events

Real decisions branch, run in parallel, and loop back — they're almost never a clean straight line. Each persona gets a lane with a few real steps, and every step becomes its own event. Tap or hover any step to see the role, the app, and the event it drops into memory.

Each lane is one persona; the multiple steps inside a lane are exactly the events RPM captures within that role and app.

The data behind the picture

What actually lands in the database — events, context & reasoning

This is the part that makes it more than logging. Each row doesn't just record what happened — it also stores the on-screen context the decision was made in and a short reason the assistant inferred on the spot. Multiple rows per role, all sharing one business object id, are what rebuild the whole launch journey.

Every row carries three layers — the event, the ui_context it happened in, and a short reasoning — all sharing business_object_id = launch_sku_family_x, the thread that reconstructs the full cross-role journey.