AdProv: Provenance for Adaptive Workflows

• AdProv is a prescriptive, service-oriented method that captures, stores, retrieves, and visualizes runtime adaptations in workflows through systematic logging of execution and change events.
• It extends the XES event log standard and maps events to the PROV Ontology, ensuring semantic consistency and enabling detailed process adaptation analysis.
• The modular Provenance Holder architecture supports efficient data collection, persistent storage, flexible retrieval, and visual auditability in diverse workflow environments.

AdProv is a prescriptive, service-oriented method for capturing, storing, retrieving, and visualizing the provenance of runtime adaptations in workflow and business process executions. It specifically addresses the systematic provenance of process modifications—so-called change events—that occur during the operational lifetime of a workflow instance, a gap not sufficiently handled by prior approaches to scientific and business process provenance. AdProv defines both conceptual and technical foundations for logging ad-hoc process adaptations, provides a modular architecture for provenance management (“Provenance Holder”), asserts semantic consistency via PROV Ontology (PROV-O) mapping, and extends the XES event log standard for adaptation events (Stage et al., 7 Oct 2025).

1. Core Concepts and Formal Definitions

AdProv centers on four principal constructs: process execution events, change events, adaptation logs, and provenance information. A Process Execution Event $e_{\mathrm{exec}}$ encodes activity invocations (with attributes such as $\mathit{concept:name}$, $\mathit{time:timestamp}$, and $\mathit{org:resource}$, conforming to XES standards). The primary AdProv addition is the Change Event $e_{\mathrm{chg}}$, formally represented as:

$$e_{\mathrm{chg}} = \bigl\langle \mathit{type}, \mathit{target}, \mathit{who}, \mathit{when}, \mathit{details}\bigr\rangle$$

where:

• $$\mathit{type} \in \{\mathrm{insert}, \mathrm{delete}\}$$ describes the adaptation operation;
• $\mathit{target}$ specifies the modified element (e.g., activity node);
• $\mathit{who}$ identifies the actor (user or automated system) initiating the change;
• $\mathit{when}$ is the (semantic) timestamp of change creation;
• $\mathit{details}$ may capture ancillary metadata such as impact or annotations.

An Adaptation Log $L_{\mathrm{adapt}}$ extends traditional XES-based event logs by mixing $e_{\mathrm{exec}}$ and $e_{\mathrm{chg}}$ events:

$$L_{\mathrm{adapt}} = \left\{e_{\mathrm{exec}}^1, e_{\mathrm{exec}}^2, \dots, e_{\mathrm{chg}}^1, \dots\right\}$$

The overall Provenance $P$ of an instance is the union of these, mapped to a PROV-compliant semantic model:

$$P = \left\{e_{\mathrm{exec}}\right\} \cup \left\{e_{\mathrm{chg}}\right\}$$

AdProv thus formalizes adaptation provenance as a first-class, queryable data source (Stage et al., 7 Oct 2025).

2. The AdProv Method: Workflow Phases

The AdProv method consists of five ordered phases: Produce, Collect, Store, Retrieve, and Visualize.

1. Produce: Source systems (e.g., Workflow Management Systems) emit process execution events $e_{\mathrm{exec}}$ and, if supported, change events $e_{\mathrm{chg}}$ annotated with the AdProv XES extension.
2. Collect: An Adapter ingests raw logs, parsing both explicit execution and adaptation records. When adaptation events are not explicit, drift detection or model–trace alignment techniques infer $e_{\mathrm{chg}}$ retrospectively.
3. Store: A Controller invokes the “record” operation on one or more registered Providers, which migrate events into persistent storage (graph DB, RDF triple store, or relational PROV table) compliant with PROV-DM.
4. Retrieve: Retrieval is initiated either by users or visualization tools, supporting flexible queries on instance identifiers, time windows, and event types, returning PROV-O or intermediate formats.
5. Visualize: Visualization tools (such as ProvToolbox, ProvViz, ProvViewer) render semantically enriched provenance graphs; activities map to prov:Activity, data objects to prov:Entity, and change operations as specialized prov:Activity nodes with prov:wasInfluencedBy semantics.

This phased workflow delivers end-to-end management of process adaptation provenance, including change detection, semantic harmonization, and visual auditability (Stage et al., 7 Oct 2025).

3. Provenance Holder Architecture

AdProv’s architectural realization is centered on a modular Provenance Holder service:

• Adapter: Exposes CollectProvenance (for ingestion) and RetrieveProvenance (for extraction). Handles protocol translation (e.g., XES→JSON, JSON→PROV-XML).
• Controller: Orchestrates validation, migration, recording, and retrieval of events; asserts schema and access constraints.
• Provider(s): Implement backend-specific storage/retrieval (e.g., Neo4J for graph-based storage, Apache Jena Fuseki for RDF/PROV).
• Persistence: Underlying store, supporting different database paradigms (graph, RDF, relational).

Data flows traverse Producer→Adapter→Controller→Provider (for recording) and Provider→Controller→Adapter (for retrieval). The separation of adaptor/controller/provider concerns enables extensibility and straightforward integration into heterogeneous environments (Stage et al., 7 Oct 2025).

4. Ontological Mapping to PROV-O

AdProv enforces semantic consistency and interoperability via explicit mapping of adaptation events to the W3C PROV Ontology (PROV-O). The principal correspondences are summarized below:

AdProv Concept	PROV-O Class	PROV-O Property
Process Execution Event	prov:Activity	prov:startedAtTime, prov:endedAtTime, prov:wasAssociatedWith
Change Event	prov:Activity	prov:atTime (“when”), prov:wasInfluencedBy
Workflow Data Artifact	prov:Entity	prov:generatedAtTime, prov:wasGeneratedBy
Actor / Resource	prov:Agent	(n/a)
Adaptation Operation	prov:Activity	prov:qualifiedAssociation to Agent
Process Instance	prov:Entity	prov:hadMember (events)

For example, the insertion of an activity node “GoToCart” is captured as a prov:Activity with time, association, and influence relationships, enabling detailed reconstruction and analysis of adaptive provenance trails (Stage et al., 7 Oct 2025).

5. XES Extension for Adaptation Logging

AdProv introduces a dedicated XES extension file (adaptation.xesext) to capture runtime adaptations. Key attributes, all required on change events unless otherwise specified, include:

• change:type (string): “insert” or “delete”
• change:target (string): identifier of the affected model element
• change:who (string): initiator of the change
• change:when (dateTime): timestamp of change creation
• change:details (string, optional): arbitrary metadata

An example XES snippet demonstrates the insertion of the activity “GoToCart” with all adaptation attributes. This extension supports both direct logging and drift-detected change annotation downstream (Stage et al., 7 Oct 2025).

6. Tooling and Implementation

The AdProv prototype is implemented in Java/Spring Boot with a RESTful interface:

• Adapter API: Supports POST /collect for log/event ingestion (XES or JSON) and GET /retrieve?instanceId=…&format=prov-xml for standardized extraction.
• Providers: Neo4J GraphDB backend records execution/change events as nodes with PROV relationships; Apache Jena RDF backend for direct PROV-O triple mapping.
• Visualization: Output in PROV-XML format tools (e.g., ProvToolbox) enables inspection and graphical analysis; activities and inserted actions are distinguished by node type/shape.

Performance evaluation indicates logging of 10,000 events (<1 s), and single-instance retrieval/serialization (~200 ms) on commodity hardware (Stage et al., 7 Oct 2025).

7. Application Scenarios and Evaluation

One representative use case involves runtime adaptation of an online shopping workflow: an ad-hoc request inserts a “GoToCart” step before checkout. AdProv logs both the insertion event and subsequent executions. After completion, provenance retrieval for the process instance produces a graph in which adaptation operations, their initiators, and temporal context are transparent.

Feasibility analysis demonstrates minimal system intrusion provided native XES annotation (otherwise, drift detection infers changes). Visualization immediately exposes adaptation points and provenance links, facilitating forensics, compliance validation, and “what-if” scenario modeling.

Empirical evaluation shows high throughput for both event recording and provenance retrieval, confirming AdProv’s suitability for process-mining, auditing, and advanced provenance analytics in adaptive workflows (Stage et al., 7 Oct 2025).