Madhav Suri

The Story

I wanted to understand what makes systems like Flink and Spark Structured Streaming dependable, so I built the core engine mechanics myself instead of wrapping an existing processor. StreamForge consumes Kafka events, partitions keyed state across workers, and coordinates the cluster over gRPC and Protobuf.

The hard part was not moving messages; it was making recovery correct. Workers checkpoint BadgerDB state and Kafka offsets at aligned barriers, stage Parquet output by checkpoint, and restore ownership after heartbeat-based failure detection. An automated chaos test kills a worker while the stream is active and reconciles committed output against deterministic ground truth.

The result is a defensible miniature stream processor with real distribution, event-time watermarks, fault-tolerant state, Prometheus/Grafana observability, and an Apache Iceberg sink that creates one time-travelable table snapshot per completed checkpoint.

Problem

Stateful stream processing must keep offsets, distributed state, and output in agreement when workers fail. If those advance independently, recovery either loses events or counts them twice. StreamForge treats all three as one checkpointed unit and makes the remaining crash-boundary behavior explicit.

Technical Depth

• Distributed engine: coordinator-managed workers with keyed gRPC/Protobuf shuffle, so every key aggregates on exactly one owner
• Fault tolerance: heartbeat detection, epoch-based reassignment, filtered state restore, and Kafka resume from checkpoint-owned offsets
• Correctness: aligned two-phase checkpoints and staged output commits verified by an automated crash reconciliation test
• Event-time processing: tumbling windows close from watermarks rather than wall-clock time, keeping replay assignments stable
• Measured limits: ~40k events/s at p99 ≤ 25 ms; the benchmark exposes the CPU/shuffle saturation knee instead of hiding it

Key Features

• Kafka source with engine-owned offsets and keyed state in BadgerDB
• Parquet output staged in S3-compatible MinIO and committed with checkpoints
• Worker crash injection plus no-loss and duplicate-window reconciliation
• Prometheus metrics for throughput, latency, checkpoints, lag, recovery, and shuffle traffic
• Provisioned Grafana dashboard for live workload and recovery monitoring
• Apache Iceberg sink with one snapshot per checkpoint and time-travel queries

Why It Matters

StreamForge demonstrates the systems work hidden behind a streaming API: coordination, partition ownership, replay-stable time semantics, durable state, and transactional output. The benchmark and failure tests make its guarantees inspectable rather than leaving them as architecture-diagram claims.

Honest scope: output is bit-exact exactly-once without failures. Under a mid-stream crash, it is effectively-once: zero lost keys and zero duplicate windows, with a small aggregate residual on windows that straddle recovery. Closing that residual requires Chandy-Lamport barrier snapshotting.

The Story

GitHub sits on top of millions of repositories — practically the entire open-source world — yet I was only ever using it the boring way: cloning code, scrolling through files, hunting through pull requests. One night, trying to ramp up on an unfamiliar codebase, I caught myself wishing I could just ask the repo what it did instead of reading it line by line.

That frustration turned into a goal: make GitHub something you could point real intelligence at — and not just my projects, but any repository on GitHub — without ever blindly trusting what an AI handed back.

So I built RepoPulse Agent. You connect a repo and it indexes the codebase, answers grounded questions with cited source context, plans changes, generates reviewable diffs, and routes everything through a human approval gate — all backed by 170+ unit tests over a deterministic core.

The result is a platform where you can interrogate any GitHub repo and trust the output: it never auto-merges code, every answer traces back to the files it came from, and each run turns into a shareable engineering report.

At its simplest, RepoPulse Agent lets you point an AI at a GitHub repository and trust what comes back. It is an AI codebase intelligence and safe change-planning platform: it indexes a repository, answers grounded questions with source context, plans code changes, generates reviewable diffs, requires human approval, and produces stakeholder-facing engineering reports — without ever automatically merging code.

Problem

AI coding tools either hallucinate answers about code they haven't read or silently apply changes nobody reviewed. RepoPulse Agent does neither: every answer cites the indexed source files it came from, and every proposed change passes a safety gate and an approve/reject workflow before anything happens.

Technical Depth

• Deterministic repository indexing first, AI second — file classification, framework detection, and architecture mapping are rule-based and unit-tested, so answers ground in facts
• Grounded Q&A with cited source context: multi-stage retrieval over the indexed tree, with confidence scores per answer
• Safety gate that classifies and refuses destructive or review-bypassing requests before any AI call
• Multi-provider AI layer (OpenAI gpt-4o-mini, Groq, Anthropic, deterministic mock) with budget guard, prompt caching, and per-call cost tracking

Key Features

• End-to-end agent workflow: Index → Ask → Plan → Diff Review → Verify → Approve → Report
• Change planner producing risk/test/rollback plans and per-file proposed diffs with approve/reject decisions
• Sandbox verification that trial-runs only human-approved patches in an isolated clone, comparing baseline vs patched results — the original repository is never modified
• Final Engineering Report summarizing the whole run (plan, diffs, approvals, verification, conclusion) with exportable Markdown
• Agent run history and audit logging of every plan, diff, refusal, and approval decision
• 170+ unit tests (Vitest) over the deterministic core: classification, retrieval, safety, sandbox, and cost controls

Why It Matters

Teams want AI leverage on unfamiliar codebases without losing review control. RepoPulse keeps humans responsible for every decision, makes weak AI output visible through verification gates, and turns each run into a shareable engineering record — the safe-workflow pattern real engineering orgs need before trusting AI with code.

The Story

RiskOS AI was built at PaySim, a fintech hackathon where every team was handed the same starting point: a raw dataset of roughly 6.3 million simulated financial transactions and one open-ended prompt — build an application from it.

Most teams reached straight for charts and dashboards. I kept circling back to a different question: what does this data actually represent? It's the bloodstream of a bank — and somewhere in those millions of rows, fraud is hiding in plain sight. I wanted to build something that mirrors how bank fraud detection really works, not just visualize it.

So instead of another analytics view, I built an end-to-end fraud operations console: a deterministic rules engine and an ML risk-scoring pipeline flag suspicious activity, and a human analyst reviews, approves, or overrides every decision.

The result is an explainable, auditable system — every score traces back to the rules and features behind it, every action is logged, and it reflects how a real bank actually defends against fraud rather than treating it as a black box.

At its simplest, RiskOS AI watches a stream of transactions and helps a fraud team decide which ones to trust. Under the hood it is a full risk orchestration system: every transaction is scored by a deterministic fraud rules engine and a Logistic Regression model, combined into a hybrid score that routes flagged cases into an analyst investigation workflow.

Problem

Financial institutions need to detect suspicious transactions without relying on fully automated black-box decisions. Rule-only systems create false positives; AI-only systems are hard to audit. RiskOS AI is designed around explainability, human-in-the-loop review, and operational safety — the system recommends, people decide.

Technical Depth

• Hybrid scoring: rule-based signals and ML predictions are combined rather than replaced — every score is traceable to the rules and features that produced it
• RBAC-protected FastAPI endpoints with distinct Analyst and Manager roles, so overrides and approvals are permission-gated
• Audit logging on every decision and workflow action — investigations are reconstructable after the fact
• Model evaluation built into the product: confusion matrix, ROC-AUC, precision/recall, and false-positive analysis views (precision 55.4%, F1 0.663 on the seeded dataset — reported honestly, tuned for recall)
• Data modeling with SQLAlchemy ORM over SQLite; 94.3% seeded automation rate for repeatable demos
• CI/CD test workflow on GitHub Actions running the 111-test Pytest suite

Key Features

• Deterministic fraud rules engine and ML risk-scoring pipeline for transaction monitoring
• Investigation workflow for flagged transactions with approve/override decisions
• Fraud analytics dashboard with KPI, trend, and review-queue views
• Notification workflow with Twilio SMS integration
• Developer console for scenario testing against the rules engine

Why It Matters

Fraud operations live or die on auditability and trust. RiskOS AI shows how a real fintech risk console balances rule-based and ML signals while keeping analysts in control, logging every decision, and gating actions behind role-based access — the kind of explainable, reviewable system financial teams can actually defend.

The Story

I didn't start D.I.Y.A — I inherited it. I was brought onto the project after an intern stepped away mid-build, and what I picked up was a half-finished codebase I hadn't written: a strong idea wrapped around real problems. The task was simple to say and hard to do — make it production-ready, and earn the team's trust while doing it.

So I started where trust is earned fastest: the truth. Before changing a line, I ran a full audit, and it surfaced things that mattered — a critical access-control hole where any logged-in user could read or write any class's data, a fresh clone that crashed on the very first setup step, raw database errors leaking to the browser, and zero tests anywhere.

Then I delivered, in priority order. I locked authorization down so professors reach only their own classes and students only the ones they joined, replaced the leaking errors with a clean handler, and got the project running from a fresh clone in one command. From there I hardened the AI: every model call now runs through a guarded pipeline with deterministic fallbacks and real spend caps, so the public demo can't burn API credits.

The result is a platform that went from inherited-and-unrunnable to deployed, tested, and cost-capped — with a one-click demo a recruiter can open and use. I earned trust the only way that lasts: by shipping something that works.

Problem

Professors drown in repetitive questions while the ones that actually need a human get buried. Fully automating answers is unsafe and unauditable; doing it all by hand doesn't scale. D.I.Y.A is built around human-in-the-loop review — the AI drafts an answer, scores its own confidence, and only escalates what it's unsure about; the professor approves, rejects, or overrides, and every AI answer stays marked "pending review" until they do.

Technical Depth

• Role-based access control enforced on every group-scoped route — professors are scoped to classes they own, students to classes they joined (this closed a critical cross-tenant data hole)
• AI workflow orchestration: each question is classified → checked for duplicates → grounded with RAG → drafted → confidence-scored → routed or escalated → recorded as a workflow item
• Retrieval-augmented generation over uploaded course documents using local 384-dim embeddings (all-MiniLM-L6-v2) — no external vector database
• Defense-in-depth AI cost controls: a master enable switch, daily/monthly USD budget caps computed from a usage ledger, and per-user/per-IP rate caps — the deployed demo is bounded to ~$2/month
• Observability: every model call logs latency, tokens, and estimated cost to an admin dashboard with live spend-vs-cap
• 42-test node:test suite + GitHub Actions CI; a central error handler that never leaks stack traces; graceful keyless fallback so the app still works with no API key

Key Features

• Student forum with AI-drafted answers held for professor review
• Professor workflow queue surfacing only escalated, low-confidence questions with their scores
• Confusion-cluster detection with interventions and tracked effectiveness
• Approved-answer reuse library that auto-serves future duplicates
• RAG knowledge base: upload PDFs/DOCX/notes; answers cite the source file
• AI self-check grading and a live observability / cost dashboard

Why It Matters

D.I.Y.A is the pattern real teams need before they trust AI in production: human-in-the-loop review, role-based access, full auditability, and hard cost governance. But the part I'm proudest of isn't a feature — it's that I took over someone else's unfinished project, found the uncomfortable problems first, and turned it into something live and dependable. That's how you earn trust on a team.