Coa Connect with us
03

Case Study — 2026

The Synthetic VA: A Flight Simulator for Government Software

Product Adjudicate Docket
Domain Federal Benefits · Appeals
Population 177,000 Synthetic Veterans
Scroll

Every demonstration of Adjudicate Docket runs entirely on a replica. The product signs in, looks up a veteran who was never born, opens an appeal that was never filed, reads a case file no scanner ever produced, schedules a hearing nobody will attend, and issues a decision that affects no one. Every screen behaves exactly as it would inside the government, because behind the product stands a faithful synthetic copy of the systems it will meet there.

Software built for government has an integration problem before it has a code problem. The systems a product must talk to hold real records about real people, so a vendor cannot develop against them. The usual answer is a mock: a stand-in that returns tidy, instant, perfect responses. The mock is polite. The real systems are not. Every difference between the two is a defect the customer discovers after they go live.

So Ari built the whole thing. The synthetic VA is a working replica of the eleven government systems Adjudicate connects to for benefits records, identity, documents, hearings, and notifications. Each runs as its own service at its own address, speaks the real system’s protocol, and behaves the way the real system behaves, including the ways it misbehaves.

The replica changed how the product is built, not only how it is tested. The 42 screens in the current edition began as design mockups, were built into the live product, and were proven against the synthetic VA before any real user saw them. Design, build, and rehearsal run on the same synthetic caseload, so a screen that looks right also has to behave right, against thousand-page files and slow gateways, before it ships.

“Synthetic VA allows us to build close-to-production products with replicas of VA systems and 177k demo veterans, without access and compliance issues.”

In the Replica
177,000
Synthetic veterans, every fact fictional
11
Government systems simulated, each at its own address
In Practice
0
Real records in development, rehearsal, or demonstration
42
Screens proven against it before any real user saw them

The Doctrine

Built to Be Difficult

Think of a flight simulator. A good one is hard on you, because a simulator that flatters its pilots trains them to crash. The synthetic VA follows the same rule, and the project’s first law says it plainly: simulate how hard the real government is. Never make the product’s life easy.

So nothing answers instantly. Every call waits a realistic amount of time, drawn from the long-tailed distributions real systems produce: most responses come back quickly, and a few take painfully long. A heavy document costs more time per page on top.

The faults are real too. The gateways enforce rate limits and tell an impatient caller to slow down. A small share of identity lookups fail on the first key. The database that holds the oldest records runs out of connections under load, because the real one does. An identity search can return two candidates for one person, and a retired identifier still resolves to the veteran who once carried it, because both things happen in the real systems and a product must handle them.

Agents building the product keep proposing to soften one of these constraints to make a feature easier. The standing answer is no, because a product built against a fantasy fails the day it meets the real VA.

The strictest rule is the least visible. The real interfaces offer no bulk queries, so the replica refuses them too. A product that wants a worklist must build one from its own legitimately fetched data, case by case, the way it will have to inside the government. The inconvenient path is the point.

The product is still allowed to be fast. It earns speed the way a real product does: caching what it has legitimately fetched, building its own read models, indexing its own store. The one sin is making the replica easier than the government.

The Population

177,000 Veterans, None of Them Real

Nobody scrubbed a real dataset to make this population, because a redacted record is still a real record with holes in it. Every record is generated from scratch. The result is 177,000 synthetic veterans whose files are statistically faithful and factually fictional: the mix of claims and the share of decades-old legacy cases follow the real distributions, and not one fact belongs to a living person. The population even includes the deceased, because real caseloads do, and a product that has never met a deceased appellant will meet one in its first week of production.

The population is not stored anywhere. Every record is computed on demand from a seed, the way a video game generates an enormous world instead of saving one, which is why a service simulating 177,000 veterans fits in about fourteen megabytes. Every machine that runs the replica sees byte-identical veterans, because the generator’s random streams are frozen: a change that would reorder a single draw fails the build. The generator also exists twice, once in the replica and once in the product’s contract layer, and a fixture test pins the two implementations to each other byte for byte.

One person is one person everywhere. A veteran keeps the same identity across every system, under every key each system uses, so a file pulled from one service and a hearing scheduled in another belong to the same fictional life. The tests prove it: the same veteran has to show up, identical, across three different protocols before the suite passes.

Identifiers are drawn from reserved synthetic ranges, and a scanner fails the build if anything shaped like a real identifier appears anywhere in the tree. Zero real records is not a policy in a document. It is a gate in the build.

The Systems

Faithful Down to the Database Engine

Government systems do not share one architecture, so neither does the replica. One service speaks SOAP with signed security headers. Another answers identity queries in a healthcare messaging standard. The oldest has no API at all: the product talks to it the way the government does, in raw SQL, against the same commercial database engine the agency itself runs. The document repository serves the government’s actual public forms, filled in for synthetic veterans. Nothing was flattened into one tidy interface, because nothing in production is.

And the replica is not a script on a laptop. It runs as a standing environment: eleven services, each in its own container at its own address behind TLS, plus the legacy database running as an actual instance of the same commercial engine the agency operates. The product connects across a network, with certificates, timeouts, and everything else the real connection involves.

Copying systems no vendor is allowed to see sounds impossible, and the answer is that nobody copied them. The government runs open-source applications that consume these same closed systems, and their code, their test doubles, and their recorded wire fixtures are public. The replica’s interfaces were derived from that public evidence plus the published interface specifications: real shapes, sanitized endpoints, synthetic test data, never production traffic and never a real byte.

Every shape is cited. Each simulated service carries a header tracing its responses and its behavior to a real, public source, and a check fails the build if a service cannot show its citation. The responses match the government’s published contracts closely enough that an agency engineer could diff them against the specification.

Adjudicate's systems-integration console on the synthetic VA: live diagnostics against a simulated government document repository.
The systems console, run against the synthetic VA: the same interfaces, protocols, and fault modes as the real thing, with zero real records behind them.

The Paperwork

The Government’s Own Forms, Filled In

The documents had to be real too, because Adjudicate is document software. The replica’s file repository serves the government’s actual public forms with synthetic veterans typed into them, not paragraphs of invented prose pretending to be a form.

That was harder than it sounds. Government forms are dynamic PDFs in a format most tools can only partly handle: free libraries can fill in the data but cannot draw the result. So the pipeline runs in two stages. An offline step downloads each public form, flattens it into a plain drawable page, and records the exact position of every field. At runtime, a filler lays each synthetic fact onto its recorded position: checkboxes matched to the exact option they tick, long statements word-wrapped into their boxes, dates pinned so the same veteran produces the same document every time.

A reviewer opening the replica’s files sees the claim form, the appeal form, the personal statement, and the power-of-attorney the way they would arrive from the real repository, at their true page counts. The document engine that has to survive hundred-page scans practices on the real paperwork, not a simplification of it. So does the AI layer: the features that extract, summarize, and cross-reference are exercised against documents with the government’s true structure, at the government’s true page counts.

The Seam

One Line Between Product and Replica

The rule that keeps the whole arrangement honest: the product reaches the replica only over the wire, through the same typed contracts it will use in production. There is no side door, no shared library, no direct import. If a feature works, it works across a network, against services that behave like the government’s.

ADJUDICATE DOCKET the product · its own data in its own store ONE LINE typed contracts TLS · modeled latency rate limits · faults THE SYNTHETIC VA · ELEVEN SERVICES, EACH AT ITS OWN ADDRESS BENEFITS REGISTRYSOAP · signed headers IDENTITY REGISTRYhealthcare messaging DOCUMENT REPOSITORYSOAP · file attachments LEGACY DOCKET DBraw SQL · no API CASE MANAGEMENTREST + its own database API GATEWAYREST · 429s + retry-after VIDEO HEARINGStwo vendors, two APIs NOTIFICATIONStemplated delivery BULK MAILsubscription delivery SINGLE SIGN-ONfederated handoff REPORTINGsingle-use tickets no service imports another service SHARED PRIMITIVES · POPULATION SEED · LATENCY + FAULTS · STATE PROVENANCE — every shape and behavior cited to a real, public source; the build fails without a citation The legacy docket database runs as an actual instance of the same commercial engine the agency operates. The product’s worklist is its own data, built case by case — the replica offers no bulk reads, because the real systems offer none.
The shape of the rehearsal. The product sits on one side of a single wire of typed contracts; eleven simulated services sit on the other, on three shared primitives that generate the population, the latency, and the faults.

The wire also frees the replica to evolve. Because consumers see only protocols, any service can be rewritten in a faster language behind its address, and a differential test proves the new implementation behaves exactly like the old one. The seam is the contract; everything behind it is negotiable.

A single command runs the whole proof: eight gates across the replica, the contracts, and the product, from the population’s consistency to a live call over every protocol. Nothing merges until all eight pass. The latency and the faults have dials, and the dials exist for one purpose: unit tests that need to run in milliseconds. A live flow never touches them. The same seam is why a demonstration is safe to give anywhere: the laptop carries the whole government with it.

The Referee

Checked Against the Government’s Own Algorithm

Some behavior is too important to approximate. The government publishes the algorithm that distributes appeals to judges, and Adjudicate’s implementation is pinned against an executable copy of it, matched on every pick and every remainder. When the two disagree, the build fails and the product changes, never the referee.

Distribution decides fairness: which judge hears which appeal, in what order, under what priority. An approximation that is right most of the time is a defect that surfaces as a pattern, months in, in someone’s docket. Pinning against the government’s own executable copy removes the approximation entirely.

The product cannot tell any of this from the real thing, and that is the entire point. A product that survives the replica is ready for the real thing.

What This Means

Proof Should Arrive Before the Contract

Government software usually breaks where systems meet, and nobody finds out until the worst possible moment: after award, after deployment, on production systems, with real records at stake. The synthetic VA moves that discovery to the cheapest moment instead: development, where a failure costs an afternoon, not a program.

The replica also changes what a buyer can ask to see. A demo on slides proves nothing, and twenty minutes of clicking can be staged. A product running live against a faithful replica of the agency’s own systems, misbehavior included, is a different class of evidence, and an agency can watch it on day one, before any credential is issued or any record is exposed.

None of this is specific to veterans’ appeals. Any agency that publishes its interface specifications could have a replica like this built, give every bidder the same copy, and judge the bids by how the software behaves instead of what the proposal promises.

It could also change the code challenge. Most challenges today ask vendors to build a small app against a clean mock, which shows how a team writes code but not how its product handles a real agency’s systems. A shared synthetic agency would show that difference directly. Ours practices on one every day.

The Outcome

By the time the product meets the real government, it has already survived a faithful copy of it. Everything below runs today, in development and in every demonstration.

177,000
Synthetic veterans in the population
Statistically faithful, factually fictional.
11
Government systems simulated
Each its own service, each traced to a real, cited interface.
0
Real records anywhere
Development, rehearsal, and demos run entirely synthetic.
42
Screens proven against it
Designed, built, and rehearsed before any real user saw them.

We didn't want to interrupt. We may not always be taking clients, but leave your email for our latest thinking and to connect down the road.

Skip to content