System and method for generation of user advisories using generative ai in contract analysis

Abstract

A system, apparatus and method for contract classification processes both primary contracts and their associated documents using context window marshalling. The computing device receives and segments each contract document into contextual chunks based on semantic boundaries, maintaining coherent meaning. A marshalling queue processes chunks sequentially, storing processed data within defined context windows, cross-references between chunks, and a running context buffer of key elements. The system identifies parties and contract categories by aggregating information across processed chunks from all related documents, then determines risk parameters using a classifier that considers contractual elements, cross document relationships, and contextual importance weights. Risk recommendations are calculated based on these parameters, identified parties, class categories, and aggregate metrics computed across document and chunk boundaries.

Description

TITLE OF INVENTIONSYSTEM AND METHOD FOR GENERATION OF USER ADVISORIES USING GENERATIVE Al IN CONTRACT ANALYSISCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] Cross-Reference to Related Applications This application claims priority to provisional application number 63 / 617505, filed January 4, 2024, provisional application number 63 / 592992, filed October 25, 2023 and provisional application number 63 / 593004, filed October 25, 2023, the entire contents of which are incorporated herein by reference.BACKGROUND

[0002] Human contract analysis, drafting, execution and management has always been plagued by a number of human weaknesses in dealing with complex issues.

[0003] Inconsistency in tracking: The variability in transactions, especially on third-party documents, hinders consistent tracking and collection of trustworthy contract data across different deals.

[0004] Starting over on each new contract: Due to the unavailability of past agreements and summaries, many contracts have to be initiated from scratch, wasting time and resources.

[0005] Manual Labor Intensiveness: A lot of time is consumed on tasks such as renewals and negotiations, which are challenging to automate.

[0006] Missed Relationship Opportunities: There's a missed opportunity to use historical contract insights to enhance and personalize customer interactions.

[0007] Lack of Guidance in Drafting: Without insights or recommendations from previous contracts, creating compliant and optimal new contracts becomes problematic.

[0008] Complex Language Barriers: The intricate legal jargon used in contracts confuses business users and frequently necessitates the intervention of specialized legal teams, adding to time and cost overheads.

[0009] Given the inability for humans to have the capacity, a number of platforms have turned to Al to help the humans cope with this complexity in contracts. However, using Al especially Generative Al has resulting in a new and more complex problem set than anticipated.

[0010] Generative Al models lack an inherent grasp of control flows, rules, and logical reasoning, relying instead on statistical patterns from training data. Despite advances in research, enabling generative models to have explicit reasoning and rule-following capabilities remains a challenge.

[0011] Techniques such as chain-of-thought prompting only offer a framework for logical sequence of inferences rather than a complete solution. While reinforcement learning allows models to adopt basic rule-based behaviors, they still struggle with intricate control flows.

[0012] Predominant generative Al models like GPT can produce fluent outputs but often falter in logical consistency, factual precision, and compliance with intricate rules.

[0013] The reliability of these models diminishes over extensive chains of inference due to the absence of an explicit rule model.

[0014] Alternative approaches using contract Gen Al focusing on structured knowledge and reasoning, such as semantic parsers and theorem provers, offer more accuracy in modeling complex rules but may not be as fluent or encompassing in knowledge.The Challenge of the LLM Context Window:

[0015] Training a Large Language Model (LLM) to understand contracts, addendums, and associated legal documents is a complex endeavor. One significant challenge is the inherent complexity and ambiguity in legal language. Legal documents often contain phrases that are intentionally broad to cover various scenarios or are couched in terms that have evolved specific meanings over centuries of legal practice. For a model, discerning the nuances and specific intentions behind such phrasings can be difficult.

[0016] Additionally, contracts often reference external laws, regulations, and previously agreed-upon terms. Without a comprehensive contextual understanding, an LLM might misinterpret a clause because it doesn't understand an external reference or how it interacts with the rest of the document. This interconnectedness of legal documents makes them particularly tricky for models that operate primarily on the immediate context they're given.

[0017] Moreover, legal language often evolves based on case law. That is, the interpretation of a phrase in a contract might depend on legal precedents set by courts in prior cases. Without access to this vast body of evolving case law, or without understanding the implications of a particular precedent, an LLM might not provide an accurate interpretation of a contract's terms.

[0018] Cultural and jurisdictional differences add another layer of complexity. Contracts drafted in different countries or legal systems might use similar terms but mean different things, based on the local legal tradition and practice. Training a model to understand these distinctions and provide accurate interpretations for diverse legal systems is challenging.

[0019] Lastly, the stakes in interpreting legal documents are incredibly high. Misinterpretations can lead to costly litigation, financial losses, or breaches of regulatory compliance. While LLMs can assist in understanding and drafting legal documents, relying solely on them without human oversight can pose significant risks.

[0020] The inventors have identified the following problems with managing Context Windows in LLM

[0021] The first problem identified is a limited ability to process long sequences. LLMs can only process a certain number of tokens at a time, which limits their ability to understand and respond to complex or long-form text. This is especially problematic in long lifecycle documents like Master Service Agreements that have many orders or addendums that occur chronologically over over a period of years.

[0022] Another problem identified is difficulty tracking long-range dependencies. LLMs can struggle to track long-range dependencies in text, which can lead to errors in tasks such as question answering and summarization. This is especially prevalent in very long contracts where changing effective and termination dates are rarely disclosed.

[0023] Another problem identified is increased risk of hallucination. LLMs can hallucinate, or generate false or misleading information, especially when given a large context window. Hallucinations in generative Al summarization occur when the model generates information that is not explicitly present in the input documents. These hallucinations can stem from various factors, including model biases, ambiguity in the source text, or inconsistencies within the dataset. Addressing this problem is crucial, especially in applications where the generated summaries are used for decision-making or legal purposes, such as contract analysis.

[0024] Another problem identified is increased computational cost. Training and deploying LLMs with large context windows are computationally expensive.

[0025] Another problem identified is reduced model portability. LLMs with large context windows are less portable and can be difficult to deploy on edge devices.

[0026] Another problem identified is increased risk of overfitting. LLMs with large context windows are more likely to overfit to the training data, which can lead to poor performance on unseen data.

[0027] Another problem identified is difficulty adapting to new domains. LLMs with large context windows can be difficult to adapt to new domains, such as medical or legal text.

[0028] Another problem identified is reduced fairness. LLMs with large context windows can be biased, reflecting the biases in the training data.

[0029] Another problem identified is increased security risks. LLMs with large context windows can be more vulnerable to adversarial attacks.

[0030] Another problem identified is that data quality of contracts ingested for review is generally poor.FIELD OF THE INVENTION

[0031] The field of the solution relates to computer implemented methods for the automated analysis or use of data, including use of a large language model (LLM), and to related computer implemented methods and systems as used to review and analyze large copra of contracts and other associated documents throughout the life span of the contracts.BRIEF SUMMARY OF THE INVENTION

[0032] One of the solutions proposed fixes a persistent challenge with LLMs is memory management. Given the vastness of language and the complexity of human context, a model can't simply remember everything it has ever seen. Instead, it operates within what's termed a "context window."

[0033] The context window is essentially the immediate span of tokens (words, characters, or subwords) the model considers when generating a response or understanding context. For example, GPT-4, one of OpenAI's LLM variants has a context window of ranging from 2048- 32,000 tokens. The context window restricts the model's immediate "lookback." If a piece of information or context appears outside this window, the model won't directly consider it for its immediate response. So, handling long sets of texts is a problem If you feed an LLM a text that exceeds its context window, it will only consider the most recent tokens within that window.For instance, if you input a 3000-token text into a model with a 2048-token window, the earliest 952 tokens won't be directly considered in the model's response. Extending the context window is computationally complex and most LLM models restrict to maintain contextual relevance. Them context window ensures that the model gives more weight to immediate and relevant context. If you're asking the model about a specific topic like termination terms, it will focus on the surrounding information, ensuring that the generated output is pertinent to the current contract or set of contracts.

[0034] Computational efficiency: as mentioned previously, confining the model's focus to a limited number of tokens, the context window ensures computational efficiency. Without this restriction, the task of real-time text generation or comprehension might become computationally prohibitive.

[0035] The present solution uses a plurality of methods and processes to overcome this context window issue. An aspect of the solution: A method is described wherein a processing system uses contract data, structured in a machine-readable language, to furnish new contractual analysis using an LLM to interpret and analyze contracts, addendums and other related documents attached by reference or other means.

[0036] Another Aspect of the solution: A method involves relaying contract data from one system via an LLM to a system that employs structured, machine-readable data. This system then evaluates and refines the LLM's output for an improved contract intelligence outcome experience.

[0037] Another Aspect of the solution: An LLM produces continuation data using feedback from a processing system that employs structured data. Here, the LLM uses this feedback as supplementally generated prompts to narrow and refine for superior text output. This method amplifies the quality of the processing system's output.

[0038] Another aspect of the solution. The solution can summarize state of the commercial relationship between two entities based on contractual agreements signed to date regardless of the contract origin. By using natural language risk assessment and negotiation playbook to assess commercial relationship risks associated with effective commercial terms, and to guide negotiation in order to mitigate them. The solution leverages historically signed contracts between parties to help the parties negotiate based on either paper, provide neutral risk context,draft agreements in either parties style or autogenerate relevant amendments, statements of work, and orders and allow assessments of critical points for who is required to sign.

[0039] Another aspect of the solution will be to have chatbot interactive sessions allowing user to ask questions about the commercial relationship and its agreements.BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0040] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0041] FIG. 1 illustrates an aspect of the Gen Al Control Environment in accordance with one variant of the solution.

[0042] FIG. 2 illustrates an aspect of the ingestion process in accordance with one variant of the solution.

[0043] FIG. 3 illustrates an aspect of the object model in accordance with one variant of the solution.

[0044] FIG. 4 illustrates an aspect of the solution apparatus in accordance with one variant of the solution.

[0045] FIG. 5 illustrates an aspect of the ingestion flow and result in accordance with one variant of the solution.

[0046] FIG. 6 illustrates an aspect of the subject matter in accordance with one solution variant.

[0047] FIG. 7 illustrates an aspect of the subject matter in accordance with one solution variant.

[0048] FIG. 8 illustrates an aspect of the subject matter in accordance with one solution variant.

[0049] FIG. 9 illustrates an aspect of the subject matter in accordance with one solution variant.DETAILED DESCRIPTION

[0050] The disclosed technology encompasses systems, methodologies, and / or computer program commodities at varying degrees of technical integration. Such a computer program commodity may comprise a machine-readable storage medium (or multiple mediums) bearing machine-executable instructions to prompt a processor to execute components of the specified technology.

[0051] This machine-readable medium is a physical entity capable of maintaining and storing instructions to be utilized by an instruction execution apparatus. The medium could be, for example, but not restricted to, electronic, magnetic, optical, electromagnetic, semiconductor storage devices, or a fusion of these. A non-limiting list of specific instances of the machine- readable medium includes portable computer diskettes, hard drives, RAM, ROM, EPROM or Flash memory, SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, and mechanical devices like punch-cards or tangible structures with instructions. It should be clarified that the aforementioned medium does not consider transitory signals in isolation, like free-propagating electromagnetic waves or electrical signals over wires.

[0052] The machine-executable instructions detailed can be transferred to diverse computational devices from the machine-readable medium or an external computer or storage via networks like the Internet, LANs, WANs, or wireless networks. Such networks may integrate copper or optical fibers, wireless transmission mechanisms, routers, firewalls, switches, gateway computers, and edge servers. Within each computational device, a network interface or adapter fetches the instructions from the network, forwarding them for retention in the device's machine-readable medium.

[0053] Instructions facilitating operations of this technology might be encoded as assembler instructions, ISA instructions, machine codes, microcodes, firmware instructions, circuit configuration data, or code (both source and object) in diverse programming languages. Examples include but aren't restricted to object-oriented languages like Python, Java, C++, and procedural ones like the "C" language. These instructions might operate wholly on a local computer, partly on local and remote computers, or entirely remotely. Remote computers can be linked via networks, inclusive of the Internet via ISPs. In certain cases, hardware such as FPGAs or PLAs could employ the instructions, utilizing their state data to modify the hardware to actualize facets of the technology.

[0054] The technology's facets are expounded with reference to flowcharts and block diagrams of methods, systems, and computer program products per its solution variant s. Each block in these can be realized via machine-executable instructions. These instructions could be presented to a processor in general-purpose computers, specialized computers, or other programmable data apparatuses, crafting a machine that institutes the functions denoted in the diagrams. Furthermore, these instructions could be conserved within a machine-readable medium directing device to operate in a specific fashion. The instructions could also be loaded onto a computer or device to prompt a sequence of tasks producing a computer-driven process.

[0055] The depicted flowcharts and diagrams exhibit potential system, method, and product architectures and functionalities per the technology's solution variant s. It's essential to note that these blocks, or their combinations, can be realized by hardware systems specifically designed for those tasks or combinations of hardware and machine instructions.

[0056] While multiple solution variant s has been detailed, skilled individuals will recognize that modifications can be made without diverging from the broader aspects of the technology. The term "user" here pertains to any individual or entity interacting with the described contract analysis and generation system. "User device" signifies any computational apparatus, from PCs to mobile devices like smartphones, laptops, wearables, and more, employed to access the system. The term "entity" encompasses organizations or user groups engaging with the system, such as businesses or companies either operating or accessing the system.

[0057] This solutions generative Al contract management offers a process and a system of advanced tools designed to streamline and enhance the handling of business contracts. With the Contract Summary feature, users can employ specific Al prompts to efficiently distill the essence of contracts, orders, and organizational playbooks. The system traces the lineage of contracts, capturing the initial agreements and any subsequent amendments, and provides concise summaries of orders and negotiations, eliminating the need for extensive research.

[0058] Next, the Compare Playbook tool harnesses the power of generative Al to assess and compare contracts against the organization's negotiation playbook. This includes a deep examination of both historical and draft agreements to identify deviations. Each deviation is analyzed for its relative risk, ensuring previously negotiated deals' compliance and alerting users to potential pitfalls in draft agreements. By pinpointing deviations and their associatedrisks, the system recommends the necessary personnel for approval, ensuring adherence to organizational policies.

[0059] Finally, the Draft Contract feature identifies deviations in executed agreements that surpass organizational risk tolerance. In light of this the draft contract tool can automatically generate draft amendments. This draft retains the core essence of the agreement but incorporates language tweaks to ensure alignment with the company's negotiation standards. By doing so, it drastically reduces the manual workload for legal teams, enabling them to concentrate on refining the auto-generated language, thereby accelerating the deal cycle time and ensuring robust compliance with company policies.

[0060] The system comprises a User Device 102, a Network 104, a SaaS Contract Platform 108, a Data Repository 110, an Al Module 612, a Training Data Repository 114, an Ingested Contracts 116, a Risk Recommendation 118, and a Contract Draft Generator 120. Displayed in the FIG. l, one or more user devices are operationally linked through a network to one or more entity systems. Consequently, the user devices can transmit and retrieve data from the entity systems. In the depicted solution variant, several user devices might connect with the entity systems via the network.

[0061] FIG. l provides just one variant of the solution of a computer system. In alternative configurations, certain systems, devices, or servers might be amalgamated into a single unit, or be divided into multiple units. It should be inferred that the various servers, systems, and devices can be amalgamated in different variants while retaining analogous functionality.

[0062] For example, the network might be a dedicated distributive network which identifies specific network triggers. Moreover, the network could be a Global Area Network (GAN) like the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any fusion of such networks. This network can facilitate wired, wireless, or combined communications. Additionally, the network might encompass a peer-to-peer communication system.

[0063] Both the entity systems and user devices possess data storage and processing capabilities, holding data pertinent to the system environment, including data devised by various system applications. The contract analysis and generation system's diverse applications and their associated data may reside within the memory of the entity systems and user devices. In some versions, users might engage with the contract analysis and generation system via a user interface. This interface is designed for simple contract generation.

[0064] FIG. 1 details singular modules and repositories for simplicity, but the solution and its variants comprise complex combinations of repositories, databases, and Al modules. These components work in concert to provide a comprehensive contract analysis and management system.

[0065] The user interface is designed for efficiency, offering single-click contract analysis. This streamlined approach allows users to quickly initiate comprehensive contract reviews without navigating through multiple menus or options.

[0066] A data repository houses an extensive collection of contract clauses. This repository serves a critical function by verifying the inclusion of all vital clauses in a contract. It acts as a safeguard, ensuring no essential elements are overlooked during contract creation or review.

[0067] One of the Al modules employs a model trained on a vast array of queries. This model is adept at determining whether human-input questions have default responses. When applicable, it intelligently inserts these pre-determined answers while providing contextual output, ensuring relevance and accuracy in the responses.

[0068] Another Al module is built around a database of keywords and links to various regulations, (e.g., Federal Acquisition Regulations (FAR). This module is fine-tuned to export unique and necessary contract wording that aligns with relevant regulations, ensuring compliance and precision in contract language.

[0069] Another Al model is trained to extract contract terms using a curated list of terms. This capability allows for rapid identification and isolation of key contractual elements, streamlining the review and drafting processes.

[0070] Another repository employs Named-Entity Recognition (NER) technology. Its primary function is to identify and exclude keywords that are not considered variables in a contract from the working text. This refinement process helps focus attention on the most relevant and adaptable parts of the contract.

[0071] Another Al model in the solution variant is designed to classify anticipated contract issues into distinct categories or classes. This classification system aids in organizing and prioritizing potential contract concerns, allowing for more efficient problem-solving and risk management.

[0072] Another Al module handles comparative analysis, by conducting various types of comparisons, including:1. Comparing different contract templates2. Analyzing contracts against established templates3. Examining distinct versions of the same contract

[0073] Moreover, this Al module can dissect party details, transforming them into structured lists and contract templates.

[0074] Another Al module would be a multilevel prompt generator.

[0075] The contract lifecycle management module is engineered to oversee every stage of a contract's lifecycle. This includes creation, negotiation, approval, execution, and post-execution management, ensuring approach to contract administration.

[0076] In more advanced implementations, the system can integrate with external Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) systems. These systems serve as rich data repositories, retaining crucial information about users, entities, and their associated devices. This integration allows for a more comprehensive view of the contractual landscape within an organization's broader operational context.

[0077] Certain modules within the system, particularly the party management module, can access these ERP and CRM systems using established Application Programming Interface (API) techniques. This interoperability ensures smooth data flow and consistency across different organizational systems.

[0078] FIG. 2 illustrates a high-level complex control flow showing how a variant of the solution would work in assessing contract risk. According to an example of the solution, the method includes analyzing an Agreement Collection 216 comprising a Master Services Agreement MSA 202 and Amendment 204. The Effective Terms 220 are extracted comprising Assignment 206, Payment Term 208, Price Increase 210, and Other Terms 212. The GENAI 224 checks Check Rule A.2.1 226, a Check Rule A.2.2 228, a Check Rule A.2.3 230, a Check Rule Pl 232, and a Check Rule PT.l 234 against the extracted Effective Terms 220, example categorizes the Agreement Collection 216 into three responses High Risk (GC / Deal Desk ) Approval Needed 214, Medium Risk (Deal Desk Approval) 218, and Low Risk (No Approvals 222 for review and clearance for the Effective Terms 220

[0079] Although the example routine depicts a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does notmaterially affect the function of the routine. In other examples, different components of an example device or system that implements the routine may perform functions at substantially the same time or in a specific sequence. As another example of the solution variant, a set of hardware and software would ingest a set of contracts, parsing their constituent parts, supplemental documents like amendments, statements of work, appendices, codices and other correspondence and associated communications. The parser breaks the documents into effective terms, (e.g. Assignments, Payment terms, Pricing, other key items) These terms are then fed into a set of generative Al rules that are associated with assessing the risks related to various states or effective terms in a particular contracts and outputs a risk rating for the particular contract or contract effective term that is then routed to an appropriate authority for review. (e.g. General Counsel, Deal Desk or normal no / low risk outcome. The platform then generates three types of prompts.

[0080] Summarize Contracts prompt - this prompt will create a summary of the lineage of contracts for a business relationship, including the original agreement and any follow-on amendments.

[0081] Summarize Orders prompt - summarizes all the orders executed for a business relationship like products sold / purchased renewal dates, etc.

[0082] Summarize Playbook prompt - summarizes the organization’s negotiation playbook converted from raw form into defined rules by SI.

[0083] The solution then feeds the contracts into the LLM in a fashion that minimizes hallucination or improper context to be drawn from the representative parts of the contracts being analyzed.

[0084] An example of a solution variant is as follows: A system, apparatus and method for contract classification processes both primary contracts and their associated documents using context window marshalling. The computing device receives and segments each contract document into contextual chunks based on semantic boundaries, maintaining coherent meaning. A marshalling queue processes chunks sequentially, storing processed data within defined context windows, cross-references between chunks, and a running context buffer of key elements. This chunking and storing process repeats until all associated contract documents are processed. The system identifies parties and contract categories by aggregating informationacross processed chunks from all related documents, then determines risk parameters using a classifier that considers contractual elements, cross-document relationships, and contextual importance weights. Risk recommendations are calculated based on these parameters, identified parties, class categories, and aggregate metrics computed across document and chunk boundaries. The system ranks contracts by evaluating both individual chunk risks and wholecontract assessment, weighting risks based on contextual significance and inter-chunk dependencies across all related documents. Change recommendations are generated that correlate contractual elements with risk levels, identify high-risk chunks and their relationships, and suggest modifications considering cross-document impacts. This approach enables processing of contracts and their associated documents that exceed single context window limitations while maintaining semantic coherence and relationship preservation throughout the entire document collection.

[0085] Data Grounding for LLMs: The solution implements robust data grounding techniques to ensure the LLM's outputs are reliable and relevant. Grounding data connects the LLM's knowledge to real-world facts and figures, similar to teaching children about concepts through direct experience rather than abstract definitions. This solution variant addresses several challenges:1. Real-life interaction: Grounding helps the LLM understand and use real- world data, making its responses more accurate and reliable in the context of contract management.2. Context relevance: It enhances the LLM's ability to generate contextually relevant answers by connecting abstract legal concepts to real-world examples and specific contract details.3. Error reduction: Grounded LLMs are less likely to produce Al hallucinations, as they are anchored to trusted sources of information, crucial for maintaining accuracy in legal documents.4. Flexibility: LLM grounding allows the Al model to adapt to changes in contract law, company policies, and industry regulations more effectively.

[0086] The solution variants use these various techniques for grounding LLM data.1. Document Embedding: Contract documents are converted into vector embeddings, allowing the LLM to efficiently search and retrieve relevant information.2. Knowledge Graph Integration: A contract- specific knowledge graph is constructed, linking related terms, clauses, and concepts. This helps the LLM understand complex relationships within and between contracts.3. Pre-training on publicly available legal / contract corpora: The LLM is pre-trained on diverse legal datasets to enhance its foundational knowledge of contract law and legal language.4. Fine-tuning on domain- specific data: The LLM is further fine-tuned on anonymized contracts and legal documents specific to the company or industry, enhancing its understanding of specialized terms and practices.5. Retrieval-Augmented Generation (RAG): When generating responses, the system uses RAG to retrieve relevant contract data and incorporate it into the LLM's output, ensuring accuracy and reducing hallucinations. This technique injects the LLM with trusted enterprise data in real-time during response generation.6. Incorporating external knowledge bases: The solution links the LLM to external legal databases and industry-specific knowledge bases for up-to-date information on regulations and best practices.7. Post-processing and validating: The solution conduct post-processing checks to validate LLM outputs against specific legal criteria or thresholds, catching and correcting errors before the final response is delivered.8. Contextual Understanding: By grounding the LLM in company- specific data, industry regulations, and legal precedents, the system provides advice and insights tailored to the user's specific business context.9. Version Control and Diff Analysis: The grounded LLM can analyze different versions of a contract, highlighting changes and potential implications based on its understanding of legal language and business practices.10. Compliance Checking: Leveraging its grounded knowledge of regulations and company policies, the LLM can automatically flag potential compliance issues in contracts.11. Intelligent Clause Suggestion: Based on the context of the contract and grounded data from similar agreements, the solution can suggest relevant clauses or modifications to existing ones.

[0087] By implementing these advanced grounding techniques, the generative Al contract management solution ensures that its outputs are as contextually accurate and up to date aspossible. This approach significantly enhances the solution's reliability, reducing the risk of errors or misinterpretations in contract handling, which is crucial in legal and business contexts.

[0088] As grounding techniques continue to advance, future iterations of this system will likely become even more accurate and dependable, potentially expanding its application to more complex legal scenarios and a wider range of industries and domains.

[0089]

[0090] Displayed in the FIG. 3, the solution variant that uses context window marshalling process to avoid accuracy issues using a First in First out Queueing process. The process is as follows:1. Contracts and their parts are submitted to the LLM in a queue. This queue can be implemented in a variety of ways, such as a database table, a message queue, or a simple file. Also, contracts can be submitted to the queue in a variety of ways, such as through a web interface, an API, or a batch processing system. The specific method of submission will be different based on the desired user input mode.2. The LLM analyzes the first contract in the queue. The LLM is trained on a specific dataset of contract rules and patterns in order to perform this task effectively.3. Once the LLM has finished analyzing the contract, it generates a report. This report can include information such as the key terms of the contract, the risks associated with the contract, and any potential legal issues.4. The LLM then removes the analyzed contract from the queue and moves on to the next contract.5. This process repeats until all of the contracts in the queue have been analyzed.6. After the contracts are ingested, the system weights various risk rules associated with the risk profile associated with general contract risk and risk tolerances of the particular entity using the LLM. Upon request, the system generates a risk report. This report can include information such as the key terms of the contract, the risks associated with the contract, and any potential legal issues. The specific format and content of the report will depend on the specific implementation of the LLM.

[0091] One of the significant benefits to the staging of the ingestion and analysis of a document as demonstrated by this solution is demonstrated by this example. This apparatus describes a system, method and apparatus for analyzing and classifying contracts and their associated documents. At its core, it's designed to process contracts that are too large to be analyzed in a single pass while maintaining their semantic meaning and relationships throughout the analysis.

[0092] The system begins by receiving contract documents and breaking them down into meaningful chunks based on semantic boundaries. These chunks are processed sequentially through a marshalling queue, with each chunk being analyzed while maintaining important contextual information within a defined window size. The system tracks cross-references between chunks and maintains a running buffer of contract elements to ensure nothing important is lost during processing.

[0093] A key feature of the apparatus is its party identification capability, which determines who the contracting parties are and categorizes the contract type based on accumulated information from the processed chunks. The system then performs a comprehensive risk assessment, evaluating contract elements, relationships between different sections, and the contextual importance of distinct parts based on their position and cross-references.

[0094] The risk assessment process culminates in a detailed risk recommendation that takes into account contract parameters, the identified parties, the contract category, and risk metrics calculated across chunk boundaries. The system then ranks the contract based on these risk parameters, considering both individual chunk risk levels and whole-contract risk assessment, while weighing risks based on contextual significance and inter-dependencies between different sections.

[0095] The apparatus includes sophisticated handling of contract hierarchies, particularly for Master Services Agreements (MSAs) and their associated documents. It can establish and maintain parent-child relationships between MSAs and their subordinate Statements of Work (SOWs) and addendums. The system creates cross-mapped references between different documents and maintains a unified context buffer that preserves the hierarchical structure across all related documents.

[0096] For SOWs specifically, the system can break down deliverables, timelines, and acceptance criteria into discrete chunks while maintaining bidirectional links to their governingMSA provisions. When processing addendums, the system identifies which specific sections of the MSA or SOW are being modified, ensures semantic alignment with the original documents, and recalculates risk parameters to account for changes across all related documents.

[0097] Finally, the apparatus includes version control capabilities that track the chronological sequence of modifications, maintain separate processing queues for different versions, and preserve historical context while updating active content. This allows for comparative risk assessments between different versions of documents to highlight how risk profiles change over time.

[0098] The system's ultimate output includes specific recommendations for contract changes, identifying correlations between contractual elements and risk levels, highlighting high-risk sections and their relationships, and suggesting modifications that take into account the impact across different parts of the contract.

[0099]

[0100] FIG. 4 describes a contract object model for a variant of the present solution. The model displayed only lists some of the metadata and commercial terms. The solution object model is structured to capture the key elements and attributes of a contract while also being flexible enough to be used across different types of contracts. Examples of this solutions objects include.

[0101] . Contract Metadata:1. Contract ID: A unique identifier for the contract.2. Title: The title or name of the contract.3. Date Created: The date the contract was created.4. Last Modified: The date of the last modification.5. Contract type: The type of the contract (e.g., lease, employment, vendor).6. Status: Current status (e.g., active, expired, terminated).

[0102] Parties Involved:1. Primary Party: The main party or entity entering into the contract.2. Secondary Party: The other party or parties involved.3. Representative: Legal representatives or contact persons for each party.4. Company Level / Group5. Account Maps6. Associated 3rd Party product or service providers.

[0103] Key Commercial Terms:1. Duration: Start and end date of the contract.2. Payment Terms: Details about payment amounts, frequencies, and methods.3. Termination Clauses: Conditions under which the contract can be terminated.4. Fees associated with the performance of the contract other than payment (termination fees / audit fees / etc.)5. Obligations: Responsibilities and duties of each party.6. Rights: Rights granted to each party under the contract.7. Export / Off shore Restrictions8. Most Favored Nation9. Exclusivity10. Geographical Reach11. Audit Requirements12. Licensing Requirements

[0104] Common or Unique Clauses and Provisions:1. Confidentiality: Details about confidentiality and non-disclosure.2. Liability: Clauses related to indemnity, limits of liability, etc.3. Governing Law: The jurisdiction and laws governing the contract.4. Dispute Resolution: Mechanisms for resolving disputes (e.g., arbitration).

[0105] Attachments and other Related Documents1. Related Documents: Links or references to external documents or previous versions.2. Schedules: Detailed schedules or appendices attached to the contract.3. Statements of Work or Orders

[0106] Review and Analysis:1. Risks Values and Risk Change values2. Recommendations and previous recommendations3. Al Summary of the aggregated contract

[0107] Signatures:1. Signature Primary: Digital or scanned signature of the primary party.2. Signature Secondary: Digital or scanned signature of the secondary party.3. Third Party Approvals

[0108] This object model is modular, so sections can be added, removed, or modified based on the specific type of contract and the requirements of the organization. Solution also facilitates the LLM's ability to understand, analyze, and generate content related to contracts or subsequent addendums and statements of Work. I

[0109] FIG. 5 is an example of a playbook generated by solution variant. A unique feature of this solution will generate a playbook as guidance for a less experienced negotiator to prevent the user from giving away negotiated points that open the company to risk. Examples of Risk Points and Guidelines beyond the exemplar drawing would also comprise:

[0110] Solution Risk Point Identification:1. Flagged Unique Contract Type: Without clarity on the type of the contract, (e.g a services contract format used for product delivery.)2. Undefined or Ambiguous Parties: Often 3rd party obligations creep into contract language, by not clearly identifying all involved parties can lead to future disputes.3. Unclear or Conflicted Duration: Without a well-defined duration and renewal terms, there may be unintended contract extensions or premature terminations.4. Conflicting Payment Terms: Ambiguous payment conditions can result in financial discrepancies.5. Termination Ambiguities: Unclear termination conditions might lead to unintended penalties or breach of contract.6. Loose or Missing Confidentiality Clauses: Inadequate confidentiality or non-disclosure terms can risk leakage of sensitive information.7. Governing Law: Agreeing to jurisdictions that are hostile to the company is a significant risk point.8. Undefined Dispute Mechanisms: Without clear dispute resolution methods, disagreements can become protracted or costly.9. Overlooked or Unique Special Provisions: Missing out on unique or unusual terms can introduce unexpected obligations or rights.10. Unchecked Liabilities: Not assessing potential liabilities can expose the organization to undue risks.11.

[0111] Solutions Categories for Guidelines for Procurement1. Clearly Define the Contract Type: Limiting the types of contracts to be accepted.2. Identify All Parties and update negotiation playbook: Ensure all entities involved in the contract are clearly listed.3. Establish Clear Contract Duration: Limit contracts to the minimums and maximums.4. Detail Payment Terms: Lists of cleared payment amounts, frequencies, methods, and conditions.5. Clear Termination Clauses: List the minimum and maximum grounds for contract termination and any associated penalties.6. Confidentiality Minimum Guidelines: Ensure robust clauses for confidentiality or nondisclosure are in place.7. Governing Law as listed: Clearly state the legal jurisdiction governing the contract.8. Permitted Dispute Resolution Mechanisms9. Flagging Special Provisions:10. Flagging other solution Risks and Liabilities as needed

[0112] FIG. 6 is an example of a historical look back at previous contracts with an entity or entity group that would inform the negotiations of a current contract. Other aspects of historical risk extracted from historical contracts also comprise:1. Problem Clauses: Previous contracts might contain clauses that have historically resulted in disputes or unfavorable outcomes.2. Performance on Payment: Past contracts may have ambiguous or inconsistent payment terms and performance that caused financial discrepancies or disputes.3. Problem or Missing Definitions: Definitions that have caused historical disputes.4. Risky Termination Clauses: Historical termination clauses were either too rigid or too lenient, affecting the parties involved in negative formats.5. Mismatched Expectations: Previous contracts might have set expectations that were not met, leading to dissatisfaction or breaches.6. Overlapping Jurisdictions: Historical contracts may have had unclear or conflicting jurisdiction clauses, complicating dispute resolutions.7. Problematic Obligations: Past contracts might not have clearly delineated the responsibilities of each party.8. Inadequate Dispute Resolution Mechanisms: Previous agreements may have lacked a clear mechanism for handling disputes, leading to prolonged or unresolved disagreements.9. Unfavorable Auto Renewal Terms: Past contracts might have auto-renewal terms that were not in a party's favor or went unnoticed.10. Missed Deadlines or Milestones: Historical instances where critical deadlines or milestones were missed, leading to penalties or breaches.11. Weak Indemnity Clauses: Historical contracts may have had inadequate indemnity clauses, leading to financial burdens.

[0113] FIG. 8 is an example of Guidelines for a new draft contract based on the solution's assessment. This example recommends three areas of concern for the negotiators.

[0114] Summarize Contracts prompt - this prompt will create a summary of the lineage of contracts for a business relationship, including the original agreement and any follow-on amendments .

[0115] Summarize Orders prompt - summarizes all the orders executed for a business relationship like products sold / purchased renewal dates, etc.

[0116] Summarize Playbook prompt - summarizes the organization’s negotiation playbook converted from raw form into defined rules by Al.

[0117] FIG. 9 shows the construction of a proposed amendment or draft from the playbooks or summaries.

[0118] In conclusion, a generative Al (GenAI) contract platform can complete tasks a human cannot perform, an example is provided below throughout the lifecycle.

[0119] Contract Lifecycle: Request Stage• Traditional: Contract initiation often happens through emails, without any systematic tracking or visibility, leading to inefficiencies in resource allocation.• GenAI: Offers streamlined contract initiation by combining conditional logic forms and Al insights, optimizing the process and providing proactive notifications and risk assessments before the contracts are drafted.

[0120] Contract Lifecycle: Authoring & Approval• Traditional: Lawyers often face the challenge of choosing the right template due to a multitude of them, leading to manual effort and inconsistencies.• GenAI: Leverages Al to automatically generate compliant on its first drafts of contracts, eliminating the overhead of multiple templates.

[0121] Contract Lifecycle: Negotiation• Traditional: Determining what's been signed previously is a manual and tedious process due to a fragmented history of contracts and generally a fragmented set of lawyers performing the negotiations.• GenAI: Provides on-demand summaries of past negotiations, enabling better decisionmaking and leveraging a collective knowledge unattainable by a human contract group.

[0122] Contract Lifecycle: Storage & Analytics• Traditional: Contracts are often dispersed across different storage systems, leading to data fragmentation and difficulty in accessing required contracts.• GenAI: Enables a comprehensive approach to a contract data lake, with automated organization and extraction of key contract data, simplifying storage and retrieval processes.

[0123] Contract Lifecycle: Compliance & Obligation Management• Traditional: After signing a contract, compliance events are manually tracked, leading to missed obligations and potential penalties.• GenAI: Continually scans past contracts for specific commitments requiring future action, ensuring no compliance event is overlooked.

[0124] Contract Lifecycle: Renewal & Termination• Traditional: Renewal drafts are created manually from scratch, leading to inefficiencies. Termination processes lack systematic reminders, resulting in missed opportunities to exit contracts.• GenAI: Facilitates the automated creation of renewal drafts based on relationship history and trends. For terminations, it proactively notifies stakeholders and auto-generates termination notices, streamlining the process.

[0125] In conclusion, while traditional contract management practices are often manual and fragmented, GenAI contract management and curation offers a more streamlined, automated,and insightful approach, leveraging the power of Al to address the challenges and inefficiencies of the traditional method.ADDITIONAL CONSIDERATIONS

[0126] While the preceding description outlines various solution variants in detail, it's important to recognize that the legal scope of the invention is ultimately defined by the claims listed at the end of this patent. The detailed description serves as an illustrative example, and it is not exhaustive of all potential solution variants. Due to the impracticality of describing every conceivable solution variant, alternate configurations may exist — whether using current technologies or those developed after this patent’s filing — that still fall within the scope of the claims.

[0127] Throughout this specification, references to singular instances may also include plural instances, and vice versa. Likewise, while operations of methods are described separately, they can be performed concurrently or in a different sequence than presented. Components or functionalities described as separate in example configurations may be combined, while those presented as a single entity may be divided into multiple components. These and other modifications or improvements remain within the bounds of the described invention.

[0128] In certain solution variants, logic, routines, subroutines, applications, or instructions may be executed via software (e.g., code on a non-transitory, machine-readable medium) or hardware (e.g., special-purpose processors). In a hardware context, these routines can be physical, tangible units configured in specific ways, such as through a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). Alternatively, they may leverage general-purpose processors configured temporarily via software to execute specific operations. Decisions on whether to implement routines in dedicated hardware, software, or hybrid solutions may depend on cost, complexity, or other constraints.

[0129] For purposes of clarity, "hardware module" should be understood to mean a tangible entity that can either be physically constructed or configured (permanently or temporarily) to operate in a specific manner. If temporarily configured via software, a general-purpose processor may act as various hardware modules at different times. This flexibility enables the same processor to perform multiple functions dynamically, depending on the system’s current needs.

[0130] Inter-module communication between hardware modules may occur through signal transmission over circuits or buses. When modules are instantiated at different times, data can be stored and retrieved from shared memory structures, enabling asynchronous operation. For instance, a hardware module may execute an operation and store its results in memory, allowing another module to access and process the stored information later.

[0131] The operations of methods described in various solution variants may be partially or fully implemented by one or more processors. These processors may be physically located within a single machine or distributed across multiple systems, enabling distributed processing. In some cases, these systems may be in a centralized location, like a data center, while in other cases, they could be spread across multiple geographic locations. When processors are distributed, they may communicate and coordinate their tasks via networked infrastructure, forming a cohesive processing system.

[0132] Terminology used herein, such as "processing," "computing," or "calculating," refers to the manipulation of data in physical forms, such as electrical, magnetic, or optical quantities. When the specification refers to "one solution variant" or "a solution variant," it indicates that the described feature may be applicable to at least one possible solution variant. This should not imply that all instances of the phrase refer to the same solution variant.

[0133] Additionally, terms like "comprises," "including," and their variants are intended to imply non-exclusive inclusion. For instance, a method that "comprises" certain elements is not limited to those elements alone and may include other components not explicitly listed.Similarly, "or" should be interpreted as inclusive unless otherwise specified, meaning A or B could be true individually or simultaneously.

[0134] The descriptions provided are intended as illustrative, non-exhaustive examples. They do not define every possible solution variant, as doing so would be impractical, if not impossible. Moreover, technological advancements and alternate configurations may arise that still fall within the invention’s defined scope.

Claims

CLAIMSWhat is claimed is:

1. A system for classification of contracts and their associated contract documents, the system comprising: a computing device configured to: receive a contract document comprising a plurality of contractual elements; segment the first contract document into a plurality of contextual chunks based on semantic boundaries, wherein each chunk maintains coherent contextual meaning; maintain a marshalling queue to process the plurality of contextual chunks sequentially; store, for the each contextual chunk: processed data within a defined context window size, cross-references to the other chunks, and a running context buffer of key contract elements; repeat the receiving of each of the contract documents until all of a contract’ s associated contract documents are chunked and stored. identify a party to the each contract document and a class category of the each contract document based on aggregated party and classification information from a set of processed chunks; determine at least a contract risk parameter using a risk classifier operating on: the plurality of contractual elements, relationships between elements identified across the different processed chunks, and contextual importance weights derived from at least a chunk positions and cross- references; calculate a risk recommendation based on: the at least a contract risk parameter,the identified party, the class category, and an aggregate risk metrics computed across chunk boundaries; rank the contract based on the contract risk parameter, wherein the ranking: incorporates the individual chunk risk levels, incorporates a whole-contract risk assessment, weights risks based on contextual significance determined during marshalling, and accounts for inter-dependencies between the processed chunks; and generate a change recommendation for the contract comprising: an at least one correlation between a contractual element and a level of risk, an identification of high-risk chunks and their contextual relationships, and at least a suggested modifications that consider cross-chunk impacts; wherein the computing device processes the contract using context window marshalling to handle the contract sizes exceeding single context window limitations while maintaining semantic coherence and relationship preservation across the contract and the associated contract documents.

2. The system of claim 1, wherein the computing device is further configured to: establish a hierarchical relationship between a Master Services Agreement (MSA) and it’s an associated contract document by: identification of a parent-child relationships between the MSA and a subordinate Statement of Work (SOW)s and it’s an addendums; a cross mapped references between the MSA's contextual processed chunks and related provisions in a dependent document; maintenance of a unified context buffer that preserves the hierarchical structure of related contractual elements across all associated documents; andpropagated risk assessments upward through the document hierarchy to inform a risk profile.

3. The system of claim 2, wherein the computing device processes the Statements of Work by:Segmentation of a set of deliverables, timelines, and acceptance criteria into a set of discrete contextual chunks;Establish at least a bidirectional link between a SOW chunk and a corresponding governing MSA provisions;Generation of a risk recommendations that account for both SOW-specific risks and inherited MSA constraints.

4. The system of claim 3, wherein the computing device processes a contract addendum by: identification of a specific chunk of the MSA or SOW being modified; creation of a contextual chunk that maintain semantic alignment with an aligned original document section; update the cross mapped references to reflect any changes; and recalculating a risk parameter to account for the cumulative impact of modifications across all related documents.

5. The system of claim 4, wherein the computing device maintains a document version control by: tracking a chronological sequence of addendums and modifications; maintaining a separate marshalling queues for the each document version; preserving a historical context buffer for the each document version while updating the contract’s active context; andgenerating a comparative risk assessment between the document versions to highlight a risk profile change.

6. An apparatus for classification of contracts and their associated contract documents, comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the apparatus to provide: a document receiving module configured to receive a contract document comprising a plurality of contractual elements; a segmentation module configured to segment the contract document into a plurality of contextual chunks based on semantic boundaries, wherein each chunk maintains coherent contextual meaning; a marshalling module configured to maintain a marshalling queue to process the plurality of contextual chunks sequentially; storage module configured to store, for the each contextual chunk: processed data within a defined context window size, cross-references to the other chunks, and a running context buffer of key contract elements; a document processing module configured to process each of the contract documents until all of a contract's associated contract documents are chunked and stored; a party identification module configured to identify a party to each contract document and a class category of each contract document based on aggregated party and classification information from the processed chunks; a risk assessment module configured to:determine at least a contract risk parameter using a risk classifier operating on: the plurality of contractual elements, relationships between elements identified across different chunks, and contextual importance weights derived from chunk positions and cross-references; calculate a risk recommendation based on: the at least a contract risk parameter, an identified party, the class category, and aggregate risk metrics computed across chunk boundaries; a ranking module configured to rank the contract based on the contract risk parameter, wherein the ranking: incorporates an individual chunk risk level, incorporates a whole-contract risk assessment, weights risks based on contextual significance determined during marshalling, and accounts for inter-dependencies between chunks; and a recommendation module configured to generate a change recommendation for the contract comprising: at least one correlation between a contractual element and a level of risk, identification of at least a high-risk chunk and their contextual relationships, and suggested modifications that consider cross-chunk impacts; wherein the apparatus processes the contract using context window marshalling to ingest the contract that comprises sizes exceeding single context window limitations whilemaintaining semantic coherence and relationship preservation across the contract and the associated contract documents.

7. The apparatus of claim 1, further comprising: a hierarchy management module configured to establish a hierarchical relationship between a Master Services Agreement (MSA) and its associated contract documents, the hierarchy management module comprising: a relationship identifier configured to identify parent-child relationships between the MSA and subordinate Statement of Work (SOW)s and addendums; a reference mapper configured to cross map references between the MSA's contextual chunks and related provisions in dependent documents; a context buffer manager configured to maintain a unified context buffer that preserves the hierarchical structure of related contractual elements across all associated documents; and a risk propagation module configured to propagate risk assessments upward through the document hierarchy to inform the master agreement's risk profile.

8. The apparatus of claim 7, further comprising: a SOW processing module configured to: segment a set of deliverables, timelines, and acceptance criteria into discrete contextual chunks; establish at least a bidirectional link between SOW chunks and their governing MSA provisions; and generate risk recommendations that account for both SOW-specific risks and inherited MSA constraints.

9. The apparatus of claim 8, further comprising:an addendum processing module configured to: identify the specific chunks of the MSA or SOW being modified; create contextual chunks that maintain semantic alignment with the aligned original document sections; update the cross mapped references to reflect any changes; and recalculate risk parameters to account for the cumulative impact of modifications across all related documents.

10. The apparatus of claim 9., further comprising: a version control module configured to: track a chronological sequence of addendums and modifications; maintain a separate marshalling queues for each document version; preserve a historical context buffer for each version while updating the active context; and generate a comparative risk assessment between document versions to highlight risk profile changes.

11. A method for classification of contracts and their associated contract documents, comprising: receiving, by a processor, a contract document comprising a plurality of contractual elements; segmenting the contract document into a plurality of contextual chunks based on semantic boundaries, wherein each chunk maintains coherent contextual meaning; maintaining a marshalling queue to process the plurality of contextual chunks sequentially;storing, for each contextual chunk: processed data within a defined context window size, cross-references to other chunks, and a running context buffer of key contract elements; processing each of the contract documents until all of a contract's associated contract documents are chunked and stored; identifying a party to each contract document and a class category of each contract document based on aggregated party and classification information from the processed chunks; determining at least a contract risk parameter using a risk classifier operating on the plurality of contractual elements, relationships between elements identified across different chunks, and contextual importance weights derived from chunk positions and cross-references; calculating a risk recommendation based on the at least a contract risk parameter, the identified party, the class category, and aggregate risk metrics computed across chunk boundaries; ranking the contract based on the contract risk parameter, wherein a ranking incorporates individual chunk risk levels, incorporates whole-contract risk assessment, weights risks based on contextual significance determined during marshalling, and accounts for intcr-dcpcndcncics between chunks; generating a change recommendation for the contract comprising: at least one correlation between a contractual element and a level of risk, identification of high- risk chunks and their contextual relationships, and suggested modifications that consider cross-chunk impacts; and wherein the method processes the contract using context window marshalling to manage contract sizes exceeding single context window limitations while maintaining semantic coherence and relationship preservation across the contract and the associated contract documents.

12. The method of claim 11, further comprising: establishing a hierarchical relationship between a Master Services Agreement (MSA) and its associated contract documents by identifying parent-child relationships between the MSA and subordinate Statement of Work (SOW)s and addendums, cross mapping references between the MSA's contextual chunks and related provisions in dependent documents, maintaining a unified context buffer that preserves the hierarchical structure of related contractual elements across all associated documents, and propagating risk assessments upward through the document hierarchy to inform the master agreement's risk profile.

13. The method of claim 12, further comprising: processing SOWs by segmenting a set of deliverables, timelines, and acceptance criteria into discrete contextual chunks, establishing at least a bidirectional link between SOW chunks and their governing MSA provisions, and generating risk recommendations that account for both SOW-specific risks and inherited MSA constraints.

14. The method of claim 3, further comprising: processing addendums by identifying the specific chunks of the MSA or SOW being modified, creating contextual chunks that maintain semantic alignment with the original document sections, updating the cross mapped references to reflect any changes, and recalculating risk parameters to account for the cumulative impact of modifications across all related documents.

15. The method of claim 14, further comprising: controlling versions by tracking a chronological sequence of addendums and modifications, maintaining separate marshalling queues for each document version, preserving a historical context buffer for each version while updating the active context, and generating a comparative risk assessment between document versions to highlight risk profile changes.

Images