Armakuni Contact us
← All case studies

A new law firm arrived with 400 pages.
Someone had to read every one before it went live.

A Canadian legal SaaS company onboards law firms onto its corporate-records platform, and every new customer brought a document bundle that staff read, classified and indexed by hand. In a five-to-six-week proof of value, we built a pipeline that splits a bundle into chunks, reads them in parallel, pulls out the fields each document type needs and makes them searchable, with a reviewer checking every record against the source. AWS proof-of-concept funding covered the cost.

Before

Onboarding a new firm was the slow part.

Operators classified the same document differently.

After
Parallelreading of every bundle, so throughput is no longer capped by headcount
  • One consistent way to classify and extract each document type.

Onboarding a new firm was the slow part

The company helps law firms manage corporate records: entity management, document workflows, e-signature and compliance tracking. Its value is fast access to those records.

Before a new customer could use it, staff had to read the incoming documents, identify each one's type, extract the fields that type needs and build the searchable record. A single onboarding package could run to 300–400 pages across many document types. The cost of onboarding grew with the number of pages, and the turnaround delayed the customer's start at exactly the moment first impressions are made.

Operators classified the same document differently

Document type decides which fields the platform needs, but classification and indexing varied from one operator to the next. Across thousands of documents, those small differences made the output unreliable as structured data, and nothing was searchable until the manual work was finished.

Split each bundle into chunks and read them in parallel

The bundle didn't need to be read one page after another. Split it into small chunks and read them at the same time, and the time to process a bundle depends on its longest chunk rather than its total length. Then one pipeline can do the reading, the classifying and the indexing, the same way for every document.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Five-to-ten-page chunks, read in parallel
  2. A reviewer sees the record beside the page it came from
  3. Containers, private subnets and logs the team can run

Five-to-ten-page chunks, read in parallel

Built withS3TextractBedrock
400 pages 5–10 pages eachRecords
The engineering

The application starts processing the moment a file lands in S3, with no manual step to kick it off. Instead of treating a large package as one long task, it divides the content into five-to-ten-page chunks for parallel processing:

  • Textract runs OCR on each chunk.
  • Where OCR confidence is low, the chunk is routed to a multimodal model on Bedrock, which reads the page visually.
  • LLM extraction identifies sections, classifies the document type and extracts the fields relevant to that type.
  • The pipeline generates metadata alongside each extracted record, so it's indexed consistently.

The proof of value included an evaluation of several models through Bedrock on the legal extraction task, and the best performer was chosen on the results.

Why: low-confidence OCR is where a scanned signature page or a stamp hides a field, so only those chunks go to the vision model, and the bill stays with the pages that need it.

A reviewer sees the record beside the page it came from

Built withStreamlitOpenSearch
The record extractedShown beside its pageA reviewer checks it
The engineering

In a legal product, every extracted record has to be checkable. Extracted data goes into structured storage and appears in a Streamlit interface beside the original document, so reviewers can check each generated record against its source before the customer commits to the wider build.

OpenSearch indexes each processed document with its metadata. Indexing runs with extraction, so there's no separate manual step, and a document is searchable as soon as it's processed.

Containers, private subnets and logs the team can run

Built withFastAPIECSFargateSecrets ManagerCloudWatchCloudTrail
Our teamTheir team TerraformThe application code
The engineering

A FastAPI backend runs in ECS/Fargate containers that scale with processing volume, behind a load balancer in private subnets across two Availability Zones, with Secrets Manager, CloudWatch and CloudTrail for credentials and operational visibility. Terraform and the full application code were delivered to the customer, so it can reproduce and extend the environment without us.

What we'd tell another CTO

1Split long documents and read the chunks in parallel, because the longest chunk sets the time, not the page count. Then send only the hard pages to the expensive model, with low-confidence OCR as the trigger.
2Classify each document before extracting from it, since the type decides which fields matter, and show every extraction beside its source page. In a legal product the reviewer has to trust what they approve.
3We handed over the code and the infrastructure at the end. A customer who can rebuild the pipeline can rely on it.

What else changed

  • A working prototype tested on 100 representative legal documents, including shareholder agreements and articles of incorporation, covering the whole sequence from ingestion to indexing, with comparison against the source.
  • Parallel processing, so throughput is no longer capped by headcount, and the cost of onboarding no longer grows with each page read by hand.
  • A production roadmap covering integration into the existing onboarding platform, security hardening and broader document coverage.
  • The code and Terraform, owned by the customer.
  • The $13,800 engagement was covered by AWS proof-of-concept funding, subject to approval, so the customer's cost was $0.

What comes next

Production deployment, integrated into the company's onboarding platform, with production-grade security hardening, a multi-region architecture and more document types.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

With Guaranteed AI Outcomes the pipeline would be signed against a number the business already tracks, such as days from contract to a searchable platform or staff hours per onboarding, with our engineers inside the business until it's live in 90 days or less, a go-or-stop call at week 4 and payment on the result after it.

On AK AI Factory, the reviewers' corrections would become the test: every record a reviewer fixed is a case each prompt or model change has to pass, alongside a sealed set nobody tunes to, and a wrong document type fails the change outright. The company's legal experts would sign off which fields each document type must contain, a shareholder agreement or articles of incorporation, and because a document can carry text written to steer an AI agent, everything the AI agents read would be treated as untrusted. At volume, AI Inference Engineering would send the routine pages to a model the company owns on Amazon SageMaker AI, at about a tenth of the price, and keep the hard ones on a frontier model through Amazon Bedrock.

Modernize with AI Guaranteed AI Outcomes AI Inference Engineering

More work like this

  1. AIPlain EnglishA U.S. concussion-management platformquestions answered across both clinical modules, in the proof of valueA return-to-play decision shouldn't wait for someone who knows SQL.$1,300 net cost to the customer4–5 weeks to the proof of valueOn AWS S3 · Bedrock · Fargate · RDS
  2. AIHoursA visitor-management software companysaved per workflow, in the company's own testingThe editor could do anything. Customers left because they couldn't use it.10+ node types in the production editor6 acquired products, one visitor identity, provedOn AWS Bedrock · DynamoDB · RDS · Cognito
  3. AIFirstA U.S. drug testing networklabeled sensor dataset for this kind of testing, and a working prototypeCameras weren't allowed in the room. So we built a way to sense cheating without seeing anyone.24,000+ tests a day the pipeline is sized for120 testing centersOn AWS S3 · Lambda · DynamoDB · API Gateway

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop