Sai Krishna Ranjan Gauravarapu builds machine learning systems that work inside some of the most heavily regulated software environments in existence. As an applied machine learning engineer at Amazon Web Services, he develops automated medical coding models and agentic clinical systems that operate within electronic health record workflows, where a wrong output carries consequences for patients, providers, and payers alike.
His path to healthcare AI runs through industrial fault monitoring, financial recommendation systems, and graduate research at UC San Diego, where his published work has drawn roughly 250 citations. Across all of it, one question keeps surfacing: how do you make a model trustworthy enough that a clinician, an operator, or a scientist will actually rely on it? We spoke with Ranjan about calibrated uncertainty, what production engineering teaches you that research papers don’t, and where clinical AI goes from here.
Your day job is building clinical AI systems at AWS, but you also review papers and serve on program committees. How did the reviewing work start?
It really started because I had been on the author’s side first. I had published earlier work on fault monitoring, and during my master’s at UC San Diego, I worked on research around climate data tooling that we presented at PLATEAU.
After going through peer review a few times, I became interested in contributing from the other side. My first invitation came through IEEE for EIT 2026, and from there I was invited to serve on the program committees for ICDM 2026 and SIGCSE Virtual 2026. I have also judged three hackathons, most recently the Call for Code AI track run with the Linux Foundation and UN Human Rights.
What made the reviewing work a natural fit was that I understood the research process, but I had also seen what happens when technical ideas have to operate under real constraints. That combination shaped the kind of reviewer I became.
Industrial researchers from major labs already participate in peer review. What’s different about what a production engineer sees in a paper?
The distinction that matters to me is not industry versus academia. It is whether you still own the system after it ships.
A lot of strong reviewers can evaluate whether a result is correct. Fewer have had to answer for it months later when the data has shifted, the latency budget no longer survives real traffic, or an edge case has become the dominant failure mode.
That changes the questions you ask. I still read for correctness, but I also look at which assumptions have to remain true, how the method behaves outside the average case, and whether the reported cost reflects what it would actually take to run.
That perspective does not replace academic rigor. It tests whether the result remains meaningful once it leaves the paper.
You’ve said benchmark performance often falls apart in deployment. What does that failure actually look like in a healthcare setting?
In healthcare, failure usually does not look like a model suddenly becoming useless. It is often much quieter.
A model can perform well on a benchmark, but once it is deployed, the patient population may be different, the data may come from different devices or workflows, and important fields may be missing or delayed. What appears to be a small drop in average performance may be concentrated in one subgroup, while the headline number still looks acceptable.
There is also drift over time. Clinical practice changes, coding standards are revised, and documentation patterns evolve. The system was validated against a snapshot of that environment, so degradation may happen gradually without a clear moment when something breaks.
Then there is the workflow itself. Even an accurate model can fail if it answers too late, creates too many alerts, or gives a result without enough context for someone to act on it. Clinicians stop trusting it, and that trust is difficult to rebuild.
So deployment quality in healthcare is not just accuracy. It is whether the system stays reliable, understandable, and useful inside a real clinical workflow.
Walk us through how you evaluate a paper. What do you flag that an academic reviewer might not?
I usually read a paper twice.
On the first pass, I focus on the claim. What are the authors actually saying they have shown, and does the evidence support that claim or only a weaker version of it? A lot of my comments come from the gap between what the abstract asserts and what the experiments establish.
On the second pass, I focus on the evaluation. Are the baselines meaningful? Could anything have leaked across the data splits? Are the gains larger than the variance? Is the average hiding what happens at the tail?
Then I look at whether the experimental setup depends on conditions that are unlikely to hold outside the paper. That might include clean inputs, stable data distributions, unrealistic compute assumptions, or failure modes that were never characterized.
I also try to make the review actionable. I do not only say what is missing. I explain what additional evidence or changes would affect my assessment.
What does a company actually gain when its senior engineers take on reviewing and judging roles?
Visibility is one benefit, but I think the more important gain is judgment.
When senior engineers review papers or judge technical work, they are exposed to a much wider range of ideas than they would see inside one company. You see what researchers are trying, which ideas are gaining momentum, and which approaches repeatedly fail under scrutiny. That sharpens how you evaluate technical bets internally.
It also forces you to articulate your reasoning. Writing a good review means separating what is genuinely new from what is only well presented, and naming exactly what evidence is missing. Those are the same skills you use when reviewing designs, mentoring engineers, or deciding whether a system is ready to ship.
There is also a broader benefit. The standards of a field are shaped by the people doing the reviewing. Companies have a real interest in ensuring that those standards reflect not only what is publishable, but what can actually be built and sustained.
Before healthcare, you worked on industrial fault monitoring and financial recommendation systems. Did the reliability problem look the same in each industry, or did each one teach you something new?
The underlying problem was similar in all three. A model can look strong in development and still fail once the environment starts changing. But each domain exposed a different part of that problem.
Industrial fault monitoring taught me about rare events and asymmetric failure. Most of the data describes normal operation, while the events you care about are infrequent and often poorly labeled. A false alarm is disruptive, but a missed fault can be much more expensive.
Financial recommendation systems taught me that user behavior changes in response to the system itself. Once recommendations influence what people click or choose, the data is no longer passive. You have to think about feedback loops, shifting preferences, and whether short-term engagement is aligned with the outcome you actually care about.
Healthcare adds delayed and incomplete ground truth. In fault monitoring, you often get a clearer operational signal when something goes wrong. In recommendations, the click gives you feedback. In healthcare, the outcome that would tell you whether the system was right may not be observable for a long time, or at all.
So, each industry expanded what reliability meant to me, from model performance, to system behavior over time, to whether people can safely use a result that cannot always be verified.
A senior engineer reading this might assume peer review is closed to anyone without an academic title. What would you tell them?
I would tell them it is far more open than it looks, and that the assumption itself is often what keeps people out.
An academic title is not the only route into peer review. Venues need people who can evaluate work carefully, understand the subject, and write useful feedback. Conferences and workshops often publish calls for reviewers, and people can also reach out directly when their background fits the topic.
Publishing your own work helps because it shows you understand the process from the author’s side. Workshops can be a practical place to start, and judging hackathons or technical competitions builds many of the same evaluation skills.
It also compounds. When you write a thoughtful and actionable review, people remember it and invite you again.
Practitioners are not outsiders to the process. Someone who has had to build and maintain real systems may bring exactly the perspective a reviewer pool needs.
If you could change one thing about how AI conferences select reviewers, what would it be?
I would put more weight on complementary experience, not just publication history.
Publication history is useful because it signals subject knowledge, but it can also make reviewer pools narrower than the work itself. If everyone is selected through the same pathway, papers may be evaluated against the same assumptions, and important practical weaknesses can go unnoticed.
I would want program chairs to think more deliberately about the mix of perspectives assigned to a paper. Some reviewers may bring deep theoretical expertise, others may be especially strong on experimental design, and others may understand what happens when a method is deployed under real constraints. The goal is not to find one reviewer who covers everything. It is to build a group that tests the paper from different angles.
I am not arguing for replacing academic expertise. I am arguing for a review process that asks whether the work is novel, whether the evidence is sound, and whether the assumptions would survive outside the paper.
