Summary
A BlueSky position paper (no experiments, no data) arguing that process mining should shift its target from log-to-model to log-to-action: mining operational event data so an agent can recommend, defer, ask, or refuse an action with causal evidence, privacy accounting, and auditable authority. It names four “mineable artifacts” the community must define — R1 a typed event-object state representation, R2 an evidence object carrying explicit causal tiers and uncertainty, R3 a governance object recording tool provenance, privacy budget, and approval authority, R4 an evaluation object where act/defer/ask/refuse are all scored outcomes — and five stress tests, each phrased as “the agenda fails if…”. It proposes a concrete community challenge, E2A-Bench, releasing realistic process ecosystems with partial object-centric logs, local tool APIs, privacy budgets, intervention catalogs, and hidden ground-truth mechanisms, scored on calibration, causal validity, privacy cost, robustness to drift, auditability, and refusal quality. Its sharpest line for benchmark builders: “a system that acts confidently on unsupported evidence should lose, even when its next-event prediction is plausible.” It explicitly disclaims building a full enterprise simulator, on the grounds that logs are partial, policy-shaped traces.
Key points
- What they say logs contain and how to represent it: not flat case traces but an event-object graph — typed objects, events, resources, queues, documents, decisions, policies, timestamps, external conditions, linked through time — because interventions on one object propagate to other objects, organisations, and resource queues. OCEL 2.0 (many-to-many event–object relations, evolving object attributes) is their proposed standard.
- The proposed self-supervised targets on such a representation are directly reusable as environment-construction tasks: masked event reconstruction, object-state forecasting, resource-contention prediction, constraint-violation detection, time-to-deadline estimation, and action-effect consistency.
- The output object is a “governed action recommendation” with five parts: the proposed action, its predicted process consequences, an evidence tier, the privacy/authority conditions permitting it, and an audit trail linking the claim to a local computation. Recommendations can be positive, conditional (act only with manager approval or remaining privacy budget), deferential (collect more evidence), or negative (refuse).
- Evidence tiers are enumerated as a ladder: historical association → adjusted observational estimate → quasi-experimental support → expert assumption → generator-only conjecture → verified intervention. A recommendation must carry its rung.
- Refusal is treated as a first-class scored output, and the paper insists it is a pipeline-level property: sparse event coverage, unsupported causal assumptions, exhausted privacy budget, missing authority, or unacceptable risk transfer to a partner are each grounds for non-action. This is a direct challenge to task-success-only grading.
- Named failure modes worth stealing as design constraints: treating logs as neutral telemetry (the same activity label can mean routine progress in one org and a compliance violation in another); reducing counterfactuals to scores; separating agent safety from process safety (an agent can satisfy a formal rule while exploiting a logging loophole, or hit a local SLA while worsening system fairness); and evaluating deployment as static prediction when workers adapt once agents act.
- They point at SimBank and ProCause as the existing way round the missing-counterfactual problem — a simulator with known ground-truth mechanisms so the outcome of the unchosen action exists. That is an argument for building the environment, not just scoring on replayed logs.
- Limitation: this is an agenda, not a method. No representation is learned, no benchmark is released, E2A-Bench does not exist, and nothing is said about how any of the four artifacts is actually mined from a real log.
Relevance
- ITSMBench — the clearest published statement that “logs → agent actions” is an open, unbuilt frontier, which supports the survey finding that no paper builds an agent environment from event logs. Two things it hands V2: the object-centric representation (typed objects, queues, documents, policies) as the right shape for the world extracted from BPI 2013/2014, rather than a flat trace; and the act/defer/ask/refuse action space, which maps almost exactly onto ITSM (resolve, wait-user, reassign, reject) and onto the reassignment/ping-pong patterns in the BPI logs. It also names the verifier gap: end-state success is not enough if a policy-violating or unauthorised path can reach the same state. What it does not cover: any method, any code, any numbers, any task-generation procedure, and any account of how an event-object graph becomes an interactive environment. It supplies vocabulary and a target, not a bridge.
- Benchmark Research — a benchmark-design contribution in the sense that it specifies the contract: score calibration, causal validity, privacy cost, communication cost, robustness to drift, auditability, and refusal quality; keep a fixed versioned core with renewed hidden scenarios; report benchmark versions separately so changing difficulty is not mistaken for progress. The “refusal counted as non-performance is a failure mode” rule is the part V2 most obviously lacks.
- Enterprise Environments — home concept since 2026-09-10
Questions it raises for ITSMBench:
- V1 and V2 grade on end-state DB checks. If restraint (defer, ask for approval, refuse) is a correct answer in ITSM — and it plainly is, for changes needing CAB approval or tickets with missing information — how is a correct refusal verified without a trajectory check, and what fraction of BPI cases actually end in one?
- The paper insists the same activity label means different things across organisations. BPI 2013 (Volvo IT) and BPI 2014 (Rabobank) use different vocabularies; does a V2 world built from one transfer at all, or does each enterprise need its own refiner run?
- E2A-Bench is proposed but not built. Is V2 close enough to it that the ITSM instance could be released as the first concrete instantiation, and what would it need — privacy budgets, an intervention catalog, hidden mechanisms — that it does not have?
Notes
(Our take: to add after reading; drafted 2026-09-09, not yet discussed)