Building RateGuard AI: An Agentic Guardrail Against Silent Insurance Pricing Errors

Hackathon disclosure: I created this piece of content for the purposes of entering the All Things Agentic Hackathon.

Built by the RateGuard team

RateGuard AI was designed and built collaboratively by:

• Charan Panja — Project lead, product vision, architecture, and implementation
• Ashwini Tekula — Insurance-domain expertise, backend test design, worker architecture, documentation, project planning and governance

This article is published by Ashwini Tekula on behalf of the RateGuard team.

Imagine an insurance company preparing a new homeowners pricing release. The actuaries have approved what customers should be charged, but that pricing logic still has to be recreated inside another rating system.

A small implementation error may not crash the software. It can quietly calculate the wrong premium and repeat that mistake across thousands of policies.

For example:

Approved pricing intent: roof_age >= 21 -> factor 1.35
Target implementation:   roof_age >= 21 -> factor 1.25

Both versions are valid code. Ordinary smoke tests may pass. The defect becomes visible only when the right policy reaches the affected boundary - potentially after the release is already serving customers.

I built RateGuard AI to turn that uncertainty into evidence before deployment. RateGuard is a vendor-neutral, agentic pricing-assurance system that compares pricing sources, generates targeted tests, independently recalculates premiums, measures portfolio impact, proposes remediation, and returns a conservative release decision.

The product idea is simple:

Put an autonomous assurance mission between approved pricing intent and production deployment.

Instead of asking a reviewer to manually inspect hundreds of factors and hope the regression suite covers the right combinations, a team launches one mission. RateGuard follows the change from semantic difference to premium behavior to portfolio exposure, then returns the evidence needed to pass, review, or block the release.

• Live application: RateGuard AI
• Source code: RateGuard on GitHub

A RateGuard mission begins by selecting the assurance workflow and pricing sources.

Why this product could matter to an insurance organization

Rate changes involve several teams. Actuaries define the pricing intent, implementation teams configure the target platform, QA teams design regression tests, and release or compliance teams decide whether the change is safe to deploy. Each handoff creates an opportunity for meaning to drift.

RateGuard is designed to become a shared evidence layer across those handoffs.

Reduce release risk

A silent rating defect can affect premiums without producing a software exception. The risk is therefore not just system availability; it includes incorrect customer charges, inconsistent treatment of similar risks, remediation work, customer trust, and regulatory scrutiny.

RateGuard reduces this risk by checking both structure and behavior. It does not conclude that a release is safe merely because two source files look similar. It compiles them, compares their pricing semantics, tests the affected boundaries, reconciles calculation traces, and applies conservative decision gates.

Make the financial consequence visible before deployment

Finding a changed factor is useful, but decision-makers also need to know whether it matters. A difference that affects no in-scope policy is not the same as one that changes premiums across a large portfolio.

RateGuard converts a technical defect into decision-ready impact evidence:

• how many policies match the defect condition;
• how many produce a premium difference;
• the direction and amount of the simulated premium impact;
• overlap between multiple defects; and
• whether remediation returns the measured exposure to zero.

This does not claim that every detected dollar becomes a realized loss. The demonstration uses a synthetic 50,000-policy portfolio. Its purpose is to show how a carrier could connect technical release assurance to portfolio-level financial exposure using its governed internal data.

Reduce repetitive manual effort

Traditional pricing validation can require people to compare tables, identify changed boundaries, build test policies, calculate expected premiums, reproduce the target result, document the first divergence, and assemble evidence for a release meeting.

RateGuard automates that chain as one mission. Humans still own the pricing intent and release authority, but they receive a focused evidence package instead of starting with an open-ended investigation.

The goal is not to remove actuarial, engineering, QA, or compliance judgment. It is to spend that judgment on material findings rather than mechanical comparison and evidence assembly.

How RateGuard could be used

RateGuard is designed for several points in a pricing lifecycle:

• Before a rate-book deployment: compare approved pricing intent with the target implementation and block material drift.
• During a rating-platform migration: compare legacy and replacement implementations neutrally without assuming either is automatically correct.
• After a vendor configuration change: identify whether a seemingly small table or rule change affects downstream premiums.
• Inside CI/CD: launch an assurance mission as a release gate and attach its evidence to the change record.
• During incident investigation: reproduce the first divergent calculation node and test a proposed correction against targeted and regression scenarios.
• For audit and release review: preserve semantic differences, model decisions, test evidence, reconciliation traces, and portfolio analysis in one lineage.

In a production operating model, RateGuard would sit beside the rating platform rather than replace it. The rating engine continues to calculate customer quotes. RateGuard independently verifies that the implementation still represents the intended pricing logic.

The design question that shaped the project

The hardest question was not, "How can I add an LLM to insurance rating?" It was:

Where should an agent be allowed to reason, and where must the system remain deterministic?

Premium calculation is the wrong place for probabilistic arithmetic. A pricing-assurance system must be reproducible and auditable. If it reports that a certain number of policies are affected or that the simulated exposure is a certain amount, those figures cannot come from a language model.

That led to RateGuard's central rule:

Gemini reasons, prioritizes, and explains. Deterministic engines calculate, test, and prove.

Gemini never computes a premium, counts policies, or invents a financial-impact number. Every number shown in the application is produced by deterministic Python or a BigQuery aggregation.

Step 1: Create a common language for pricing

Pricing logic appears in many forms: actuarial specifications, rating-engine configurations, spreadsheets, and platform-specific exports. Comparing those formats directly makes the assurance process dependent on a particular vendor.

I introduced the Insurance Pricing Intermediate Representation (IPIR) as a canonical, executable representation of pricing logic. IPIR models:

• rating inputs and constraints;
• constants such as a base rate;
• factor and rate tables;
• calculation expressions;
• dependency relationships; and
• final premium outputs.

Once two sources compile into IPIR, RateGuard can compare their meaning rather than their original file layout. The same representation also drives the independent premium oracle, dependency analysis, and boundary-test generation.

The live build currently accepts strict structured JSON. Unknown or incorrectly named fields fail schema validation instead of being silently ignored. I intentionally disabled unverified PDF and Excel extraction in production. Supporting fewer inputs honestly was more important than claiming formats I could not verify end to end.

Both pricing sources compile into vendor-neutral IPIR before comparison and testing.

Step 2: Support two different assurance questions

RateGuard has two workflows because not every comparison has the same meaning.

Release Conformance

One source is declared authoritative, such as approved pricing intent, and the other is the target implementation. If RateGuard reproduces a material premium mismatch, it can propose a directional patch and validate the corrected implementation.

Symmetric Equivalence

Neither source is presumed correct. RateGuard reports differences neutrally as Source A and Source B. It does not generate a directional fix until a human explicitly chooses which source should become the reference.

This distinction matters. An automated tool should not silently decide which of two pricing sources represents business intent.

Step 3: Build a deterministic evidence pipeline

Every mission runs a mandatory evidence pipeline:

1. Validate and compile both sources into IPIR.
2. Compare the abstract syntax trees for semantic differences.
3. Trace each difference through the dependency graph.
4. Generate targeted boundary and interaction scenarios.
5. Calculate expected premiums with an independent oracle.
6. Execute the corresponding target calculation.
7. Reconcile both traces and identify the first divergent node.
8. Query the synthetic portfolio to measure the blast radius.
9. Propose and revalidate remediation when the workflow permits it.
10. Produce a release decision: PASS, REVIEW_REQUIRED, or BLOCK_DEPLOYMENT.

The boundary-test generator is especially important. Instead of brute-forcing every possible input combination, it focuses on changed ranges, thresholds, and interacting factors. If a roof-age factor changes at age 21, scenarios around that boundary are much more informative than random policies.

Step 4: Add Gemini only at bounded decision points

The deterministic pipeline creates evidence and candidate actions. Gemini 3.7 Flash, called through Vertex AI using the Google GenAI SDK, helps decide which candidates deserve attention.

Depending on the mission, the supervisor can ask Gemini to:

• prioritize already-detected differences;
• select from deterministically generated boundary tests;
• judge whether the collected evidence is sufficient;
• propose a remediation for a confirmed conformance defect;
• produce neutral alignment options in Equivalence mode; and
• select targeted and regression tests for revalidation.

Every response is schema-validated. Gemini may select only IDs that already exist in the candidate pool; it cannot invent a finding or test. Each mission also has a call limit and a deterministic fallback for every decision point.

On the standard defective demonstration path, the Gemini Action Timeline shows five bounded invocations: prioritization, boundary-test selection, evidence sufficiency, remediation proposal, and revalidation selection.

A clean comparison takes an even safer path: when the sources have zero semantic differences, Gemini is not invoked because there is no judgment call to make. The UI reports "Gemini not invoked by design."

Step 5: Design an asynchronous Google Cloud architecture

Missions perform source compilation, targeted tests, reconciliation, and portfolio analysis, so I did not run them inside a synchronous web request.

The deployed architecture uses:

• Next.js 14 on Cloud Run for the web interface;
• FastAPI on Cloud Run for mission and evidence APIs;
• Cloud Pub/Sub as the durable job queue;
• a private Cloud Run worker for mission execution;
• Firestore for mission state, events, and evidence records;
• BigQuery for the 50,000-policy synthetic Arizona homeowners portfolio;
• Cloud Storage for uploaded sources and compiled artifacts;
• Vertex AI for bounded Gemini decisions; and
• Cloud Build and Artifact Registry for container delivery.

The API validates the request, stores a QUEUED mission, and publishes a job. Pub/Sub delivers it to the private worker using authenticated push delivery. The worker acquires an atomic execution lease before starting, which protects the mission from duplicate delivery. The web application polls the API for status and results; it never calls the worker or Gemini directly.

Next.js and FastAPI create the mission; Pub/Sub delivers it to a private worker that coordinates deterministic engines, Gemini, Firestore, BigQuery, and Cloud Storage.

What one mission gives the release team

For the demonstration scenario, Source A represents approved pricing intent and Source B represents a target implementation with deliberate drift. RateGuard does more than display a JSON difference.

It produces a release evidence package containing:

• the exact pricing elements that changed;
• downstream calculation nodes affected by each change;
• boundary scenarios selected for testing;
• expected and actual premium traces;
• the first divergent calculation node;
• affected policies and simulated financial exposure;
• multi-defect overlap where applicable;
• a proposed isolated remediation; and
• targeted plus regression evidence showing whether the correction worked.

A confirmed material mismatch produces BLOCK_DEPLOYMENT. That decision is backed by the chain from source difference to reproducible premium impact, rather than by an LLM opinion.

A material pricing mismatch is traced to customer-premium behavior and quantified across the synthetic portfolio before deployment.

After remediation, RateGuard reruns selected boundary and regression scenarios. If the proposed correction eliminates the mismatch and no conservative gate remains, the evidence shows the exposure returning to zero.

Running the same process against a clean implementation produces PASS with zero semantic differences and zero exposure. Gemini is not invoked because deterministic equivalence already answers the question.

A clean implementation passes with zero differences and Gemini is not invoked by design.

The value proposition in risk, money, and effort

RateGuard's product value is easiest to summarize in three outcomes.

Risk: stop silent pricing drift before customers experience it

The platform turns a pricing release into a provable conformance or equivalence question. Conservative gates prevent a structural comparison alone from creating a false sense of safety, while evidence lineage makes every finding reviewable.

Money: measure potential exposure while the release is still reversible

Portfolio analysis translates a technical difference into affected-policy counts and simulated financial impact. That gives release owners a way to compare the cost of delaying or correcting a release with the size and severity of the identified exposure - before production remediation, rebilling, support, or regulatory response is required.

Effort: compress a multi-team investigation into one repeatable mission

Source comparison, dependency tracing, test selection, independent recalculation, root-cause analysis, blast-radius analysis, remediation, revalidation, and evidence assembly run as a coordinated workflow. Specialists review the evidence and control the decision instead of manually constructing every artifact.

The long-term vision is for RateGuard to make pricing assurance repeatable: every important rate change receives the same minimum evidence standard, regardless of the vendor platform implementing it.

Conservative decisions were a feature, not a limitation

For pricing assurance, a false PASS is worse than an honest request for review. RateGuard reaches PASS only when its verification signals agree.

Behavioral mismatches override a clean structural diff. Low-confidence source extraction cannot support an automatic pass. Product or jurisdiction mismatches return REVIEW_REQUIRED because comparing unlike products would produce misleading assurance.

This fail-closed behavior also shaped the source-upload experience: invalid structured inputs return specific validation errors, while unsupported formats are rejected rather than approximated.

Testing and deployment lessons

At the time of this submission, the backend test suite contains 389 passing tests, and the frontend passes TypeScript type checking. I also built deployed-system acceptance tests for three judge-visible paths:

• clean Release Conformance -> PASS;
• defective Release Conformance -> BLOCK_DEPLOYMENT; and
• Symmetric Equivalence -> neutral findings and on-demand alignment.

Deployment follows a staged process. Candidate revisions run against isolated staging resources, acceptance tests exercise the deployed system, the verified image digest is promoted as a zero-traffic release revision, and traffic moves only after configuration guards confirm that production revisions do not reference staging resources.

One of my biggest lessons was that production verification must test more than health endpoints. Browser CORS behavior, asynchronous delivery, duplicate execution, evidence persistence, and UI labels are all part of the product's correctness.

What I would build next

RateGuard is a hackathon-scale implementation, not a production carrier platform. Its current boundaries are intentional: JSON-only verified ingestion, a single synthetic Arizona homeowners portfolio, and a single-tenant deployment.

The next steps would be:

• validated adapters for real Excel workbooks and filing PDFs;
• authenticated multi-tenant isolation;
• additional synthetic portfolios for auto and commercial products;
• integrations with commercial rating engines and release pipelines;
• configurable organizational release policies; and
• longitudinal monitoring that compares every pricing change across releases.

Final takeaway

I did not build RateGuard to be another dashboard that says two files are different. I built it to answer the question a release owner actually faces:

Is this pricing implementation safe to deploy, what evidence supports that decision, and what should we do if it is not?

The most useful agentic systems are not the ones that give an LLM control over everything. They give the model a clear reasoning role, surround it with deterministic evidence, constrain its available actions, and preserve a complete audit trail.

That is the product vision behind RateGuard: an autonomous investigator for pricing changes, with deterministic math and human-controlled release authority.

You can explore the live RateGuard application or review the open-source repository.

---

Editorial disclosure: We designed and built RateGuard and reviewed the technical claims in this article against the project implementation and README. I used ChatGPT to help organize and edit this write-up.