Skip to content

Legal Objects, Data Models, and Logical Databases

Abstract: This is a high-level specification of ideas and features for the evolution of the Looplex platform. The scope of this document is (1) to explain what Managed Objects are; and (2) to explain what Data Models and Logical Data Models are for the legal world.

What are Objects

In legal engineering, Legal Objects are the fundamental entities you need to consider first to create legal content, applications, or services that will run on the Looplex Platform.

When a Legal Object serves as a model or for instantiating others, it is a Legal Data Model, and when it is instantiated (i.e., it effectively represents something in a concrete situation), it is a Legal Data Object.

Each object has its properties and methods. It can be transformed into a “generic class” of an object, with even more generic classes defined so that objects can share models and reuse definitions in their code.

An object is what actually works on the computer. Individually, all objects have three basic characteristics: identity, state, and behavior.

  1. Identity: Each object has its own identifier and can be distinguished from all other objects. The name or identity of each object is unique and distinct.

  2. State: Refers to the properties of an object. For example, the values of the object’s variables contain data that can be added, altered, or deleted.

  3. Behavior: Refers to the actions the object can perform. For example, an object can respond to another object to execute software functions.

Some programming concepts that can be defined as objects include:

  • Variables, which hold values that can be altered.
  • Data Structures, specialized formats used to organize and process data.
  • Functions, named procedures that perform a defined task.
  • Methods, programmed procedures defined as components of a parent class and included in any instance of that class.

Objects perform actions. For instance, a function or method of the object can be programmed to modify the content of a data structure or variable object based on event occurrences.

The Looplex Dataverse contains data structure models (Legal Data Models), legal logic operations associated with content (Operations), and operational models based on events, which are the Legal Service Models1.

Object Models

A representation of objects, events, and their associations in the real world is called a model. The model helps the legal engineer understand the complexities of a legal domain or the legal system as a whole.

A collection of concepts to describe and manipulate data, relationships between data, and constraints on the data is called a data model. These are the Legal Data Models.

A data object model allows defining the structure of “business data” or a “business object.” For example, an object can represent a “client,” “party,” “clause,” or even a “case,” with attributes like name, address, and other relevant information.

From a data object model, instances of data objects—or simply data objects—can be created, updated, queried in Documents, Workflows, Dashboards, Cases, etc., on the platform, with all structures modeled and standardized.

Data models are conceptually simple: they define a structure (schema) of a business object. This means such a model describes the fields that make up the object and the type of each field, acting as a “container” for these fields.

Legal Data Models and their respective Data Objects do not define how they should be read, created, updated, processed, deleted, or queried. These actions are called Operations in the various engines used by Looplex, and they determine how fields and their values are used to implement the logic of constructing the object.

Operations can be any method or function associated with creating content on the Looplex platform. These operate on data object content within templates, such as dynamic interviews, field determination, variable calculations, etc.

Operations are also used outside the context of document generation, for instance, to automate the lifecycle processes of Documents (Contract Lifecycle Management), Cases (Project Lifecycle Management), and BI (Legal Analytics), such as email dispatch, data synchronization, and data extraction via RPA.

Operations can be encapsulated and abstracted into another logical layer of the platform, simplifying logic creation and manipulation for templates. These functions are called Actions.

In the Lawtex document engine implementation, Actions were called Tubes.

Examples of Actions include Logical Operators and Tubes from Lawtex, Looplex Code operations, Office Render content angular expressions (Looplex365), Flowable service models, standard SQL endpoint calls, and Data Pipes (preset ETL routines), among others.

Actions, in all their names and variations, create a type of logical data model.

When a component containing multiple abstracted and resolved functions is standardized and encapsulated to execute a sequence of predefined steps (data lifecycle execution for a legal operation), it is called a Legal Service Model.

A Legal Service Model allows the creation of operations and Actions freely usable in Document, BI, Process, or Case Templates, simplifying logic depth for legal engineers or modelers.

Supported Implementations

A legal engineer can access and manipulate data from various sources, such as:

  • Database: Use this type of Service Model when accessing our Common Data Service for data object instantiation in Documents and other Templates stored in the Looplex Dataverse databases.
  • API: Use this type of Service Model when data objects to be instantiated exist in an external system. For example, invoking standardized operations for analyzing or extracting data from an unknown external document submitted to our Data Extraction service.

The power and flexibility of Legal Data Models and Service Models become evident when implemented for different types of Templates. Examples include deadline calculations for creating a paragraph in a Document, a Dashboard or email alert, generating a timeline update in a Case, or defining task type and due dates in automated BPA workflows.

Local Models and Common Data Model

Legal engineers can create service and data object models locally for a specific Project or Program of Projects or globally for use across any content or management scenario on the Looplex platform.

Creating local models is useful for certain projects, such as organizing shared data access among various Templates (formerly “Document-to-Document” communication), stored in a special SQL Table for querying.

However, this local implementation lacks the scalability and fungibility of a model usable universally in any project requiring that context.

For this, we have the Common Data Model. Thus, only entities normalized and specified according to our Common Data Model are called Legal Data Models.

Similarly, implementing a service model applicable in any scenario with the same context (e.g., a judicial deadline calculation for assigning a due date to a Legal Snippet in a contestation) becomes a Legal Service Model.

The complete Looplex platform environment allows consuming data from various sources—normalized in the Common Data Model, structured in local models, unstructured in a data lake, or accessed externally. This data consumption is managed through Looplex’s API services.

Footnotes

  1. For more information about data models and databases, see this conceptual and introductory article: https://guidervision.com/what-is-database-model-types-of-database-models/