Discovery

How the recording works, how it is analysed, and how the processes appear

Live demo · sample data Start free analysis
18 recorders 16 producing 6 departments 289 person-days of capture 16 Jun – 13 Jul 2026 · Europe/Madrid

28 calendar days, 20 of them working days. Weekend volume falls to 4–7% of a weekday; 30 Jun is the month-end peak.

Synthetic demo dataset

The pipeline, stage by stage

Eight stages turn raw signal into discovered processes. Every count is recomputed at build time from the same source the rest of the dashboard reads.

Bar lengths use a log₁₀ scale (10²–10⁷); the printed numbers are absolute.

-4.1%

-97.17% 35.4 retained signals per resolved action

1374 resolved actions per work session

45.5 resolved actions per activity instance

-5.7% orphaned — no usable correlation key 11.99 activity instances per case

2,114 cases clustered into 14 processes

fan-out, not a reduction

Stage 1 of 8 — Capture

outputs: raw signal · 47,147,840

What happens here

A recorder on each machine subscribes to accessibility and input events and emits one signal per interaction. Nothing is interpreted yet.

A real record

A real record — raw signal
FieldTypeExampleMeaning
event_idstringev_8f31c04aOpaque per-event identifier.
tstimestamp2026-07-13T10:24:07.412+02:00Millisecond precision with an explicit offset.
device_refstringWIN-OPS-04The machine, not the person.
user_refstringemp_4471Pseudonymous. No name, no email address.
app_exestringerpclient.exeForeground executable.
window_titlestringVendor invoice — postingWindow caption, redacted before upload.
action_typeenumclickOne of eight verbs.
target_controlstringGrid/Row[4]/VendorNameAccessibility-tree selector path.
url_hoststringerp.internalHost only for browser events — never the full query string.
dwell_msinteger1420Time the control held focus.

Action types recorded: click keys focus scroll paste navigate file_save print

Captured

  • System events and user actions across the applications the team uses.
  • Which application and which screen, and the order things happened in.
  • How long each step took, including the waiting between steps.
  • Field labels and the structure of the data entered, for correlation.

Never captured

  • Keystroke content — typing is aggregated, never logged verbatim.
  • Message text in chat or email bodies.
  • Personal application use — blocked at capture, never uploaded.
  • Screen content from password managers, banking and HR portals.

Typing is recorded as "typed into Vendor name, 34 chars" — an aggregate, never the characters themselves.

Volume per recorder

Ranked by raw signals over the window. Two machines were offline throughout and produced nothing.

Recorder · Raw signals, 28-day window

  • WIN-OPS-04 Operations 4,862,400 Open recording
  • WIN-OPS-07 Operations 3,582,260
  • WIN-OPS-09 Operations 1,667,200
  • WIN-FIN-02 Finance 4,297,600 Open recording
  • WIN-FIN-05 Finance 3,173,400
  • MAC-FIN-11 Finance 1,824,600
  • WIN-FIN-08 Finance 0
  • MAC-SAL-03 Sales 4,029,000 Open recording
  • MAC-SAL-06 Sales 3,190,100
  • WIN-SAL-10 Sales 2,263,040
  • WIN-SAL-12 Sales 1,377,600
  • WIN-SUP-01 Customer Support 3,854,000 Open recording
  • WIN-SUP-04 Customer Support 2,847,960
  • MAC-SUP-07 Customer Support 2,689,640
  • WIN-BO-02 Back Office 3,406,000 Open recording
  • WIN-BO-05 Back Office 1,806,400
  • MAC-HR-01 People & HR 2,276,640 Open recording
  • WIN-HR-03 People & HR 0

The heaviest recorder produced 3.5× the volume of the lightest, and two machines were offline for the whole window.

Reconciliation ledger

Every row is recomputed at build time. If any tie-out broke, this page would not exist — the build fails instead.
Reconciliation ledger
#StageInOperationOutResidualTie-out
1Capture—reduce47,147,8400 Balances
2Privacy47,147,840reduce45,214,7791,933,061 Balances
3Resolve45,214,779reduce1,279,00043,935,779 Balances
4Segment1,279,000reshape9310 Balances
5Abstract1,279,000reduce28,1351,250,865 Balances
6Correlate28,135reduce2,11426,021 Balances
7Discover2,114reduce142,100 Balances
8Analyse2,114fan-out4570 Balances

Assertions checked at build time

  • Σ per-process cases = stage-6 output — Balances 312 + 188 + 146 + 121 + 88 + 214 + 132 + 96 + 176 + 121 + 84 + 240 + 132 + 64 = 2,114
  • orphan + correlated + unclassified = stage-5 output — Balances 1,604 + 25,350 + 1,181 = 28,135
  • Σ variant cases = that process's case count (14 of 14) — Balances checked per process at build time
  • Σ step durations + Σ waits = case duration (every sampled case) — Balances checked per trace at build time

Derived ratios, and the band each is expected to fall in

Derived ratios, and the band each is expected to fall in
ValueValueDerivationExpected band
Resolved actions per person-day4,4261,279,000 ÷ 289 person-days4,000–12,000
Raw signals per resolved action36.947,147,840 ÷ 1,279,00025–60
Resolved actions per activity instance45.51,279,000 ÷ 28,13530–80
Activity instances per case11.9925,350 ÷ 2,1149–140
Resolved actions per case545correlated share of 1,279,000 ÷ 2,114180–3,400

What the analysis does not know

Nothing on this panel is 100%. A process-intelligence view that reports perfect coverage has been tidied by hand.
  • 94.3% Correlation-key coverage
  • 0.81–0.94 Fitness range
  • 0.58–0.83 Precision range
  • 4.2% Unclassified activity instances
  • 5.7% Orphan activity instances
  • 10.4% Quarantined low-confidence actions
  • 1.4% Masking decisions reclassified on review

Glossary

Every term used anywhere in this dashboard. The tooltips elsewhere pull their text from here.
Event log
The table every figure here is computed from: one row per activity instance, with a case id, an activity name and a timestamp.
Case
One end-to-end run of a process — one invoice, one ticket, one new hire. The dashboard calls these cases everywhere a number is involved.
Activity
A named business step, such as "Validate invoice header". Produced by abstraction from many low-level UI actions.
Activity instance
One occurrence of an activity inside one case. A case that repeats a step has several instances of the same activity.
Trace
The ordered list of activity instances belonging to one case, with the waiting time between them.
Variant
One distinct ordered sequence of activities. Every case that ran that exact sequence belongs to that variant.
Resource
Whoever or whatever performed an activity, reported by role and department. Individuals are never named or ranked.
Directly-follows graph (DFG)
The discovered process map: a node per activity, an edge wherever one activity was directly followed by another, weighted by how often.
Happy path
The single most frequent complete variant. It is a measurement, not an ideal — here it covers 20–40% of cases, never most of them.
Fitness
The share of the observed behaviour the discovered model can replay. High fitness means the model misses little.
Precision
How little unobserved behaviour the model allows. It trades off against fitness, which is why both are reported and never combined into one score.
Conformance
The share of cases that ran without a deviation from the reference model.
Deviation
A departure from the reference model — a skip, a retry, a loop back. A deviation is not necessarily an error.
Rework
Work done more than once in the same case. Measured as the share of cases containing at least one repeated activity.
Self-loop
An activity directly followed by itself — the same step repeated back to back.
Throughput time
Wall-clock time from the first to the last activity of a case, waiting included.
Working vs waiting time
Working time is hands-on interaction; waiting time is the gap between activities. On most processes waiting dominates by an order of magnitude.
Bottleneck
A transition where cases wait. Ranked by total waiting time, because total is what can actually be recovered.
Correlation key
The field read off the screen that stitches activity instances into one case. Its coverage is never 100%; what it missed is counted as orphan.
Abstraction
The rules that collapse runs of raw UI actions into one named activity. Roughly 45 actions become one activity instance.
Lift, support and baseline
Lift is how much more often a branch is taken when a condition holds, against the baseline rate for all cases. Support is how many cases the rule was measured on.
Straight-through processing (STP)
The share of cases that ran end to end with no manual touch. Real rates sit well below 85%.
Resolver and confidence
How a raw event was mapped to an application and screen — accessibility tree, DOM or OCR — and how sure that mapping is. Below 0.70 an action is quarantined.
Masking
Field-level redaction applied on the device before upload. The detector is a model, so a small share of its decisions is reclassified on review.
Esc
↑↓ navigate ↵ open Esc close