OpenWorkGraph Roadmap 2: closing competitor-depth gaps in process and task mining

What they did

The maintainers of OpenWorkGraph (OWG) opened a second roadmap issue after every item in their first roadmap (#264) had a first implementation in `main`. They started from an honest baseline table comparing OWG against Mimica, UiPath (Task Mining, Process Mining, Task Capture, Automation Hub, Communications Mining), Celonis, Soroco, Microsoft Power Automate Process Mining, SAP Signavio and Skan.ai, and concluded that most items were breadth, not depth, and that the #264 parity gate (test competitor-style UX against realistic consenting datasets) had not been met. They then broke the remaining work into lettered sections: A) task mining and reconstruction quality, including reconstruction beyond exact record refs (#349), cross-day resumption (#347) and k-anonymous team-level discovery (#348); B) event-log interoperability and scale, covering OCEL 2.0 JSON/XML, XES, a DuckDB columnar engine with a 10M-event acceptance test, object-centric maps and enterprise connectors; C) analytics depth, covering token-replay and alignment conformance, root-cause associations, KPI dashboards, what-if simulation and cohort benchmarking; D) documentation, communications mining and deployment monitoring; E) proof via a real consenting pilot and a competitor-style UX review; F) gaps found in a second parity review (organizational mining, KPI signals, a PQL-like analysis builder, an automation opportunity pipeline, incremental append); G) gaps from ABBYY Timeline, Signavio, Disco, Apromore, IBM and PM4Py (predictive monitoring, Declare-style compliance rules, map abstraction sliders, automatic model discovery); and H) performance and change analysis (processing vs waiting time, dotted chart, map comparison, concept drift). Each item is a checkbox with an issue reference, and most are already checked off. They kept OWG's foundations explicit: local-first capture, consent, evidence/policy/permission separation, agent handoff over MCP, Discovery Mode, and no hidden upload or productivity scoring. They also added acceptance gates (backward-compatible REST/MCP, cross-tenant isolation, revocation/retention, safe HTML, performance acceptance at scale, and no derived path or statistical association presented as a verified workflow, cause or authorization) and coordination rules for parallel agents: claim an item before starting, branch by area (e.g. `feat/ocel-import`), and keep shared files like `tests.yml`, `dashboard/index.html` and the process model to minimal additive edits.

How it went

Most of the roadmap is checked off in `main`: OCEL 2.0 and XES import/export, a DuckDB engine with a 10M-event acceptance test, object-centric maps, alignment and token-replay conformance, root-cause associations, KPI dashboards, what-if simulation, organizational mining, KPI signals, a typed analysis builder, an opportunity pipeline, incremental append, predictive monitoring, Declare-style rules, Disco-style map sliders, inductive-miner discovery with BPMN export, processing vs waiting time, dotted chart, map comparison and concept drift. The authors are candid about limits: deterministic reconstruction signals reach 0.52 identifiable holdout F1 (0.57 with #349), and accepting every ambiguous candidate reaches 0.65 but with 0.125 contamination, so the 0.90 target likely needs an LLM-graded linker with a user-supplied API key. Enterprise connectors and a real consenting pilot remain open.

Worth knowing

This is a roadmap issue, not a finished product: several items (enterprise source connectors, the 0.90 reconstruction F1 gate, the real pilot and the competitor-style UX review) are still unchecked. Executing robots are out of scope by design, and signals and predictions never act or rate people. The parity claims are self-assessed against a baseline table, not independently verified, and the A/B/C harness has never run on real users. Parallel agents must claim items and keep shared files to additive edits to avoid collisions.

Wiring

The roadmap assumes a local-first OWG stack: capture feeds a local SQLite store, with a DuckDB event-log workspace for multi-million-event analytics. Event logs move in and out via OCEL 2.0 (JSON/XML) and XES, so PM4Py, ProM, Apromore, Celonis and Signavio can interoperate. Analytics (conformance, root cause, KPIs, simulation, benchmarking, organizational mining, signals, analysis builder, opportunity pipeline, predictive monitoring, Declare rules, map sliders, model discovery, processing/waiting time, dotted chart, map comparison, concept drift) run over saved logs and expose results through a backward-compatible REST/MCP surface and the dashboard. Agent handoff is over MCP, and non-executing starters (Codex/Claude/n8n/AI SDK) are monitored via run reports and an SDK journal. Parallel agents coordinate by claiming items in the issue, branching by area, and keeping shared files to additive edits.

Try it yourself

Read the OpenWorkGraph roadmap issue at https://github.com/kaventures/openworkgraph/issues/326 and the baseline table in it. Pick one unchecked item (for example enterprise source connectors in section B, or the reconstruction F1 gate in section A). Claim it in a comment, create a branch named after the area (e.g. `feat/salesforce-connector`), and implement it against the existing event-log workspace. Keep shared files (`tests.yml`, `dashboard/index.html`, the process model) to minimal additive edits, add tests for cross-tenant isolation, revocation/retention, safe HTML and concurrent edits, and run the performance acceptance at the stated scale. Do not present derived paths or statistical associations as verified workflows, causes or authorizations, and do not add hidden uploads or productivity scoring.