Armakuni Contact us
← All case studies

Every insurance form is also a set of instructions.
We taught the product to read them.

A North American insurance software provider had people reading the logic out of PDF forms and rebuilding it by hand, a configuration tool only specialists could use, and a 25-year-old VB6 and Citrix platform holding 1,200 customer databases that had to stay in Canada. Across six pieces of work on three product lines in seven months, we built a two-pass Nova Pro pipeline that turns PDFs into the product's form schema, tested configuration by plain-English request, and planned and began the platform's move to AWS, funded by AWS.

Before

The form held the logic, and people retyped it.

The oldest platform had nowhere to go.

After
In productiona pipeline that turns PDF forms into the product's schema, where a person rebuilt it
  • Email and spreadsheet intake mapped to the same schema, with confidence-scored fields to review.

The form held the logic, and people retyped it

An insurance form is more than fields. It says which fields to collect, how answers are grouped and which questions depend on an earlier answer. The provider's teams read that logic from PDFs, and from emails and spreadsheets, and rebuilt it in the application by hand.

Even once a form was configured, a small change, such as a new underwriting field or a rule that hides a tab, needed someone who understood the schema. The product's flexibility depended on a small group of specialists.

And the oldest platform had nowhere to go

In Canada, the broker-management platform ran on 25-year-old Visual Basic 6 code delivered through Citrix, with 1,200 customer databases holding about 75 TB, plus 12 TB of documents. Canadian law required every record, backup and replica to stay in Canada. Citrix, VMware, SQL Server and the disaster-recovery setup were tangled together, so none could move alone, and earlier attempts to modernize had stalled against the same wall. One earlier plan, a straight .NET migration, would have spent the whole budget to reach 60 to 70 percent of the work, with no architectural improvement at the end of it.

Read the instructions, then the platform

The forms and the platform needed the same approach. For the forms, the system had to read the instructions as well as the fields and land the result in the product's own schema. For the platform, VB6, Citrix, the databases, residency and recovery had to be handled together, as one coordinated problem.

How we built it

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

  1. Test the models on the provider's own forms
  2. Two passes, because they're two different jobs
  3. Email and spreadsheets into the same schema
  4. A configuration change you see before it happens
  5. The VB6 and Citrix platform, moved as one problem
  6. Predicting failed agent authorizations

Test the models on the provider's own forms

Built withBedrock
The provider's own forms Candidate modelCandidate modelChosen model
The engineering

Before building anything, a three-to-four-week assessment benchmarked Amazon Bedrock models against the customer's actual forms, measuring extraction accuracy, cost and latency against defined targets, with workshops to settle the special cases: checkboxes, free text and nested tables. It produced a model recommendation, an implementation roadmap and a business case built on hours saved per form and fewer data-entry errors.

Two passes, because they're two different jobs

Built withNova ProS3SQSCloudWatchDjango
Pass 1: pick out the fieldsClean and structurePass 2: rules into JSON
The engineering

The implementation uses Nova Pro in two sequential inference passes, because pulling out a field and working out how fields relate are different tasks:

  • A PDF upload lands in S3 and creates an SQS message, and background workers process the document while the user keeps working.
  • Preprocessing converts the PDF into model-ready content, as markdown. The first pass extracts field attributes: labels, types, options and one-level nested tables.
  • A static schema normalization layer, in Python, cleans and structures that output before the second pass, which cuts tokens and keeps output consistent.
  • The second pass resolves grouping and dependency logic into JSON conforming to the application's form schema.
  • Workers update processing status and retry failed fetches or model calls, the interface shows progress and retrieves the finished JSON from S3, and CloudWatch and tracing cover the asynchronous flow.

The pipeline is integrated with the existing Django REST backend, so users submit a form and get its configuration in the application they already use. This moved from proof of concept to production over 10 to 12 weeks.

Why: one model call doing both jobs fails at both, and normalizing between the passes keeps the second pass short and predictable.

Email and spreadsheets into the same schema

Built withTextract
PDF formsEmailSpreadsheets One schema
The engineering

A related proof of concept extended intake to email text, spreadsheets and other documents. The extraction path varies with the input, and the required output stays the same:

  • File-type validation picks the right parser, with Textract available for OCR.
  • Entity extraction and schema mapping resolve values into the required numeric, Boolean and string types.
  • Users check confidence-scored fields, correct them and revalidate the JSON before export.

A configuration change you see before it happens

Asked in plain wordsThe AI agent shows a previewThe user confirmsRollback if wrong
The engineering

We built a configuration AI agent as a six-week proof of concept (POC) against the real schema library. It covered common requests such as "Add a dropdown for Underwriter" or "Hide the Property tab when Property Insurance isn't selected":

  • An unclear instruction prompts a follow-up question.
  • The AI agent generates a schema change and shows a preview.
  • The user confirms before the change is applied.
  • Rollback restores the previous update if the result is wrong.

The proof of concept tested whether the AI agent understood the product's configuration vocabulary and could produce usable changes. Authentication, production access controls and more complex cross-field dependencies are part of the next integration phase. Nothing an AI agent writes reaches a customer's configuration without a person seeing it first.

The VB6 and Citrix platform, moved as one problem

Built withEC2RDSDMS
underwayVB6 and CitrixAWS The application1,200 databasesAbout 75 TB moved as one problem
The engineering

A two-to-three-week assessment, under the AWS Migration Acceleration Program (MAP), mapped dependencies across 1,200 customer databases and about 75 TB: the VB6 application delivery, Citrix, the multi-instance SQL Server architecture, file servers and the integration services. Canadian residency was a constraint on every decision. It also changed the question leadership was asking, from how to migrate VB6 to how to rebuild on a modern platform, and set a roadmap ordered by business value.

The 12-to-14-week mobilize phase coordinates the parts that have to move together:

  • AWS-hosted application delivery replaces the existing hosting pattern: EC2 Auto Scaling groups, Application Load Balancers and containerized deployments in Canadian AWS regions in place of Citrix and VMware.
  • RDS and DMS replication move the customer databases, each keeping its customer isolation and recovery targets.
  • AWS-native backup and recovery replaces the legacy disaster-recovery arrangement.
  • The sequencing accounts for application delivery, SQL Server dependencies, integrations and recovery.

The migration is underway. Its scope and status are separate from the form-processing build and the configuration proof of concept.

Predicting failed agent authorizations

assessedPast authorizationsFailure patternsLikely to fail Team
The engineering

A further three-to-four-week assessment, for the provider's agent-licensing product, looked at historical agent-authorization failures across millions of requests. It checked data readiness across background checks, agent profiles, regulatory data and failure codes, compared supervised learning, clustering and anomaly detection, and covered explainability and integration requirements. It produced a recommendation for building the predictive model next.

One form, end to end

  1. A user uploads an insurance PDF in the application.
  2. S3 stores it and SQS queues it, so the user carries on working.
  3. The PDF becomes markdown, and Nova Pro's first pass pulls out every field, its type, its options and its nested table.
  4. The normalization layer cleans that output, so the second pass gets a consistent, compact input.
  5. Nova Pro's second pass works out groups and dependencies, such as "show question 14 only if 13 is yes", as JSON in the product's form schema.
  6. The finished JSON comes back to the form builder, ready to use, with no separate AI tool.

What we'd tell another CTO

1Read the logic in a form as well as its fields, because the dependencies are the configuration nobody wrote down. Then split extraction from reasoning: two passes with normalization between them were cheaper and more consistent than one call doing both.
2Land the output in your own schema and your own application, so it's usable the day it's generated, and give non-specialists preview, confirmation and rollback, which is what makes AI configuration safe for them.
3A tangled legacy stack moves as one problem. Citrix, the databases, residency and recovery had to be planned together, which is where the earlier attempts had stalled.

What else changed

  • A configuration AI agent, proved on the real schema library, with preview, confirmation and rollback.
  • A migration strategy for the VB6 and Citrix platform, and its mobilize phase underway in Canadian regions.
  • A recommended model approach for predicting agent-authorization failures.
  • AWS funding of $150,000 for the migration ($54,000 for the assessment, $96,000 for mobilization) and $80,000 for the two AI assessments, so the provider paid nothing for those.

What comes next

Completing the mobilize phase and moving the platform toward a web-based architecture, production integration of the configuration AI agent with authentication and access controls, and building the authorization-failure prediction.

How we'd do it today

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

The VB6 platform would go through AK Evolve, because rewrites die at the cutover, when the new system meets the rules nobody wrote down. AI agents would read the old code into specs, characterization tests would pin what it does today, right or wrong, and AI agents and AWS Transform would rebuild one system at a time against those tests behind a routing layer, so each slice goes live on its own and can go back. A person would merge every change, and MAP would fund part of the work where workloads qualify.

For the form work, every form the team configured by hand would become a golden-set case that each prompt or model change must reproduce, with a sealed set beside it and a lost dependency treated as a critical case. The configuration AI agent would get its own identity and only the tools its job needs, with its rules as Cedar policies checked outside the model on every call, so it can propose a schema change and can't apply one without a person's confirmation.

Modernize with AI AK AI Factory

More work like this

  1. Modernization99.9%A global white-label auction platformuptime at thousands of bids a minute, as reportedA ten-minute change took days to ship, because it had to reach 400 auction houses by hand.100+ deployments a week30% faster auction-house onboardingOn AWS S3 · ECS · Fargate · RDS
  2. Modernization0A U.S. clinical analytics providermissed pipeline runs while production moved, as reportedHospitals expected their data every week. The platform underneath it belonged to other people.8 weeks to AWS, MAP-funded25 ECS clusters moved between accountsOn AWS ECS · EC2 · RDS · CloudTrail
  3. Modernization8–10 weeksA North American home-inspection companymigration plan, signed off by the CTOIts platform lived in someone else's AWS account. Then the landlord gave notice.2 weeks to a working pod, 2 days to sign~600 GB of PostgreSQLOn AWS EC2 · S3 · WAF · ECS

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