Hi, I'm

Srikanth K N

3rd Year CS Student (2024–28).

Backend-focused builder.

Open Source Contributor.

3rd year Computer Science student building backend-focused projects—FastAPI services, async workers, databases, and rule engines—plus open-source contributions to OpenMS.

View Projects Resume GitHub LinkedIn

01 — About

Building systems that ship

I'm a 3rd year B.Tech Computer Science student (2024–28 batch) who spends most of my time in backend code—designing APIs, writing tests, and figuring out why things are slow. I'm not building coursework demos that never leave localhost. My personal projects ship with CI, deployment configs, and audit trails because that's what production actually looks like.

My recent projects are full-stack, but the engineering depth is backend: FastAPI services, async workers, Postgres schemas, provider abstractions, and CI pipelines. I built an LLM safety gateway with 1,667 guardrail rules and an evaluation pipeline with an 80% CI pass-rate gate—each with a React UI, but the core work is the API layer. Before that, I contributed C++ and pyOpenMS bindings to OpenMS, where eliminating a Python↔C++ copy delivered ~30× speedup on chromatogram peak access.

What I enjoy building

REST APIs, async job pipelines, databases, provider abstractions, rule engines, and production plumbing—logging, audit trails, CI gates, and regression tests.

Why open source

OpenMS taught me how real engineering teams review code, argue about API design, and catch regressions before they hit users. Merged PRs with maintainer feedback are worth more than any course project grade.

Long-term direction

Backend engineering internships and roles—distributed systems, platform APIs, performance-critical services, and the infrastructure between a client request and a server response.

02 — Projects

Featured work

Full-stack apps with backend-heavy architecture—APIs, workers, databases, React UIs, deployed and tested end to end.

Guardrail Gateway

What happens between a user's prompt and the model's answer—and what gets logged after.

Full-stack LLM safety gateway (FastAPI + React) that scans prompts and responses, routes to multiple providers, redacts blocked output, and persists audit trails in SQLite. The core engineering is the API gateway, rule engine, and logging layer.

Live Demo GitHub

1,667

Guardrail rules

305

Test cases

755

Input rules

912

Output rules

Providers

Architecture

Browser hits Vercel; /api/* reverse-proxies to Render. The gateway runs input rules + ML injection detection, calls the configured provider, scans output, redacts on block, and writes structured logs to SQLite.

Client

Vercel

FastAPI Gateway

Input Scanner

ML Classifier

Rule Engine

Provider Router

Output Scanner

Audit Logs

Prompt flow

01POST /gateway/chat with user prompt
02Phrase + regex rules on input (allow / warn / block)
03ML injection classifier scores adversarial patterns
04Block stops request; warn/allow proceeds to provider

Response flow

01Provider returns model text (OpenAI, Gemini, Grok, or Mock)
02Output rule engine scans response content
03Block redacts response_text before client delivery
04Full request metadata + rule hits stored in SQLite

FastAPI

React

SQLite

Gunicorn

scikit-learn

Vercel

Render

Challenges solved

Designing a rule engine that handles 1,667 rules without latency spikes on every request
Balancing ML classifier accuracy with deterministic phrase/regex fallbacks
Unifying four provider APIs behind one adapter interface with consistent error handling
Shipping audit logs useful for debugging without leaking sensitive prompt content

Engineering decisions

SQLite for zero-ops persistence on Render free tier—structured enough for filters and stats
Vercel reverse proxy so the frontend never exposes the Render API origin directly
Mock provider as default for demos—predictable output without API keys
305 pytest cases including adversarial regression strings to prevent rule-engine drift

Lessons learned

Safety infrastructure is mostly plumbing: scan, route, log, redact—get the audit trail right first
Provider abstraction pays off when you need to swap models without touching gateway logic
Regression tests for blocked phrases matter more than UI polish for a gateway product

Screenshots

Guardrail Gateway overview dashboard with rule counts and decision stats

Chat flow showing input scan, LLM call, and output redaction

Rules engine test scan for input and output text

Audit logs with filters and bar-chart statistics

Frontend: Vercel · API: Render · CI: GitHub Actions

LLM Eval Pipeline

Upload test cases, evaluate models, and fail CI when quality drops.

Full-stack LLM evaluation platform (FastAPI + React) with async background jobs, Postgres persistence, stored run history, and an 80% pass-rate CI gate. Built for repeatable prompt and model quality checks before shipping changes.

Live Demo GitHub

80%

CI pass threshold

Backend tests

Multiple

Models supported

Async

Job model

Architecture

CSV datasets upload to Postgres. Eval jobs enqueue async workers that call provider adapters row-by-row, score outputs, persist results, and expose pass-rate for CI gating.

React UI

FastAPI

Async Workers

Postgres

Scoring Engine

Provider Layer

CI Gate

Evaluation pipeline

01Upload CSV (input, expected_output, optional category)
02Configure prompt template with {input} placeholder
03Background job runs one LLM call per row with progress polling
04Scorer compares model output to expected; stores per-case results

CI quality gate

01GitHub Actions triggers eval against sample dataset
02Pass rate computed across all scored rows
03Build fails if pass rate drops below 80% threshold
04Stored runs let you track pass-rate changes across deploys

FastAPI

React

PostgreSQL

Neon

Async workers

Gemini

Vercel

Render

Challenges solved

LLM calls are slow—blocking HTTP would timeout; needed async jobs with polling
Provider abstraction across mock (CI/local), Gemini, and OpenAI-compatible models
Scoring heuristics that work across varied expected outputs without brittle exact match
Postgres on Neon with SQLite fallback for local dev parity

Engineering decisions

mock-model-v1 for CI and local dev—no API keys, deterministic substring matching
Job status endpoint with progress percentage for long-running evals
80% pass-rate gate as a simple, explainable quality bar for CI
Bundled sample CSV so new users can run an eval in under a minute

Lessons learned

Eval infrastructure is a data pipeline problem—persist everything, compare over time
Async workers are non-negotiable when each row costs an LLM round-trip
A single pass-rate number is enough to gate CI if your test set is curated well

Screenshots

LLM Eval Pipeline overview with run history

Eval run configuration with prompt templates

Frontend: Vercel · API + workers: Render · Database: Neon Postgres · CI: GitHub Actions

03 — Open Source

Contributions

Merged work on OpenMS—C++ core, nanobind Python bindings, and performance-critical data paths used in production proteomics pipelines.

OpenMS

Merged

2025

Extract reusable SequenceCoverage API and add C++ & pyOpenMS tests

#8728

Refactored sequence coverage logic into a reusable C++ API with unit tests in both native and Python bindings. Addressed coverage computation issues used by downstream proteomics tools.

Impact

Unblocked EasyPQP regression fixes; established test coverage for a core algorithm path used across pyOpenMS workflows.

C++

pyOpenMS

pytest

CMake

OpenMS

30× speedup

2025

Add zero-copy NumPy view for MSChromatogram.get_peaks_struct()

#8825

Implemented nanobind-based Python bindings that expose chromatogram peak data as zero-copy NumPy arrays, eliminating expensive Python↔C++ copies on large mass-spec datasets.

Impact

~30× speedup for Python consumers reading chromatogram peaks—critical for high-throughput proteomics pipelines.

C++

nanobind

NumPy

pyOpenMS

OpenMS

Merged

2025

pyopenms: add zero-copy get_peaks_struct() for Mobilogram with tests

#8842

Extended the zero-copy peaks pattern to Mobilogram data structures with full pyOpenMS test coverage, keeping API consistency across chromatogram and mobilogram types.

Impact

Consistent high-performance data access across OpenMS Python bindings; reduces memory pressure on large mobilogram datasets.

C++

nanobind

NumPy

pyOpenMS

pytest

OpenMS / EasyPQP

Bug discovery

2025

EasyPQP regression discovery via SequenceCoverage investigation

#6240

Identified a sequence coverage regression (issue #6240) while building reusable coverage APIs—root-caused incorrect behavior affecting EasyPQP spectral library generation.

Impact

Surfaced a production-impacting bug before broader release; drove the API refactor that fixed the underlying coverage computation.

C++

Proteomics

Debugging

Regression analysis

04 — Skills

Technical stack

Languages

Python

C++

TypeScript

JavaScript

SQL

Bash

Frameworks

FastAPI

React

Next.js

Vite

pytest

Backend

REST APIs

Async workers

Provider abstraction

Rule engines

Request logging

AI

LLM gateways

Prompt evaluation

ML classifiers

Multi-provider routing

CI quality gates

Databases

PostgreSQL

SQLite

Neon

Schema design

DevOps

GitHub Actions

gunicorn

Reverse proxies

render.yaml

Cloud

Vercel

Render

Environment config

Serverless deploy

Core CS

Data structures

Algorithms

Systems design

Testing

Performance optimization

05 — Experience

Where I've built

Open Source Contributor

2025 — Present

OpenMS

Contributing C++ and pyOpenMS improvements to a major open-source proteomics framework. Work spans performance-critical Python bindings, API design, and regression discovery in production tooling paths.

3 merged PRs to OpenMS/main including zero-copy NumPy bindings
~30× speedup for chromatogram peak access in Python consumers
Discovered and drove fix for EasyPQP sequence coverage regression
Added C++ and pyOpenMS test coverage for core coverage algorithms

C++

nanobind

Python

CMake

pytest

Git

PR #8728 — SequenceCoverage API PR #8825 — Zero-copy chromatogram peaks PR #8842 — Zero-copy mobilogram peaks

Student Developer

2025 — Present

Personal Projects

Independently designed and shipped two full-stack apps outside of coursework—backend-heavy architecture with FastAPI APIs, async workers, Postgres/SQLite persistence, provider routing, and CI quality gates.

Guardrail Gateway: 1,667 rules, 305 backend tests, 4 providers, SQLite audit logs
LLM Eval Pipeline: async eval jobs, Postgres on Neon, 38 backend tests, 80% CI gate
Deployed frontends on Vercel, APIs on Render, CI via GitHub Actions

FastAPI

React

PostgreSQL

SQLite

LLM APIs

Vercel

Render

guardrail-gateway llm-eval-pipeline

06 — Achievements

Highlights

3 Merged OpenMS PRs

Shipped C++ and pyOpenMS contributions to a 1k+ star proteomics framework, including API refactors and performance-critical bindings.

30× Performance Optimization

Zero-copy NumPy views for chromatogram peaks—eliminated Python↔C++ copy overhead on large mass-spec datasets.

LeetCode Contest Rating 1500

Competitive programming foundation in algorithms, data structures, and time-complexity reasoning.

GSoC Applicant

Applied to Google Summer of Code with OpenMS—demonstrating sustained open-source commitment.

EasyPQP Regression Discovery

Identified sequence coverage regression (issue #6240) affecting spectral library generation in production proteomics tooling.

Shipped Production Apps

Built and deployed two full-stack apps—LLM safety gateway and eval pipeline—with FastAPI backends, React UIs, CI, and live demos.

GitHub

Open source activity

Live data from @Srikanthkn0—repositories, recent commits, and contribution history.

Contribution graph

Profile

Srikanth K Nattudurai

B.Tech CSE student | Open-source contributor | C++ & systems programming enthusiast | Aspiring HFT engineer

9 repos0 followers

Repositories

srikanth-portfolio

Personal portfolio — backend engineering, AI infrastructure, open source

TypeScript

llm-eval-pipeline

CSV-based LLM eval platform with async jobs, Postgres persistence, and CI pass-rate gate. FastAPI + React.

Python

guardrail-gateway

LLM safety gateway with input/output guardrails, provider routing, and request logging

Python