Govind Ravi Sulekha

The problem

Since around 2020, journals have received unprecedented submission volumes, driven by generative AI and paper mills. Editorial staff cannot manually process what arrives. Before this, publishers relied entirely on manual screening for both research integrity and technical compliance, which meant integrity problems were caught late, inconsistently, or not at all.

What I did

I built integrity checking from scratch into what became IntegrityGuard, now roughly 60 checks spanning paper-mill activity signals, transparency signals, authorship signals and reference analysis, deployed as an API that publisher-facing products consume. I owned the check logic, the evaluation criteria and the product surface, and I ran the client integrations that put it into production inside publishers' editorial systems: pre-sales, pilots, RFP responses, security and procurement review, phased delivery, UAT and post-launch validation.

The result

Roughly 20,000 manuscripts a day now pass through it in production. A published whitepaper showed that Preflight screening significantly reduces desk rejections. The B2B segment it powers went from $0 to over $1M in new ARR in FY2025-26.

Taking a problem that lived entirely in domain experts' heads and turning it into a system that runs twenty thousand times a day without them.

The problem

Peer review is the bottleneck in scholarly publishing. Reviewers are overloaded, the work is unpaid, and journals struggle to find qualified reviewers at all, which delays publication for everyone.

What I did

I conceived, specified and shipped PeerPilot: a supervised multi-agent system that takes a manuscript and produces a structured peer review report. A supervisor agent coordinates a gatekeeper and summarisation stage for validation and token economy, a methodology and statistics agent with a code interpreter that queries clinical trial registries, PROSPERO and an internal scholarly article corpus, a literature agent, and a reporting guidelines compliance agent that evaluates against CONSORT, PRISMA and STROBE. It runs on the AWS Strands SDK, is migrating to Agno, and is instrumented with LangFuse.

The harder half was evaluation. I designed a process where human peer reviewers score every generated observation for agreement, module by module, and separately log major issues the system missed. That second half is the part most teams skip, and it is the only way to measure false negatives, which is what actually matters when a reviewer is trusting the output.

The result

Roughly 8,000 reports since the December 2025 launch, at roughly $29 each, with a 10% conversion uplift on participating journals. More than a dozen publishers piloted the B2B offering, and a major computing society has signed an annual contract for workflow integration in 2026.

Shipping agentic AI into a workflow where being confidently wrong has a real cost, and building the measurement discipline to know when it is.

The problem

PeerPilot produces observations. Observations are not the job. A reviewer still has to read the manuscript, weigh what the system flagged, and write something useful, and asking them to hold a PDF in one window and a report in another does not help them.

What I did

I own the reviewer workspace: manuscript on one side, and on the other a tabbed panel holding PeerPilot observations, tools, actions and checklists, so the reviewer's attention stays in one place. My role ran from ideation and backend design through report and scoring design, UI and UX direction with designers, and defining the information architecture.

The result

Contract signed for integration into a major computing society's editorial workflow, going live later in 2026.

Owning the whole line from model output to the interface a human actually works in, and knowing that the second part is where the value gets realised.

The problem

The client is an international organisation that produces systematic reviews of clinical trials. Their submissions have to satisfy reporting standards that exist precisely because clinical evidence is easy to report badly, and checking that by hand, item by item, does not scale.

What I did

I delivered a custom checks pipeline integrated into their editorial management system: locating and validating trial registration numbers, validating CONSORT and PRISMA flow diagrams, and testing reporting consistency across effect sizes, the order in which effects are reported, and evidence quality statements, alongside strict citation format enforcement.

Building software that has to reason correctly about clinical trial reporting standards, for a client whose entire reputation rests on getting that right.

The problem

A large scientific society publisher asked for a check that would tell them whether a manuscript submitted in the current round differed significantly from the previous round. Submissions are PDFs, many checks run in real time during the author's submission flow so the latency budget was tight, and the client wanted the result to be explainable.

What I did

The detection was straightforward: extract text from both PDFs, compute a Levenshtein ratio, flag below a threshold that we tuned with the client after deployment. Explainability was the interesting part. My first design wrote both texts into documents, ran a compare-merge to produce a tracked-changes view, converted it to PDF and offered it for download.

Then I went back to the editorial team and asked who was actually going to look at it. It turned out the author-side real time display barely mattered, because authors were allowed to submit regardless. The real consumer was the editor, not in real time, and editors did not want to download another PDF. They wanted to know which paragraphs had changed. Not how they had changed. Which ones.

So I cut the compare-merge and shipped markers instead: page number, paragraph number, and the opening text of each significantly changed paragraph. Exactly the signal the editors needed, and it removed two third-party API dependencies from the design, which lowered the unit cost.

Discovery is not gathering requirements. It is finding out who the user really is, and being willing to throw away a design you have already worked out.

The problem

The same society publisher raised a billing concern: their usage was inflated because some manuscripts were being uploaded more than once, either by their system retrying or by users cancelling and re-uploading.

What I did

I specified a response cache keyed on the manuscript's MD5 hash, and wrote the backend ticket as Gherkin acceptance criteria, separating the initial state, the action that triggers the problem, and the expected result. The shape of the ticket:

Given a manuscript whose MD5 hash matches a manuscript already processed for this client
When  the same file is submitted again, by a retry or a re-upload
Then  the cached result is returned
And   no new billable transaction is recorded

The result

The client's invoicing complaint went away.

The most literal demonstration I can offer of translating a business need into an epic, a story and testable acceptance criteria.