AaryaDoc

An autonomous agent that cross-checks an applicant's own uploaded documents for internal consistency — resolving what's decidable by rule, and flagging only what needs a human's judgment.

Comment

Inspiration

Most government and utility applications in India need two documents: an identity proof, and a property or occupancy proof. A human checks both and approves.

Simple, on paper. Not simple in practice.

When the property document lists five family members — not one name, five — the reviewer has to confirm the applicant is exactly one of them. Not similar. Exact. Under time pressure, with dozens of applications a day, that's exactly the kind of check a human eye is built to miss.

We checked if anyone had already solved this — DigiLocker, UIDAI, India's national single-window system, Google's own agent platform, and every major hackathon in this space. Found no publicly documented equivalent in the workflows we researched.

So we built AaryaDoc.

🎯 Domain-Specific Verification & Technical Differentiation

Generic IDP platforms (e.g., Google Document AI) and KYC verification APIs (e.g., Signzy, HyperVerge) extract data from single documents in isolation. While effective for basic key-value extraction, they are not built to resolve multi-document relational compliance or complex Indian revenue document structures. AaryaDoc bridges this gap by evaluating document sets as a cohesive system.

To establish this gap, we evaluated standard document-processing logic against complex Indian revenue payloads (such as multi-owner 7/12 land extracts matched against patronymic identity proofs):

Compliance Vector Standard IDP / KYC APIs AaryaDoc Architecture
Verification Model 1-to-1 Lookup: Compares a single ID against a database or standard extraction schema. N-to-N Relational Audit: Cross-validates 7/12 extracts, identity proofs, legal heir affidavits, and financial records simultaneously.
Regional Name Matching Fuzzy / Levenshtein Distance: Relies on aggregate character similarity scores, which fail or falsely pass generational naming shifts. 13 Deterministic Regional Rules: Implements Gujarat-specific naming normalization (Surname-First-Father) to explicitly isolate father/husband tokens.
Co-Ownership & Succession Extraction-Only: Reads name strings; ignores historical mutation records or undivided shares. Relational Audit Engine: Maps joint holdings, detects un-mutated deceased co-owner shares, and flags missing succession links.
Decision Pipeline Opaque Confidence Score: Returns an aggregate percentage score (%) that forces manual review queues to work without context. Deterministic Exception Routing: Executes strict business logic in code while utilizing LLMs solely for natural-language audit reporting.

Observed Failure Mode in Standard Matchers

When evaluating a government ID (Patel Vikram Dahyabhai) against a land record (Vikramkumar Rameshchandra Patel), standard token-overlap algorithms fail to isolate the patronymic mismatch. They either generate an unsafe high-similarity pass based on shared tokens (Patel, Vikram) or trigger a non-specific manual review flag.

AaryaDoc handles this via a two-layer architecture:

  1. Deterministic Rule Layer: Identifies the generational discrepancy between father tokens (Dahyabhai vs. Rameshchandra), detects the un-mutated deceased co-owner entry on the 7/12 extract, and hard-blocks auto-approval.
  2. Generative Reporting Layer: Gemini 3.6 Flash synthesizes the underlying rule flags into an actionable, plain-English audit report for the legal reviewer, specifying the exact missing mutation entries and documentary gaps required to clear title.

What it does

Before writing a single line of code, we ran the design through six rounds of adversarial testing across two independent AI systems. Not for polish — because the first version of this rule set would have caused real harm.

  • It would have flagged every married woman whose documents show her father's name on one and her husband's name on the other. Normal life event. Not suspicious. We fixed that.
  • It would have flagged every legitimate tenant, because the first version assumed the applicant had to be a property owner. We built a separate path for that.
  • It would have flagged the same person's name written in a different order across two documents — as if they were two different people. We fixed that too, with a normalization layer built specifically for how Indian names actually work.

Once the rules were locked, we built it as five agents on Google ADK, running on Gemini 3.6 Flash, deployed to Cloud Run. The rules and severities are deterministic code — Gemini only does two things: reads the documents, and writes the plain-English explanation of a flag. It never touches the decision.

How we built it

Deployment & Infrastructure: Built and deployed on Google Cloud Run (https://aaryadoc-213157516515.us-central1.run.app/docs). Live container execution, start-up logs, rollout revisions, and API request handling (POST /run_v1 200 OK) are explicitly demonstrated in our YouTube demo video.

The system consists of five agents orchestrated via the Google Agent Development Kit (ADK) powered by Gemini 3.6 Flash. Severities and matched values live entirely in deterministic code, isolating LLM execution strictly to explanation generation and structured natural-language reporting.

Challenges we ran into

Getting the false-positive rate right was the actual hard problem. Anyone can build a system that catches mismatches. Building one that doesn't punish ordinary people for ordinary things — a maiden name, a reordered name, a name spelled with a V instead of a W — took real iteration.

Deciding severity took the same discipline. Not every mismatch deserves the same alarm. We built that judgment in deliberately, not by default.

We also identified, but deliberately did not rush to fix in this build cycle, a real gap: a low-confidence extraction (a blurry or damaged scan) and a confirmed mismatch between two documents currently surface with the same severity. Separating "the documents disagree" from "the scan was too poor to judge" is the single highest-priority improvement for the next version — we chose not to touch the locked, tested rule engine to add it in the final days before submission, rather than risk destabilizing a working system.

And we built and tested all of this on Gemini's free tier — twenty requests a day. That forced real discipline about when to test with live calls and when not to.

Accomplishments that we're proud of

We stress-tested the design six times before writing code, and every round found a real problem — not a cosmetic one. Catching those before they shipped, instead of after they hurt someone, is the thing we're most proud of here. Not the code. The discipline that shaped the code.

All three test scenarios run exactly as designed, on the actual deployed Cloud Run service, not just locally — including the one that matters most: a joint-holder name mismatch, caught, explained, and correctly escalated, with the system never once deciding on its own.

We also proved the architecture is genuinely modular. Severities and matched values live entirely in deterministic code. Gemini writes explanations, nothing else. If Gemini goes down mid-request, the system falls back to its own technical note instead of breaking — and we watched that fallback fire for real, in production, not in a test.

What we learned

A tool built to catch human error can become its own source of harm if you don't take its false-positive rate as seriously as its true-positive rate. Every choice in AaryaDoc — the conservative severities, the human-only decision, the plain statement of what this system does and doesn't do — exists because catching the real problem is only half the job. Not creating a new one is the other half.

We also learned that honesty about limitations isn't a weakness to hide from judges or future users — it's the thing that makes the rest of the claims believable.

What's next for AaryaDoc

Right now, AaryaDoc checks whether an applicant's own documents agree with each other. It doesn't check them against government records, and it doesn't yet distinguish a hard-to-read scan from a genuine contradiction. The next steps are separating those two cases in the rule engine, and connecting to systems like DigiLocker for identity documents — which requires formal registration as an approved partner, not open access — and, where publicly available, land-record systems. Moving from "do these documents agree" to "are these documents true."

Deployment Architecture: A Parallel Line, Never a Gate

AaryaDoc is designed to run in parallel on a copy of submitted documents—it never alters official database records, blocks intake, or makes autonomous decision calls. Human reviewers retain 100% final decision authority while consulting AaryaDoc’s plain-language verification reports.

A note on how this actually works, stated plainly

To be precise about what's built versus what's envisioned: AaryaDoc today is a document-in, report-out system — an applicant's documents are provided to the pipeline, checked, and a report is produced for a human reviewer. It is not currently an agent that runs embedded inside a client's own existing case-management system, reading documents already stored there without a separate submission step. That distinction matters, and we don't want to blur it: a true in-place deployment — where the agent operates directly inside a client's own infrastructure and database, with zero document transfer — is real future direction we've thought through carefully, not a claim about what this hackathon build does today.

Built With

Share this project:

Updates

Submission history