{"id":"51927b0a-b1ec-47ec-881c-1f7f5ed3ce96","arxiv_id":"2607.26384","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"An ER-schema-guided framework defines process cases as connected components of a graph over primary and secondary entity objects, after excluding resource and parent entities.","lead":"This paper proposes using an entity-relationship (ER) schema to decide how to group events in object-centric event logs into cases: pick a main entity type, treat some others as resources to ignore, and connect the rest through shared objects. The approach produces non-overlapping cases by construction, but the paper's single-log 'validation' is a demonstration without ground truth.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Share statistic in Definition 3 cannot identify resource types that appear once per event, so the resource-exclusion mechanism fails for the paper's own motivating examples.","rationale":"The reader's weakest assumption is exactly the load-bearing concern: the resource classifier in Definition 3 does not match the paper's own motivating examples. This is not a minor threshold-tuning issue; it is a definitional mismatch between the statistic (co-occurrence of multiple instances in one event) and the intended semantics (an object shared across independent executions, even if only one instance appears per event). The formal connected-components construction and its partition properties are correct, so the central formal claim is not invalidated. However, the practical contribution—avoiding spurious merges through resource objects—depends on an entity classification that the formal definition does not deliver. The proposed concrete test would settle whether the concern lands. Since the paper itself acknowledges the need for expert tuning and an ER schema, a conditional acceptance remains appropriate; the reader's verdict should not change.","tokens_in":9865,"tokens_out":3667,"duration_ms":42784,"concrete_test":"Construct a synthetic two-case OCEL where two independent order executions are handled by the same truck in disjoint time periods, and every event references exactly one truck. Run the framework's Definition 3 with θ_share=0.3: since no event has more than one truck, share(TRUCK)=0, so TRUCK is not placed in ET_res. Definition 5 then includes the truck object in V, and connected components merge the two order components into a single case. If the output is one case instead of two, the share statistic demonstrably fails to prevent the exact resource-bridging the paper claims to avoid.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's advertised advantage over full connected components is that resource entities are excluded from the object graph before computing components (Section 4.2, Definition 3). But share(t) is the fraction of events referencing more than one instance of t. The motivating resources — 'products, trucks, recruiters' (Section 1) — typically occur once per event. For such a type, share(t)=0, so Definition 3 places t in ET_res only if 0 ≥ θ_share, impossible for default θ_share=0.3. The truck/recruiter will remain in V and act as a bridge, re-merging independent executions. Example 3 only succeeds because ITEM co-occurs multiple times per event (share=0.75); it does not test the stated resource class. Since the framework's claim 'no spurious merging' depends entirely on this classification, and the ER schema cardinality does not rescue it (a 1:n or m:n relationship does not tell you whether the non-PE type is a resource), the central benefit collapses for the common one-resource-per-event setting. The formal partition properties P1–P3 still hold, but they describe a partition of the filtered graph, not a partition with the semantic guarantee advertised.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an ER-schema-guided framework for selecting a case notion in object-centric process mining. The framework classifies entity types as primary (PE), secondary (SE*), resource, or parent based on ER cardinalities and a log-derived share statistic, then defines cases as connected components of the object relationship graph restricted to PE and SE* objects. The authors show that this construction yields a strict partition with transitive closure by construction, and illustrate the approach on an order-management example and a 1,000-event OCEL log, followed by a two-level discovery decomposition. The central formal properties P1–P3 are indeed immediate consequences of the connected-component definition, but the paper's advertised semantic advantage — avoiding spurious merging through resource objects — depends on the robustness of the resource-classification rule, which is not established for the motivating examples.","tokens_in":10183,"tokens_out":5381,"duration_ms":65580,"significance":"If the classification mechanism were trustworthy, the framework would provide a principled, schema-grounded alternative to ad hoc flattening and to full connected-component case notions. The formal partition and transitive-closure guarantees are genuine and are obtained without optimization or post-processing. The paper is also honest about the need for thresholds and further validation, and it makes the evaluation log publicly available. However, the resource-classification step is the load-bearing element for the claimed 'no spurious merging' property, and it is not robust: the very resource types used to motivate the work (trucks, recruiters) are not identified by the share statistic. The proposed empirical validation (structural homogeneity) is circular, and the evaluation is limited to a single synthetic log with no baseline comparison. The formal skeleton is sound, but the advertised contribution requires a reworked resource-entity definition and a more convincing evaluation before the claims in Table 1 can be accepted.","major_comments":[{"comment":"The resource-exclusion mechanism fails for the paper's motivating resource types. Definition 3 sets ET_res = {t : share(t) >= theta_share}, where share(t) is the fraction of events referencing more than one instance of t. A truck or recruiter typically appears once per event, giving share(t)=0, so with default theta_share=0.3 such a type is not placed in ET_res. It therefore remains in V in Definition 5 and can act as a bridge between independent executions across events, exactly the spurious-merging failure the paper claims to avoid (Table 1, Section 6). Example 3 works only because ITEM appears multiple times per event; it does not test the truck/recruiter case. Concretely, a log with two orders and one truck, with two events (truck+order A, truck+order B), will produce one connected component even though the orders are independent, because share(truck)=0. This directly undermines the","section":"Section 4.2, Definition 3; Section 1"},{"comment":"The proposed validation via structural homogeneity H is circular. The baseline 'prediction' (from ER cardinality) and the actual coordination load SC are both computed from O2O edges in the same log that was also used to determine the share-based resource classification. High H therefore only confirms that the log is internally consistent with itself; it cannot independently confirm that the entity classification is correct. Moreover, H and SC are not formally defined — the text says 'These concepts should be developed in subsequent work' — so the statement that the 1,000-event log yields '40 structurally coherent cases' is an assertion rather than a validation. Provide an operational definition of H and compare against ground-truth logs or held-out data.","section":"Section 6"},{"comment":"The empirical evaluation is limited to a single synthetic log with no baseline comparisons and no sensitivity analysis for the thresholds theta_share and theta_cov. The claim in Table 1 that this paper achieves 'No spurious merging: Yes' is not established by the experiments; the experiments only demonstrate the formal partition properties, which hold regardless of whether the classification is semantically correct. To support the advertised advantage over full connected components and over Adams et al. [8], the paper should report precision/recall on logs with known ground truth, compare with the full-component baseline, and test the robustness of the resource classification to threshold choices.","section":"Section 4.5; Section 5; Table 1"}],"minor_comments":[{"comment":"The paper uses 'Resource entity (RE)' in Section 3.2 but 'ET_res' in Definition 3, and 'SE' vs 'SE*' inconsistently. Please unify the notation.","section":"Notation throughout"},{"comment":"The sentence 'A well-chosen PE should have high coverage and low share' is presented as a filter, but Definition 2 selects PE by domain knowledge and the statistics are only corroborative. Clarify that the thresholds are not a formal selection procedure for PE.","section":"Section 4.2"},{"comment":"MD5 is described as 'collision-resistant'; this is not accurate in a security sense. Consider using SHA-256 or remove the term.","section":"Section 4.4, Remark 2"},{"comment":"The 'arc multiplicity k' values (1 to 6) are mentioned without supporting data. Please indicate where these counts come from or include a table.","section":"Section 5"},{"comment":"References [13] and [18] are dated 2026. If these are still in press or preprints, please mark them accordingly; otherwise the citation dates appear inconsistent with the current submission year.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The formal component of the paper is elementary (connected components of a graph), and the paper's main contribution is the ER-guided classification. The current classification rule is not robust for the paper's own motivating examples, and the empirical validation is circular. I would encourage the authors to rethink Definition 3 around ER semantics rather than the share statistic, and to add a baseline comparison. With those changes the paper could become a solid contribution to the case-notion literature; in its current form, the central semantic claim is not supported."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the cleanest part of this paper is Definition 5 — cases as connected components over PE and SE* objects, with strict partition and transitive closure provable by construction. That part holds. But the resource-exclusion mechanism in Definition 3 does not do what the abstract promises. Your stress-test is right: share(t) is the fraction of events referencing more than one instance of type t, so any resource that appears once per event — a truck, a recruiter, a product — gets share=0 and is never excluded. The paper's own motivating examples are exactly these, yet Example 3 only works because ITEM happens to co-occur several times per event. The advertised advantage over full connected components collapses for the common one-resource-per-event case, and P1–P3 end up as properties of the filtered graph rather than guarantees against spurious merging.\n\nWhat is genuinely new and useful: the ER-schema-guided classification into parent, secondary, and resource types is a legitimate extension of the data-driven approaches in Adams et al. and van Detten et al. The two-level discovery framing — separate PE lifecycle and SE* lifecycle sub-logs — is a clean way to exploit the schema, and the paper is honest about its limitations: single log, no ground truth, thresholds to tune, and a proposed validation via structural homogeneity H that is only sketched, not computed. The citation pattern is fair, and the link to the 1,000-event log is a plus.\n\nSoft spots, in proportion: the share statistic is the load-bearing flaw, and it is not a minor leak. The paper keeps saying resource exclusion prevents merging of independent executions, but the definition doesn't reliably identify resources. The evaluation on one log with no baselines against Adams or van Detten would be a concern even if the classification were sound. And Section 6's homogeneity idea is future work, so it cannot serve as validation. That said, the formal connected-component machinery itself is correct, and the authors acknowledge that schema quality and threshold tuning matters.\n\nWho this is for: researchers working on case notions in object-centric process mining, especially those who want a formal reference for partition guarantees or a starting point for fixing resource identification. I'd bring it to a reading group and would send it to peer review — a referee could push the authors toward a more robust resource classifier, maybe using ER role semantics or cardinality combined with object counts. I would not cite it for the resource-exclusion claim, though I might mention it as related work. It deserves a serious referee, but the authors need to either fix the resource definition or substantially soften the claim.","headline":"The formal partition part is sound, but the share-based resource classification fails for the paper's own motivating resource types, so the advertised advantage over connected components is shaky; still worth a referee.","tokens_in":10606,"tokens_out":2419,"would_cite":false,"duration_ms":30513,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that an ER schema can define process cases for object-centric event logs, producing a strict partition of the log by treating cases as connected components over primary and secondary entities.","keywords":["object-centric process mining","case notion","ER schema","connected components","entity classification","strict partition","transitive closure","process discovery"],"falsifier":"Run the method on a log where a truck or recruiter is recorded once per event but ferries several unrelated orders; if Definition 3 keeps that type in the graph (share=0) and the resulting connected components merge those orders into a single case, the advertised 'no spurious merging' property fails. More directly, one can compute share(t) over a log with known resource types and check whether the default threshold yields ET_res exactly.","tokens_in":9782,"feed_emoji":"🧩","tokens_out":4045,"duration_ms":47390,"temperature":0.7,"pith_summary":"Object-centric event logs record several business objects per event, and there is no obvious grouping into cases—the unit that process mining needs. The paper argues that the entity-relationship schema behind the process supplies that grouping: identify one primary entity type (e.g., order), classify other types as resources (to ignore), parents (to ignore), or secondary coordinating entities (to keep), and declare each case to be one connected component of the graph whose nodes are primary and secondary objects. If this is right, the resulting cases form a strict partition of the event log, cover every execution instance exactly once, and keep resource objects from silently merging independent runs. A sympathetic reader would care because case choice determines everything downstream—discovered models, conformance checks, and per-instance performance numbers.","feed_headline":"ER schema picks process cases without flattening the log","feed_subtitle":"Schema-driven cases group object-centric events into strict partitions, keeping resources from merging separate runs.","key_machinery":"The engine of the method is Definition 5: build an object relationship graph whose vertices are all objects except resource and parent instances, draw an edge between any two objects that co-occur in an event, then take connected components. Components serve as cases, with the case output only the PE instances, while SE* objects act as bridges that intentionally fuse coordinated PE instances. This construction carries the three advertised properties: strict partition, transitive closure, and every case anchored by a PE object. The resource class itself is selected by the share statistic—the fraction of events referencing more than one instance of a type—with a default threshold.","core_discovery":"The paper's central claim (Definition 5, properties P1–P3) is that a case notion with formal guarantees can be derived from the ER schema rather than from log statistics alone. After choosing a primary entity PE, excluding resource entities (identified by a share statistic) and parent entities (1:n owners of PE), and keeping secondary entities SE* (bridge objects in m:n or 1:n coordination with PE), the connected components of the object relationship graph induce a partition of the log: every PE instance belongs to exactly one component, every event referencing at least one PE object is assigned to exactly one case, and PE instances linked through any chain of non-resource objects end up in","pith_inferences":["A testable extension is to vary θ_share across a benchmark of OCEL logs and measure how stable the resulting case partitions are; the paper tunes the threshold by hand and tests one log.","The same component-based definition could in principle be applied when the ER schema is inferred from the log rather than given, but the schema's cardinality information would have to be reconstructed from co-occurrence statistics, and the paper does not claim this.","The boundary case of PAYMENT suggests that extending SE* to transitive schema reachability would let the framework handle multi-level coordination processes (e.g., orders → invoices → payments), at the cost of deciding whether a transitively reached entity behaves as a resource or a secondary entity."],"forward_implications":["Standard process discovery algorithms can be run on the projected sub-logs, one trace per PE instance and one per SE* instance, without inventing case ids.","Joint-execution cases, where several PE instances synchronize through a shared secondary object, are represented as one case rather than being flattened away or split.","Resource objects such as catalog items do not merge independent executions, provided the resource classification is correct.","Case identifiers become stable, fixed-length hashes of the sorted PE ids, suitable as surrogate keys.","The partition reveals asymmetry invisible in the raw log: in the test log, the PE lifecycle shows 109 trace variants versus 6 for the SE lifecycle."],"fun_headline_variants":["ER schema picks cases without flattening object-centric logs","Schema-driven case notion: strict partitions, no resource merging","Entity-Relationship model guides case selection in process mining","ER framework: case notion from schema, not log stats"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the share statistic correctly tells which entity types are resources; if a resource type is referenced once per event, share=0, so its objects remain as bridges and independent executions can merge into one case.","fun_headline_variants_meta":{"raw":{"variants":["ER schema picks cases without flattening object-centric logs","Schema-driven case notion: strict partitions, no resource merging","Entity-Relationship model guides case selection in process mining","ER framework: case notion from schema, not log stats"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000227,"raw_usage":{"total_tokens":1273,"prompt_tokens":677,"completion_tokens":596,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":421,"completion_tokens_details":{"reasoning_tokens":530}},"tokens_in":421,"tokens_out":596,"duration_ms":6528,"temperature":1.0,"reasoning_tokens":530,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T16:59:54.554886+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the method on a log where a truck or recruiter is recorded once per event but ferries several unrelated orders; if Definition 3 keeps that type in the graph (share=0) and the resulting connected components merge those orders into a single case, the advertised 'no spurious merging' property fails. More directly, one can compute share(t) over a log with known resource types and check whether the default threshold yields ET_res exactly.","supporting_citations":[],"review_version":1}