Contract Virtualization

Environment Representation - Artificial Intelligence - Low Cohesion - Object Oriented Programming - Software Engineering - Finance Engineering - Data Science

Introduction

(i) In B2B businesses, contracts reign supreme. These tedious ramblings, with their ambiguous vocabulary, often result in misinterpretation by the company which set them in the first place. Especially, when the host party does not record the practices to be executed by the contract before the bond is committed.

(ii) This proves an interesting, yet overlooked, problem for business leaders. So let's try to work it out.

(iii) A few things make machine comprehension of contracts so difficult. Firstly, the multitude of terms used to describe the same function is dizzying. For example in a pharmacy contract there may be a clause to describe the cost due at the fill of a drug. Well, what counts as a fill? Is it when the drug reaches the patient, when a pharmacist is done touching the bottle, when the bottle has been boxed and leaves the fulfillment facility? There are so many ways to express the implied fulfillment of a product, which one matters? Of the problems to cover that one seems to be most arduous, likely requiring it's own repository to define the structure, but it doesn't. (see 1.1b)

(iv) Modeling how pricing structures are applied to a service is another pain point. Business developers each have their preferred approach to closing the deal with customers. Some customers want a fixed cost, some are okay with a variable price, and sometimes a product may require fixed or dynamic pricing. In any case, the closer will use the model which best fits the need. These models are usually described in large swathes of contract that are not easy reading material. It raises the problem of being difficult to represent and extract after the fact. If these models already existed within a computer system it would save significant time when reverse engineering a contract for running audits. To do this one must be able to represent any and all pricing models to a computer for processing a data source. (see 1.1f)

The value of this solution is immense, and would save countless hours and dollars auditing sources and searching documentation. (see 2.2)

Micro-Service and API representation

(v) The problem outlined above is best solved by implementing a microservice architecture using JSON and JavaScript. For this article, I will be using JSON and JavaScript to draft a solution.

Please note all code exhibited in this work is intended as an example (pseudocode).

Expression of Terms (1)

(1.1a) Let's fall back to the fulfillment example as it's a familiar topic. This example is common to any number of businesses in terms of "completion of services." Though, it can be defined in more proprietary terms.

(1.1b) How does one represent these situations when there is a varied vocabulary surrounding a function? Breaking down the jargon and syntax of legalese yields a format that is easy to represent; we just need to know the product being associated, and what defines fulfillment. In the general sense fulfillment is when an item passes a checkpoint in a procedure. The description is, therefore, a function of time.

{
 product: "Some Product",
 terms: [
   {
     title: "fulfillment",
     data_source: {some JSON object},
     data_field: "shipped_date"
   }      
  ]

}        

(1.1c) One component is still missing from this representation. How do we represent the incursion of cost relative to some unique pricing structure? I ask this because I've seen the same item being priced 5 different ways to 5 customers utilizing the same product. A practice I personally disagree with, but it poses a fun problem.

(1.1d) Pricing is a funky thing. There are a lot of philosophies to consider when building a solution to our current problem. Some atomic methods to consider would be: cost-plus, revenue share, attribution, and fixed cost. But for each of these there are more complex ways of dictating the exact cost given an input variable.

(1.1e) Cost-plus is just a modifier multiplied by or added to an input value. Fixed cost is easiest, it's a fixed value that will be applied for the duration of a contract. Revenue share is more interesting. It requires ante facto knowledge of what revenue is going to be generated by the sale of an item. Once revenue is calculated it becomes your input value, and a certain amount is always expected to be subtracted from it. Attribution poses another interesting exercise. This model associates a portion of revenue as being previously allocated to a vendor. It's most commonly used in accounting, not necessarily for transactional purposes.

(1.1f) Implementing pricing models as a program is a project in its own right. It will follow the same microservice architecture we used above, with a twist!

{
  product: "Some Product",
  terms: [
   {
     title: "fulfillment",
     data_source: {some JSON object},
     data_field: "shipped_date",
     price: {
       type: "Cost-Plus",
       input_source: {
         //some JSON object representing where to find the source field
         input_field: "acquisition_cost"
       },
       input_field: "acquisition_cost"
       dependency: {
         owner: "A Person",
         name: "table_lookup_15percent_cap",
         input_source: {
           ...
           input_field: "acquisition_cost"
         },
         function: ".calculate(dep, src.input_field)" 
       }
     }      
    ]
  }        

(1.1g) The idea of the JSON written above is to represent how to process input variables and where to find the resources hosting the input fields. The cool thing about this is it can be used to generate a JavaScript injection to a database that would calculate revenue values according to the pricing models which may be associated to a product. Furthermore, rather than discouraging JSON injection, it relies on JSON injection to link the product to its constituent functions.

(1.2) Execution

(1.2a) Digging into what the code above means; we've described a section of a fulfillment contract where the customer utilizes "Some Product", is invoiced according to the "shipped_date", and the price is determined by the cost-plus model according to a the cost-plus helper function "table_lookup_15percent_cap." It would mean that if customer C purchased item A on Jan 4, 2023 with an acquisition cost of $1.50 and it falls into the 12% bracket of the table lookup, customer C is charged $1.68 for this product when invoiced for the month of January 2023.

(2) Summary

(2.1) While contract virtualization is a difficult process, it is not impossible. Using a microservice a tool can be created to curate the terms of a contract before it's written or executed. It's just a matter of breaking down the linguistics of legalese into a representable format.

(2.2) Such a tool would be useful for auditing customers, products, general finances, and more. It would also enable analysts to merge transactional services with the tool to track accounts without the need for manual labor. My favorite element of this would be it's applications for automated invoicing.

Copyright ⓒ 2022 Eric DiGioacchino All rights reserved