Aerofiler Brings Breakthrough Automation to the Legal Profession

Steve Jurczak
May 17, 2023 | Updated: May 25, 2023
#Startups

Don Nguyen is the perfect person to solve a technology problem in the legal space. Don spent several years in software engineering before eventually becoming a lawyer, where he discovered just how much manual, administrative work legal professionals have to do. The company he co-founded, Aerofiler, takes the different parts of the contract lifecycle and digitises them to eliminate manual work, allowing lawyers to focus on things that require their expertise.

Don says the legal profession has always been behind industries like accounting, marketing, and finance when it comes to leveraging technology to increase productivity. Both Don and his co-founder, Stuart Loh, thought they could automate a lot of manual tasks for legal professionals through an AI-powered contract lifecycle management solution.

Turning mountains into automation

Law firms generate mountains of paperwork that must be digitised and filed. Searching contracts post-execution can be an arduous task using the legacy systems most firms are running on today. Initially, Don, Stuart, and Jarrod Mirabito (co-founder and CTO) set out to make searching contracts and tracking obligations easier. As the service became more popular, customers started asking for more capabilities, like digitising and automating the approval process. Aerofiler's solution now manages the entire contract lifecycle, from drafting and negotiations to approvals, signing, and filing.

Don says the difficulty with running AI to extract data is you can't usually see where the data is coming from, and you can't train your models, for example, to extract a concept that might be specific to your industry. Aerofiler supports custom extraction so firms can crawl for and find exactly the results they're looking for, and it highlights exactly where in the contract the data is found.

Aerofiler is unique as a modern, cloud-based Contract Lifecycle Management solution that streamlines contract management processes and enhances workflow efficiency. It features AI-powered analytics, smart templates, and real-time collaboration tools, and is highly configurable to fit the unique needs of different companies. Aerofiler's user interface is also highly intuitive and user-friendly, leading to greater user adoption and overall efficiency.

The startup stack

Don has over 10 years of experience working with MongoDB and describes it as very robust. When it was time to choose a database for their startup, MongoDB Atlas was an easy choice. One of the big reasons Don chose Atlas is so they don't have to manage their own infrastructure. Atlas provides the functionality for text search, storage, and metadata retrieval, making it easy to hit the ground running. On top of MongoDB, the system runs Express.js, VueJS, and Node.js, also known as a MEVN stack.

In choosing a database, Don points out that every assumption you make will have exceptions to it, and no matter what your requirements are now, they will inevitably change. So one of the key factors in making a decision is how that database will handle those changes when they come. In his experience, NoSQL databases like MongoDB are easy to deploy and maintain. And, with MongoDB offering ACID transactions, they get a lot of the functionality that they would otherwise look for in a relational database stack.

How startups grow up

Aerofiler is part of the MongoDB for Startups program, which helps early-stage, high-growth startups build faster and scale further. MongoDB for Startups offers access to a wide range of resources, including free credits to our best-in-class developer data platform, MongoDB Atlas, personalized technical advice, co-marketing opportunities, and access to our robust developer community. Don says the free credits helped the startup at a time when resources were tight.

The key to their success, Don says, is in solving problems their customers have. In terms of the road ahead, Don is excited about ChatGPT and says there are some very interesting applications for generative AI in the legal space. If anyone would like to talk about what generative AI is and how it could work in the legal space, he's happy to take those calls and emails.

Are you part of a startup and interested in joining the MongoDB for Startups program? Apply now.

← Previous

MongoDB Goes (Leafy) Green: Our Net Zero Commitment

At MongoDB, we have a deep commitment to sustainability and taking ownership of our environmental impact. In 2021, we internally announced our pledge to have net zero emissions (CO 2 e) by 2030, and have since benchmarked our emissions and have worked on developing a strategy to achieve this goal. Through this process, we discovered that over our last fiscal year we produced the same amount of carbon as driving a gas-powered vehicle around the globe more than 6,000 times. This amount may seem high because we calculated not only our Scope 1 (direct; e.g., offices) and Scope 2 (indirect; e.g., purchased electricity) emissions as is standard under current reporting requirements, but also our Scope 3 emissions (indirect; e.g., supply/value chain). These Scope 3 emissions account for ~97.5% of our total footprint. We have chosen to disclose this full amount because we are committed to reducing our entire carbon footprint as much as possible and want to be transparent on this journey. While 2030 may seem far away, we are committed to reducing emissions and already have taken immediate action. Last year, we invested in hiring a Sustainability Manager to help us tackle how we are going to achieve our goals and engage teams across the company to develop carbon reduction strategies. This included adding an interim target to be 100% powered by renewables by 2026. We can’t do this alone. A large part of our indirect emissions is from our cloud partners, so we have partnered with them to see what we can achieve for our customers together. In addition to reducing our direct footprint, we are also focused on cleaner energy sources. By 2025 our major partners—AWS, Google Cloud (GCP), and Microsoft Azure—will be 100% powered by renewables. Following their example, we have entered into our first virtual power purchase agreement to support the construction of a new 10MW solar plant in Texas and add renewable energy to the grid. This is unique for a company our size and is evidence of our commitment to sustainability. By reducing our emissions, we can help our customers reduce their own carbon impact through MongoDB and the cloud. Enabling our customers to make greener choices We have heard from our customers that sustainability is important to them and influences their purchasing decisions. We looked at our own technology and have re-engineered MongoDB Atlas to reduce power consumption by ~30%. While moving to the cloud can have a positive impact on reducing carbon emissions, the actual amount depends on various factors, including the cloud provider, the type and amount of workloads, and the location of data centers. That's why we've introduced a new level of transparency to help our customers make more sustainable choices, including our Green Leaf icon in MongoDB Atlas that highlights low-carbon AWS and GCP cloud regions and encourages customers to consider the carbon impact of their choices. Additionally, MongoDB Atlas Serverless takes this one step further. Serverless infrastructure can help customers reduce their carbon footprint by reducing their infrastructure overhead and only using computing resources only when needed rather than constantly running. This means less energy is consumed overall, and less waste is created. Additionally, with MongoDB Atlas Serverless, customers can quickly scale up or down in response to changing demand, ensuring they're not wasting resources on idle infrastructure. To drive awareness and use of our products’ sustainability features, we have released a quick reference blog and detailed white paper on sustainable architecture. Finally, to help our customers understand how these changes impact their footprint, MongoDB will now include a note on attributable carbon emissions on our customers’ invoices. Changes in our offices, operations, and beyond We are making actionable changes to gain momentum towards our larger net-zero goal within our offices. We are switching over 100% of the lights in our offices to LEDs, have eliminated many single-use items, and are reducing power consumption by regulating usage outside of peak hours– this is as simple as putting Zoom Screens on timers. Additionally, we have introduced a Supplier Code of Conduct to ensure ESG compliance throughout our value chain. Finally, we have partnered with our Green Team ERG to enable employee engagement in our sustainability goals. Our Green Team fosters employee engagement by organizing community building and educational events centered around environmentalism and act as a voice for our employees' drive for corporate sustainability. As of this year employees can donate towards a project selected by our Green Team leads focused on reforestation through points earned in our employee recognition tool. We are just getting started, and our commitment to you is to be as transparent as possible throughout this process. We encourage you to follow our progress on our Sustainability webpage and check out our latest CSR report , which dives deeper into our emissions benchmark. At MongoDB, we believe that sustainability is everyone's responsibility, and we are committed to doing our part to create a more sustainable future.

May 17, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024