Keshav

I build backends that have to be right, and run experiments that are allowed to be wrong.

Selected work

01 — 04

03 · Independent

ReviewGraph

A pull-request reviewer that reads the repository as a graph before it reads the diff, and is not allowed to say anything it can't point at.

caller · d1 · touches userscaller · d2PUT /users/:id · d3 · no guardsoverridden interface methodcovering testpermissionService.check — removed (base graph)AuthService.authorize− permissionService.check(...)+ user.role === 'admin'0.993RISK · CRITICAL · 3 RULES× ReportService — must not appear× format.ts#authorizeHeader — must not appear
View case study

All 13 projects, including Ferite, FRONTIER and the client work →

Research

2 programs · 21 experiments recorded

Featured · Research

Does choosing which attempt runs next get more independently verified results out of a fixed compute budget? Ten experiments in; several said no.

Model promised
99.5%
Cases run, k
1 of 199
Fitted wall-time
7.8%
Fail-fast verification, per failing candidate. The charge counts cases run, so the model promises 1 − k/199. The clock pays 120.5 ms before the first case and 0.0516 ms per case after it.

exp-009 as an alignment chart: for each number of cases run before the first failure, the saving the cost model promised against the wall-time saving fitted from the measurements.

Open questions

  1. FRONTIERDoes deciding which attempt runs next get more independently verified results out of a fixed compute budget?
  2. Temporal ComputeWhat computation is still useful when its value depends on when it finishes?

Research log · latest entries

  1. FRONTIER · exp-006The price of a strong verifiermixed
  2. FRONTIER · exp-007Tasks with dependenciessupported
  3. FRONTIER · exp-008Fail-fast chargingsupported
  4. FRONTIER · exp-009Is the modelled saving real?refuted
  5. FRONTIER · exp-000Posterior allocation in simulationrefuted
  6. FRONTIER · exp-001Why it lost: misleading hints, correlation, verifier noiserefuted

The full research log →

Writing

5 essays

  1. How a GST Returns Dashboard Became a Sub-15ms ReadGST return status queries went from 3,000ms+ to sub-15ms at peak load by reading a precomputed projection that filing writers keep fresh through domain events. Requirements, options and the update path.
  2. The Redis Namespace Bug Behind a Broken Processing PipelineTwo services used the same BullMQ queue name under different Redis key prefixes, so every OCR extraction result was enqueued where nothing would ever read it. An incident write-up.
  3. When HTTP 200 Still Means Your Integration FailedFour ways a GST portal integration lost or corrupted data while every request succeeded — a case-sensitive parameter, an unechoed field, a delegated rule and an over-broad sum — and how each was closed.
  4. Why Long-Running Workflow Updates Moved to a Durable SSE StreamReplacing several ephemeral SSE channels with one table-backed notification stream — 25-second heartbeats, Last-Event-ID replay and runId correlation across async workflows. A walkthrough from the wire up.
  5. Why RAG Shouldn't Retrieve EverythingIn BARA, retrieval is three separate decisions — whether, from where and how much, then which chunks — made by deterministic rules before a vector is ever compared. A research note with the code.