BridgeR

Inspiration

Many organizations still rely on legacy SAS workflows for public health, clinical research, epidemiology, and statistical reporting. Moving those workflows to R is appealing because R is open, flexible, and widely supported—but migration is much harder than simply translating syntax.

A SAS program and an R program can both run successfully while producing meaningfully different results because of differences in reference categories, event coding, missing-value handling, factor contrasts, filtering, joins, or statistical defaults.

That problem became especially clear through conversations with public-health professionals who are interested in moving from SAS to R but do not necessarily have the time or specialized statistical programming expertise to manually rebuild and validate every workflow.

That inspired BridgeR.

Our goal was not to build another AI code translator. We wanted to build a system that could answer a much more important question:

How do we know the translated R analysis actually reproduces the SAS analysis?

What it does

BridgeR is an autonomous SAS-to-R migration and statistical equivalence verification system.

Instead of stopping after generating R code, BridgeR follows an end-to-end migration workflow:

SAS workflow → R translation → R execution → deterministic validation → discrepancy diagnosis → autonomous repair → revalidation

If the translated workflow passes the predefined equivalence checks, BridgeR produces a validated R workflow and audit trail.

If something does not match, BridgeR analyzes the failure, identifies the likely cause, selects the relevant migration skill, repairs the R code, executes it again, and reruns validation.

If the problem cannot be resolved safely, BridgeR escalates the case for human review rather than pretending the translation is correct.

The philosophy behind the system is simple:

R calculates. AI assists. Humans review.

How we built it

BridgeR combines generative AI with deterministic statistical validation.

Gemini is used for tasks where reasoning is useful, including:

understanding legacy SAS code; generating an initial R translation; diagnosing validation failures; selecting relevant migration skills; repairing translated code; explaining discrepancies in understandable language.

However, Gemini does not decide whether the migration is statistically equivalent.

That decision is made by deterministic validation code.

For example, depending on the analysis, BridgeR can compare quantities such as:

number of observations used; category counts and percentages; missing-value behavior; summary statistics; regression coefficients; standard errors; odds ratios; confidence intervals; p-values; reference categories; event definitions; predicted probabilities.

Numerical comparisons use explicit tolerances rather than subjective LLM judgments.

This separation between AI reasoning and deterministic verification is one of the most important design decisions in BridgeR.

Challenges we ran into

The hardest part of the project was realizing that syntactic translation is the easy part.

The difficult part is semantic equivalence.

SAS and R often encode the same statistical intention differently. A migration system therefore needs to understand not only what code looks like, but also what statistical result the code is supposed to produce.

Another challenge was deciding where AI should—and should not—be trusted.

LLMs are excellent at code generation and troubleshooting, but statistical verification should not depend on an AI model saying, "these results look similar."

That led us to separate the system into two layers:

AI for reasoning and repair. Deterministic software for verification.

Privacy was another major consideration. BridgeR is designed so that AI reasoning can preferentially operate on SAS code, R code, schemas, metadata, error messages, and validation differences instead of requiring raw sensitive records. Real analytical data can remain within the execution environment whenever possible.

Accomplishments that we're proud of

keep moving forward

What we learned

The biggest lesson from building BridgeR is that the most valuable use of AI in professional statistical work may not be generating more code.

It may be creating a system that can generate, test, identify its own failures, repair those failures, and know when it should stop and ask a human for help.

That is a fundamentally different model from a coding chatbot.

BridgeR turns migration from a one-shot generation task into an evidence-driven workflow.

What's next for BridgeR

The current version focuses on a narrow set of high-value SAS workflows and synthetic demonstrations rather than claiming support for the entire SAS language.

The next steps are to expand procedure coverage, strengthen the equivalence engine, evaluate BridgeR against a larger library of known SAS-to-R failure cases, and test the workflow with real analysts transitioning legacy statistical programs to R.

Longer term, we envision BridgeR as an AI-operated migration service where routine translation and validation are automated while statisticians focus their attention on the small number of cases that genuinely require expert judgment.

Our goal is not to remove statisticians from the process.

It is to make their expertise scale further.