Founder & Engineer, Auric — the continuity layer for AI-assisted work
CS @ CVR College of Engineering · AI & Data Science @ BITS Pilani (in parallel) · Hyderabad, India
I build systems, then try hard to prove they're wrong.
Most of what I make lives at the boundary between agentic AI and systems that have to be measured — inference engines, numerical solvers, state infrastructure. The through-line isn't a language or a stack. It's that I don't trust my own output until something independent says it's right: a validation benchmark, a convergence sweep, a deterministic grader.
Long-term I'm heading toward agentic systems that reason over financial data across time.
Auric — continuity for AI-assisted work
Every AI session starts in the dark. Your assistant meets your project for the first time, again — the goal, the constraints, the decisions you already made, what you'd ruled out, all gone the moment the window closed.
Auric keeps the state of the work, not the transcript. A typed continuity graph, read over MCP, that rehydrates in under a second across Claude, Cursor, and Codex.
Every other AI memory layer remembers what was said, locked inside one tool. Work runs on state: what you're trying to prove, what's blocking you, what's next.
Git tells you what changed. Auric tells you why it changed.
Private beta live · Local-first, append-only, no AI in the read path, nothing phoned home.
What I've shipped on it
| ADR-0027 | Event-stream compaction with projection-safe pinning — bounded the last two unbounded tables with row-identical cold-archive |
| ADR-0031 | Fixed a dead first-run in the invite flow — shipped tarball + license key path |
| MCP | First-class Cursor registration, plus a CI guard so shipped example configs can't rot |
| Engine | Architecture frozen under ADR-0019 · 21 ADRs · PRD v3.1 |
Production infrastructure built alongside it: NextAuth v5 + Google OAuth + WebAuthn, TimescaleDB hypertables, OpenTelemetry → Sentry → Grafana, staging/prod CD pipelines, Storybook with PR previews.
🚀 solid-rocket-grain-reverse-design · COD 0.967 vs the paper's 0.952
Reverse-designs a 2D solid-propellant rocket grain from a target chamber-pressure curve. Classical grain design is forward and parametric — pick a star or wagon-wheel template, tune its handful of dimensions, and the template bounds every shape you can ever reach.
This inverts it. The grain shape isn't parameterised at all — it's the zero level set of a phase field emitted by an 81-parameter neural network, and a genetic algorithm evolves the weights. No template, so no template to be trapped by. Burn-back solves as a nonlinear diffusion–eikonal PDE on a fixed mesh (φ-PEF), with the mesh and diffusion skeleton assembled once and reused across ~10⁴ GA evaluations — the single reason the search is tractable.
Independent Python reimplementation of Li et al., Aerospace 2022, 9(10), 552. It reproduces the paper and slightly exceeds its reported fit.
The part I'm actually proud of — how it was built, and the number I retracted
Seven stages, each with a hard quantitative gate that had to pass before the next stage was written. Every gate is a checked-in, re-runnable script — verify_stage*.py is the executable specification.
| Stage | Gate | Result |
|---|---|---|
| 0 · Environment | scikit-fem Poisson < 1e-6 | 4.4e-16 ✅ |
| 2d · φ-PEF validation | vs body-fitted PEF < 1% nodal | 0.63% max, 0.37% L2 ✅ |
| 4 · Pre-training | MSE ~1e-7…1e-8 (paper: 3.89e-9) | 5.998e-9 ✅ |
| 6 · GA loop | monotone best-fitness; tube→star morphology | ✅ |
Stage 2d is the one that matters: I validated the solver against an independent body-fitted reference before trusting it anywhere else.
Then, partway in, the fit looked stuck below the paper at ~0.89 and appeared to plateau. That turned out to be a metric artifact, not a worse grain — COD is sensitive to interpolation node count, because sparse nodes over-weight a small late-web residual at the curve overlap edge. Re-scoring the same saved winner across node counts: 0.891 (n=20) → 0.947 (n=80) → 0.960 (n=200) → 0.967 (converged, n≥1600). I published the convergence sweep and retracted an earlier flattering number from my working log.
I also declined to complete the paper's second benchmark. Its star grain isn't recoverable from the published figure — the readable dimensions underdetermine it, and pinning burnout web forces the initial perimeter 50% too high. That's a target-acquisition limit, not a method failure, and guessing a textbook star would have silently substituted a different grain. The contradiction is demonstrated in code rather than asserted.
I'd rather publish the boring correct number than the flattering one.
Python · scikit-fem · pymoo · numerical PDEs · level-set methods · genetic algorithms
🎙 asr-lab · four local ASR engines, one harness
whisper.cpp, faster-whisper, Parakeet TDT 0.6B and Canary-Qwen 2.5B — four genuinely different runtimes (prebuilt cuBLAS binary, CTranslate2, sherpa-onnx, NeMo-inside-WSL2) each running as a persistent server behind one OpenAI-compatible /v1/audio/transcriptions endpoint, so a single benchmark harness and a single web UI drive all four identically. Plus live dictation with Silero VAD segmentation, in the terminal and the browser.
| Engine | Cold-start | Warm latency | RTFx | WER | Peak RSS | Peak VRAM |
|---|---|---|---|---|---|---|
| whisper.cpp | 5.4 s | 1159 ms | 2.5× | 7.6% | 430 MB | +992 MiB |
| faster-whisper | 24.1 s | 537 ms | 5.2× | 8.1% | 821 MB | +2308 MiB |
| parakeet | 3.4 s | 229 ms | 10.0× | 13.9% | 949 MB | +0 MiB |
| canary-qwen | 65.4 s | 446 ms | 5.9× | 10.3% | n/a (WSL) | +5153 MiB |
The finding: Parakeet runs on CPU and still beats every GPU engine on speed — 229 ms, 10× real-time. But its 13.9% WER is almost entirely developer vocabulary (kubectl → "QBTL", docker → "Duck or"), which makes it the wrong default for a coding assistant despite the speed. Fast, and wrong about the words you actually say.
Every number was measured on a published reference machine, spec'd down to the CUDA runtime and driver version. Benchmarks without that are opinions.
FastAPI · ONNX Runtime · CTranslate2 · NeMo · CUDA · WSL2
🔧 NetArena · deterministic SRE environment for agent evaluation
Built for the OpenEnv / Meta PyTorch Hackathon. Drops an AI agent into a simulated Linux terminal and gives it three production outages of escalating difficulty — dead Nginx, a zombie process holding port 8080, a full disk that took PostgreSQL down with it.
No LLM judges. Every command is intercepted by a Python state machine — no real syscall ever executes — and reward is computed deterministically from final system state. Same run, same score, every time, on any machine. Scoring an agent with another model is how you get a benchmark that measures the judge.
FastAPI · Pydantic · Docker · agent evaluation · RL environments
Agent memory & continuity. State, not transcript. A bigger context window just hands the model more to re-read — the interesting problem is reconstructing what the work actually is from the evidence, and being able to prove the reconstruction is faithful. This is what Auric is.
Evaluation you can trust. Deterministic graders over LLM judges. Published reference machines over "it felt faster." Independent validation before you believe your own solver. Most of what I build ends up being an argument about measurement.
Inverse problems & optimization. Searching a space that isn't parameterised in advance — evolving a representation instead of tuning a template.
Agentic AI × quantitative finance. Where I want to end up: systems that reason over financial data across time, not just at a point in it.
A rule I hold myself to: no AI-generated code I couldn't have written, and no debugging by pasting an error and waiting. AI is for explaining a concept after I've struggled with it, and for reviewing what I already wrote. The leverage is real; the skill gap it can hide is also real.
Always up for talking to people building agent infrastructure, developer tooling, or anything in the ML-systems × quant-finance overlap.
auric.cx · LinkedIn · muzaffarjune@gmail.com
Built by someone who got tired of starting over.