Case-centric logs (XES & CSV)

Promenade imports two conventional (case-based) event-log formats: XES and CSV. Both describe the same underlying idea — a set of cases, each a sequence of timestamped events — in different levels of structure.

XES

XES (eXtensible Event Stream) is the IEEE standard interchange format for event logs, and the format most process-mining research tooling reads and writes natively. An XES file is XML, structured as:

<log>
  <trace>
    <string key="concept:name" value="order-4021" />
    <event>
      <string key="concept:name" value="Receive order" />
      <date key="time:timestamp" value="2026-01-14T09:12:03Z" />
    </event>
    <!-- more events -->
  </trace>
  <!-- more traces -->
</log>

The concept:name and time:timestamp keys are XES conventions for the activity name and event timestamp; other attributes (resource, cost, custom fields) travel along as additional key/value pairs per event or trace.

Drop an .xes or .xes.gz file onto Promenade and it’s parsed directly — there’s no mapping step, since XES already declares which fields are which.

CSV

Most systems don’t export XES. A CSV export — a ticket system’s audit log, an ERP’s transaction history — is usually “flat”: one row per event, with case, activity, and timestamp as columns among others. Promenade’s CSV importer asks you to map:

• Case ID column — which column identifies the case (order number, ticket ID, …).
• Activity column — which column (or combination of columns) is the activity name.
• Timestamp column — which column is the event time, and its format.

Every other column becomes an event or case attribute you can use for filtering, classifiers, or coloring in later views. The mapping step only needs to be repeated if the export’s structure changes; Promenade remembers the mapping alongside the imported artifact.

Choosing between them

If the source system can export XES directly, prefer it — the semantics are unambiguous and lifecycle information (start/complete, for activities that have a duration) round-trips cleanly. CSV is the pragmatic default for everything else: spreadsheet exports, database query results, log-aggregator dumps.

When neither fits

If your data doesn’t have a single, obvious case identifier — an order with several items, each shipped and returned independently — see Object-centric data instead. Object-centric event data (OCEL 2) is built for exactly that shape.