Event Log

An event log is a detailed record of (a) Entities, or cases in the court context, that are captured via a unique identifier, Case ID. These entities go through (b) Activities occurring within the process. The activities’ names describe what occurred. Examples of court system activities include "complaint" and "verdict". The log also contains (c) the Timestamp at which a specific entity interacted with a specific activity. In the court context, timestamps are recorded as the date when an activity occurred, e.g. the complaint was filed or the verdict was rendered. In addition to the case ID, activities, and timestamps, event logs often include metadata about the entities and activities involved. Accordingly, the event log we provide includes the following additional items:

• Server ID: The judge (or judges) responsible for the event (standardized judge ID code).
• Case attributes: Case metadata and attributes (e.g., nature of suit, number of plaintiffs).

In unstructured processes, activities often exhibit high variability due to contextual differences or noise, resulting in overly detailed models. The challenge is therefore to minimize the number of events per case, but still retain sufficient detail to capture any notable patterns. To achieve this, we created a hierarchical nested structure, with a limited set of broader Activity types and associated Activity Attributes that maintained access to specific details (e.g. 'motion' and the more detailed 'motion to certify class').

Activity attributes provide information that distinguishes one event from another and/or impacts case routing or timing. This means that Activity attributes are either subtypes of Activities or they indicate a feature related to the flow. For example, the activity ‘order’ could have attributes such as ‘default judgment,’ indicating the type of order, and ‘dispositive,’ indicating that this order terminates a claim, a party, or a case. The nested structure preserves the descriptive power of event logs while mitigating the challenges posed by excessive detail. It allows analysts to focus on overarching process dynamics without losing the richness of unstructured data, reducing redundancy, improving clarity, and striking a balance between representation and interpretation.

Our nesting scheme includes 26 Activities and an associated set of 55 Activity attributes. Most of these are defined in the SCALES Litigation Ontology documentation. The event log also includes a set of additional Activities and Activity Attributes, which we developed to capture operations-specific aspects of litigation that the existing SCALES ontology does not cover. They are as follows:

Activity

• R&R: A report and recommendation issued by a magistrate judge to a district court judge after consideration of a pending motion or other matter in the case, offering a non-binding recommendation for how the district court judge should rule.

Activity attributes

• Scheduling: An action by the court that sets a deadline or a date for future activity in the case.
• Rescheduling: An action by the court that changes an existing deadline or date for future activity in the case.
• Hearing/Conference: A hearing, conference, meeting, or other communication between the judge and the parties.