Parity

Inspiration

AI can now "migrate" a 40-year-old COBOL batch job to Python or a Java service to Go in minutes. The hard part was never generating the new code. It's trusting it.

A migration that is 99.99% correct can still be catastrophically wrong. A one-cent rounding difference on a payroll run, repeated across millions of records, is a compliance incident and a lawsuit. Yet teams ship AI migrations backed by little more than a git diff and optimism.

The root cause is subtle. COBOL's ROUNDED clause rounds half away from zero, while Python's default float arithmetic rounds half to even (banker's rounding). For a value landing exactly on a half-cent, the two disagree:

COBOL Rounding: Rounds half away from zero (e.g., 2.005 becomes 2.01)
Python Rounding: Rounds half to the nearest even number (e.g., 2.005 becomes 2.00)

A single line of "equivalent" code, a one-cent gap, thousands of times over. We wanted a forensic instrument that doesn't guess whether two programs are equivalent—it proves it on real inputs and leaves an auditable record.

What it does

Parity is an independent verification layer for AI-generated legacy-code migrations.

You give it a legacy program and its migrated counterpart (or use the built-in demo) and declare a comparison contract. Parity then runs a 7-stage pipeline:

Generate: 10,000 inputs plus crafted boundary cases that land on exact half-cents.
Execute legacy: (the oracle / ground truth) in an isolated sandbox.
Execute migrated: against the same inputs.
Mask: legitimately-variable fields (timestamps) within a per-field tolerance.
Compare & localize: one field_diffs row per case per field, aggregated into findings.
Explain: each finding with an LLM: root cause + a concrete suggested fix.
Certify: CERTIFIED if nothing diverges, NOT_CERTIFIED if anything does.

The product isn't the test runner—it's the equivalence ledger and the verdict. Every value, delta, and finding is reconstructable by SQL joins, so a NOT_CERTIFIED verdict ships with its full chain of evidence:

certifications ➔ verification_runs ➔ field_diffs ➔ test_cases

Standout Features

Re-verify arc: Upload a fix on a failed run and watch it go from NOT_CERTIFIED to CERTIFIED, with the drift chart recording the recovery.
Ask the ledger: A natural-language copilot that turns "which inputs diverged the most?" into read-only SQL over your run's evidence.
Live pipeline progress: Real stage telemetry streamed from the worker.
Hardened sandbox: Uploaded code runs with a scrubbed environment, resource limits, and process-group kills.

Our flagship demo migrates a COBOL interest & payroll calculator to Python. The seeded rounding bug makes final_amount diverge by exactly one cent on a fraction of inputs—deterministically, every run—and Parity refuses to certify it.

How we built it

Three components that communicate only through the database:

Frontend + API: Next.js (App Router, TypeScript) on Vercel. UI plus API route handlers that enqueue runs and serve ledger data back via SQL. No heavy execution in the serverless layer.
Database (Amazon Aurora PostgreSQL): The equivalence ledger and the job queue. A queued row in verification_runs is the queue; the worker claims it atomically with FOR UPDATE SKIP LOCKED. The dashboard analytics—divergence rate per field, drift across runs, coverage—are real SQL aggregations and window functions over the ledger, not numbers computed in JavaScript.
Verification worker: Node + TypeScript. A long-running poll loop that runs the pipeline, shelling out to GnuCOBOL (cobc) and python3 inside a hardened sandbox, and writes all evidence to Aurora.

The LLM is used twice: to explain each finding, and to power the natural-language to SQL ledger copilot.

Challenges we faced

Running untrusted code safely: Uploaded programs are hostile by default. We scrub the child environment so they can never read our database URL or API keys, add ulimit caps (address space, CPU, file size, processes) and an output-flood guard, and SIGKILL the entire process group on timeout.
Determinism: The demo must fail the same way every time. We seed boundary inputs on exact half-cents so the rounding divergence is always observable, never flaky.
One ledger, two writers: The Vercel app and the worker had to share a single Aurora cluster. We made DATABASE_URL the single source of truth so the app reads exactly what the worker writes—no split brain.
Trusting an LLM with SQL: The copilot generates queries, so we wrapped it in defense in depth: a keyword denylist, single-statement validation, a forced row cap, and execution inside a read-only transaction with a statement timeout. The model can never write.

What we learned

Equivalence is a data-modeling problem as much as an execution problem. Once the schema was right, the verdict, the analytics, and even a safe natural-language copilot all fell out of the same tables—joins, aggregations, and window functions, nothing bolted on. We also learned how much careful engineering "just running someone else's code" actually demands.