Process mining event logs for training and evaluating agents

For finance flows, see procure-to-pay and order-to-cash records; for multi-object events, see object-centric event logs (OCEL 2.0). The agent and workflow data hub maps the cluster, and SourceX's workflow data overview describes workflow records generally.

Where event logs live in business systems

Few systems export an event log directly; suppliers assemble one from the change histories, audit tables and status transitions systems already keep. The source determines the natural case ID and which work is missing.

Ask which table and field each activity came from. "Approved" built from a status change and "Approved" built from a signed document are different events; mixed, they teach an agent a step that does not exist. For logs stitched across systems, see cross-system workflow records.

The fields a usable event log carries

Case ID, activity and timestamp are the minimum; one process-mining vendor's guide calls those three the basic structure of an event log [1]. Agents also need who acted, whether an event starts or ends work, and the case context behind each path.

IEEE 1849-2023 defines XES, an XML format for event logs and streams whose extensions give attributes a standard meaning [2]. The keys below come from its concept, time, lifecycle and organizational extensions.

A case attribute such as customer segment, overwritten after the event, leaks the future into training, the problem covered in point-in-time correct training data.

An onboarding case as CSV and XES

A single case shows what a log teaches and what it omits.

Illustrative example: invented to show structure; it does not describe an available dataset.

case_id,activity,lifecycle,timestamp,resource,role,source_system,detail
ONB-20418,Application received,complete,2026-02-03T14:02:11-05:00,sys_portal,system,crm,
ONB-20418,KYC document review,start,2026-02-04T09:15:40-05:00,res_8c1f,onboarding_analyst,case_mgmt,
ONB-20418,KYC document review,complete,2026-02-04T09:31:05-05:00,res_8c1f,onboarding_analyst,case_mgmt,rejected_unreadable
ONB-20418,Request resubmission,complete,2026-02-04T09:33:52-05:00,res_8c1f,onboarding_analyst,email_gateway,
ONB-20418,Document received,complete,2026-02-06T17:48:20-05:00,sys_portal,system,crm,
ONB-20418,KYC document review,start,2026-02-09T10:02:13-05:00,res_2a77,onboarding_analyst,case_mgmt,
ONB-20418,KYC document review,complete,2026-02-09T10:11:58-05:00,res_2a77,onboarding_analyst,case_mgmt,accepted
ONB-20418,Escalate to compliance,complete,2026-02-09T10:12:30-05:00,res_2a77,onboarding_analyst,case_mgmt,
ONB-20418,Compliance approval,complete,2026-02-10T16:40:02-05:00,res_91d0,compliance_officer,case_mgmt,
ONB-20418,Account activated,complete,2026-02-10T16:41:15-05:00,sys_billing,system,billing,

The same invented case's first review completion in XES:

<trace>
  <string key="concept:name" value="ONB-20418"/>
  <event>
    <string key="concept:name" value="KYC document review"/>
    <string key="lifecycle:transition" value="complete"/>
    <date key="time:timestamp" value="2026-02-04T09:31:05.000-05:00"/>
    <string key="org:resource" value="res_8c1f"/>
    <string key="org:role" value="onboarding_analyst"/>
  </event>
</trace>

The log shows a rejection, a resubmission loop, a weekend in the queue, a second analyst and an escalation; it omits why the document failed and what the email said. Key that content to case and event IDs, as in reconstructing trajectories from ticket histories.

XES, OCEL 2.0 or flat tables

Choose the format by case notion and consumer: XES for logs with one case notion read by process mining tools, OCEL 2.0 when events touch several objects, and Parquet or CSV with a data dictionary for ML pipelines.

For flat deliveries, use a data dictionary template and the rules in timestamps and time zones in delivered datasets.

What event logs teach agents, and what they leave out

Event logs teach sequence, timing, branching and routing; they lack the screens, documents and messages an agent reads and writes. They serve four jobs.

• Next-step and outcome prediction. Predictive process monitoring predicts a running case's next activity, remaining time or outcome. One review benchmarks deep learning methods on 12 logs [5]; a 2026 study compares sequence, tabular and LLM approaches on BPI Challenge 2012, 2017 and 2020 logs [6].
• Planning priors. Variant frequencies, approval routes and normal waits tell a planner what usually happens next.
• Environment design. Arrival rates, durations and branching probabilities parameterize a simulated back office; pair them with seed data and state snapshots.
• Evaluation. Freeze held-out cases at a decision point and compare the agent's next step with the recorded one, excluding paths later reversed.

The gap is content. SourceX's pages on enterprise workflow datasets and agent trajectories and enterprise agent training data for computer use describe records that carry it; desktop click streams are covered in task mining data.

Holding out cases without leaking the future

Split event logs by time at the case level, never by random rows. Weytjens and De Weerdt report that training and test sets in predictive process monitoring are often not completely separated, a leakage problem particular to the field, and that test sets tend to be biased in their mix of case durations and running cases [7].

A remaining-time survey orders cases by start time and fits on the first 80% [8]; the 2026 comparison orders cases by first event and sends any case overlapping the split point to the test set [6]. On small logs, a time split can place a whole process variant in the test set [9]. Ask the supplier to flag cases truncated by the extract window.

Public logs: useful for pipelines, thin for agents

Public logs let you test parsers and scoring before buying, but the pool is small, dated and drawn from few organizations. A 4TU.ResearchData bundle collects 12 public IEEE Task Force on Process Mining logs, seven pre-processed to remove infrequent behavior, under CC BY 4.0 and covering 2010 to 2017 [10]. BPI Challenge 2019 is real purchase-order data from one coatings and paints company [11]. IEEE DataPort hosts noise-injected versions of real logs [12], and a Zenodo collection simulates OCEL 2.0 logs for four processes [13].

None of these carries resolution notes, linked documents or the spread of configurations production agents meet. Widely reused across papers, they also make weak held-out evaluation sets.

Employees and customers inside the log

An event log usually contains personal data even without names: resource IDs map to employees, and a case's sequence of activities and timestamps is often unique. Nuñez von Voigt and colleagues measured uniqueness in public event logs and found that potentially up to all cases in a log may be re-identified [14]. A process-mining privacy survey describes linkage attacks that combine a released log with background knowledge, and notes that a person, such as a hospital employee recorded as a resource, can be linked to an activity as well as a case [15].

Each treatment costs some utility:

• Resources: keyed, role-tagged pseudonyms, stable across tables, with bots and shared logins flagged. The UK ICO states that pseudonymised data remains personal data [16]; as of October 2026 that guidance is under review.
• Timestamps: per-case shifting keeps durations but breaks calendar effects; coarsening protects more but loses ordering within a day.
• Rare variants and attributes: suppress or generalize unique paths, small teams and exact amounts.
• Health processes: HIPAA Safe Harbor counts date elements other than year among its 18 identifiers, so a de-identified log that keeps full dates must rely on Expert Determination, where an expert finds the identification risk very small [17]. SourceX requires one of these two methods before health records are considered for a license.

For datasets SourceX sources, rights review checks that the business owns or may share the records and that required consents are in place; personal details are removed or replaced before delivery, the method is recorded and a sample is checked. No de-identification method is perfect, so share your privacy requirements with SourceX with your request. Workplace notice is covered in employee-authored records in training data.

Writing an event log request

A request names the process, case notion, fields, time rules, privacy treatment and uses, so a supplier can check its systems against it.

On delivery, check that labels match the mapping, ties are resolved, monthly case counts have no unexplained gaps, and pseudonyms join across tables.

Source real process event logs for your agents

Describe the process, case notion, fields and uses you need. SourceX sources operational datasets from US companies on request, not from stock: it looks for businesses that hold matching records, checks the data and the supplier's licensing permissions, manages the license, and coordinates delivery and payment. A request does not guarantee a match, and nothing is contracted until a supplier agrees. Describe your event log requirements.