Overview

Over around eight months of engineering, I worked across key initiatives: I architected and built HireCraft, a closed-loop tech job discovery and AI resume tailoring platform with Next.js 16, pgvector 768d semantic search, and truth-preserving Google XYZ metrics; I engineered the Cloud Data Warehouse Comparison & Multi-Engine OLAP Benchmarking Suite evaluating Snowflake, BigQuery, AWS Redshift Serverless, Databricks SQL, ClickHouse, and DuckDB across 2M-row analytical workloads with sqlglot AST dialect validation and FinOps cost guardrails; I built this portfolio website and AI assistant with hardened in-memory RAG and prompt injection guardrails; I architected and built the Autonomous Cloud SRE Copilot on GCP with Vertex AI multi-agent incident triage and Terraform IaC; I built DatasetRadar, a complete data-intelligence product from technical spec through to a running instance with a full review UI; I engineered the LangGraph Playground monorepo for developing and deploying stateful multi-actor agent workflows; I engineered a production automation that watches for pipeline failures on Factly’s public-data repo and opens fix PRs unattended; and I authored a modular ETL skill suite and tooling investigations.

Cloud Data Warehouse Comparison & Multi-Engine OLAP Benchmarking Suite

A rigorous comparative evaluation framework, automated Python benchmarking harness, and FinOps cost-governance playbook engineered for six modern analytical OLAP engines: Snowflake, Google BigQuery, AWS Redshift Serverless, Databricks SQL (Photon), ClickHouse, and DuckDB.

Standardized 5-Archetype Analytical Benchmark (Q1–Q5 on 2M NYC Taxi Rows). Engineered a unified benchmark workload (NYC TLC Yellow Taxi, 2,000,000 rows) evaluating cold-cache vs. warm-cache execution latencies (ms), cache speedup ratios, bytes scanned (MB), and normalized cost-per-1,000 queries ($) across five canonical OLAP query archetypes:

• Q1 — High-Selectivity Scan & Multi-Predicate Filter: Evaluates columnar projection, predicate pushdown, and micro-partition/granule pruning.
• Q2 — Multi-Column Group-By Aggregation: Tests hash aggregation throughput across payment and passenger dimensions.
• Q3 — Time-Series Hourly Rollup (DATE_TRUNC + EXTRACT): Benchmarks temporal bucketing and date-partitioned scans.
• Q4 — Two-Table Star Join: Evaluates hash join and broadcast join execution between fact (yellow_trips) and dimension (taxi_zones) tables.
• Q5 — Window Function Top-N Ranking (ROW_NUMBER() OVER PARTITION BY): Stress-tests partitioned sorting and analytical windowing.

Unified Python Benchmarking Harness (runner_base.py, run_all_benchmarks.py). Designed an extensible, object-oriented execution harness using Python dataclasses (QueryMetric, EngineBenchmarkResult) that executes live vector-SIMD DuckDB baselines (~14–35ms warm latency across 2M rows at $0 cost), pairs them with calibrated multi-warehouse telemetry, and exports structured benchmark_summary.json and CSV artifacts.

Multi-Dialect SQL AST Validation (sqlglot) & FinOps Guardrail CI. Authored an automated Pytest + sqlglot Abstract Syntax Tree (AST) verification suite (tests/test_sql_dialects.py) that parses native SQL dialects (bigquery, snowflake, redshift, clickhouse) without requiring live paid cloud credentials on every commit, while programmatically enforcing FinOps safety guardrails:

• Snowflake: Enforces WAREHOUSE_SIZE = 'XSMALL', AUTO_SUSPEND = 60, INITIALLY_SUSPENDED = TRUE, and USE_CACHED_RESULT = FALSE for accurate cold-run telemetry.
• Google BigQuery: Enforces partition/cluster pruning and maximum_bytes_billed caps (1 GB limit) compatible with the cardless BigQuery Sandbox.
• AWS Redshift Serverless: Enforces Base RPU = 8 workgroup bounds, daily RPU-hour quotas, and enable_result_cache_for_session TO off.
• ClickHouse: Enforces MergeTree / ReplacingMergeTree ordering keys and SIMD-friendly low-cardinality types.
• DuckDB: Enforces bounded in-process execution (memory_limit = '4GB', threads = 4).

Data Authenticity, ACID & Governance Architecture. Documented deep-dive architectural analyses (docs/authenticity_and_governance.md, docs/warehouse_comparison.md) comparing constraint enforcement (informational PK/UNIQUE metadata in Snowflake/BigQuery/Redshift vs. strict enforcement in DuckDB), Time Travel retention windows (Snowflake 90-day + 7-day Fail-safe, BigQuery 7-day FOR SYSTEM_TIME AS OF, Databricks Delta Log VERSION AS OF), native column-level lineage (Unity Catalog, Snowflake Horizon), and open table formats (Apache Iceberg, Delta Lake).

Tech Stack

• Data Warehouses & OLAP Engines: Snowflake, Google BigQuery, AWS Redshift Serverless, Databricks SQL (Photon / Delta Lake), ClickHouse, DuckDB
• Benchmark Harness & Validation: Python 3.12, sqlglot (Multi-dialect SQL AST parser), DuckDB Python API, Pytest, Ruff
• CI/CD & Governance: GitHub Actions (duckdb_benchmark_ci.yml publishing live telemetry to $GITHUB_STEP_SUMMARY, lint_sql.yml, access-guard.yml), Pre-commit & Pre-push Git Hooks

View GitHub Repository →

HireCraft — Closed-Loop Technical Job Discovery & AI Resume Crafter

A production-grade, closed-loop technical job discovery and AI resume tailoring platform engineered with Next.js 16 (App Router), React 19, Python FastAPI, and PostgreSQL with pgvector. It eliminates the fragmented, open-loop job application process by integrating direct ATS ingestion, 768-dimensional dense vector matching, truth-preserving Google XYZ metric generation, and sub-second ATS-compliant PDF generation.

Direct ATS Ingestion & Normalization. Built automated data collectors that scrape and normalize verified engineering roles directly from company career APIs (Greenhouse, Lever, Ashby) with strict Pydantic schemas, bypassing noisy third-party job aggregators.

768d Semantic Search with pgvector. Solved the severe recall limitations of brittle keyword regex filtering by projecting candidate master profiles and job requirements into a 768-dimensional dense vector space using pgvector in PostgreSQL. Executing Cosine Distance queries (ORDER BY embedding <=> target_vector) directly in relational SQL cut semantic query latencies from 1.2s to <18ms, while maintaining ACID compliance and delivering 90% lower operational costs compared to dedicated vector databases (Pinecone/Milvus).

Truth-Preserving AI & Google XYZ Metrics. Standard LLM prompts hallucinate fake qualifications or exaggerate accomplishments. I formulated an architectural invariant: Truth-Preserving Generation. The model is constrained against introducing unpossessed technologies or altering verified chronologies. It refactors achievements strictly into the Google XYZ framework: "Accomplished [X], as measured by [Y], by doing [Z]". When candidate bullets lack measurable outcomes, the system activates an interactive prompt in the UI (UserFactInputs) soliciting real production metrics before running optimization.

FastAPI AI Gateway & Concurrency Architecture. Resolved a critical 10-second FastAPI event-loop freeze caused by synchronous blocking Gemini calls by decoupling inference into an asynchronous threadpool executor (run_in_executor) with strict 4.0s timeouts. Engineered an intelligent heuristic fallback engine executing in <20ms if the LLM throttles or times out, guaranteeing zero UI hang and sub-second response times.

Performance & ATS Print Compliance.

• Route Prefetching: Reduced client-side navigation latency by 97% (1.8s down to <45ms) by replacing imperative routing with Next.js declarative <Link prefetch={true}> and React.memo capacity budgeting.
• Dynamic Capacity Budgeting: Engineered mathematical section-budgeting formulas preventing orphaned headings across Page 1/2 with manual page assignment overrides.
• ATS Machine Compliance: Implemented clean single-column print stylesheets (@media print) with break-inside: avoid, delivering a verified 96.4% ATS machine parse rate.
• NIST-Compliant Security: Memory-hard user authentication using native Node.js crypto.scrypt (salt + 64-byte key) and constant-time comparison (crypto.timingSafeEqual), eliminating fragile C++ binary compilation dependencies.
• Serverless FinOps: Deployed on Google Cloud Run (asia-south1) with Cloudflare edge TLS 1.3 / HTTP/3 routing, bypassing $25/mo GCP Load Balancer costs to maintain a $0–$20/mo operating baseline.

Tech Stack

• Frontend & Full-Stack: Next.js 16 (App Router), React 19, TypeScript 5.x, Tailwind CSS, Lucide Icons
• AI Gateway & Models: Python 3.12, FastAPI, Uvicorn, Google Gemini 1.5 Flash & Pro, Google XYZ Heuristic Engine
• Database & Vectors: PostgreSQL 16, pgvector (768-dimensional dense embeddings, Cosine Distance indexing)
• Security & Cloud: Node.js native crypto.scrypt, Google Cloud Run, Cloudflare Edge TLS 1.3 / HTTP/3

Portfolio Website & AI Assistant — In-Memory RAG & Guardrails

A deployed full-stack project demonstrating production-grade conversational AI safety without external vector database overhead.

In-Memory RAG Pipeline. Instead of passing the entire knowledge base to the model or hosting a separate vector database, an in-memory BM25 index scores and retrieves the top relevant chunks in RAM in under 0.1ms. This keeps context minimal, eliminates hallucination, and cuts token costs.

Prompt Injection Defenses.

• Context Isolation: Retrieved chunks are wrapped as untrusted data, preventing indirect injection attacks.
• Output Inspection (checkReply): Independent deterministic validation catches system prompt leaks and refusal slips before anything reaches the browser.
• History Sanitization: Blocked replies are never saved to conversation history, preventing multi-turn context poisoning.
• Multi-Model Routing: Automatic failover between OpenAI (gpt-6-astra) and Gemini (gemini-3.1-flash-lite).

Tech Stack

• RAG & Search: In-Memory BM25 & TF-IDF Vector Indexing (< 0.1ms RAM retrieval)
• Full-Stack: Astro, TypeScript, Vercel Serverless Functions, Content Collections
• AI Models: OpenAI API, Google Gemini API (with automatic fallback)
• Security: Deterministic Output Guardrails (checkReply), Sliding-Window Rate Limiting

Try the AI Assistant →

Autonomous Cloud SRE Copilot & Multi-Agent Incident Investigator on GCP

A production-grade cloud-native SRE copilot and autonomous multi-agent incident investigator engineered on Google Cloud Platform (GCP). When system anomalies or 5xx spikes trigger across workloads, the copilot consumes real-time log alerts via Cloud Pub/Sub, executes multi-turn autonomous diagnostics using Vertex AI Gemini function calling, isolates root causes, and executes guardrailed zero-downtime remediations.

Event-driven observability pipeline. I architected the ingestion stream using GCP native services:

• Cloud Logging & Log Router Sink: Ingests unhandled exception traces and 5xx errors (severity ≥ ERROR) from Cloud Run microservices.
• Cloud Pub/Sub & Dead-Letter Queue (DLQ): Delivers incident payloads reliably to the SRE copilot webhook via push subscriptions, backed by a dead-letter queue for replayability.
• Incident State Ledger: Records incident lifecycles (DETECTION → TRIAGING → MITIGATION → RESOLVED) in Cloud Firestore and archives post-mortems in Google Cloud Storage.

Agentic multi-tool diagnostic protocol. Instead of static alerts or one-shot prompting, the Gemini 1.5 agent autonomously invokes domain-specific GCP diagnostic tools until root cause is proven:

• query_cloud_logging: Extracts stack traces, error payloads, and correlation trace IDs within the incident time window.
• get_metric_timeseries: Queries Cloud Monitoring for p50/p95/p99 latency spikes, 5xx error percentages, CPU throttling, and memory saturation.
• query_log_analytics: Executes BigQuery SQL aggregations across service revisions and deployments to pinpoint regressions.
• inspect_gcp_resource: Audits live Cloud Run configurations, environment variables, VPC connectors, and IAM role bindings.
• generate_remediation_plan: Proposes validated gcloud mitigation commands with rollback paths.

Interactive chaos engineering simulator. Includes a 1-click failure injector simulating 4 realistic production GCP outages:

1. Cloud Run 500 Outage: Revision rollout missing Serverless VPC Access connector → auto-mitigated via zero-downtime traffic rollback (gcloud run services update-traffic --to-revisions=STABLE=100).
2. IAM Privilege Drop: Missing roles/storage.objectViewer on GCS bucket → root cause identified and IAM policy binding proposed.
3. Container Memory Saturation: Out-of-memory exit code 137 (OOMKilled) → agent identifies memory threshold breach and scales container memory limit.
4. Cloud SQL Connection Starvation: High p99 latency caused by connection pool saturation → diagnosed and PgBouncer/connection tuning suggested.

FinOps scale-to-zero economics. Explicitly engineered to run at $0 standby cost (100% within GCP Free Tier) using scale-to-zero serverless compute (Cloud Run min-instances=0), serverless Pub/Sub messaging, and managed free-tier databases (Firestore, BigQuery).

Codified via Modular Terraform (IaC). 100% codified using reusable Terraform modules (iam, messaging, storage_data, observability, cloud_run) with least-privilege IAM bindings (sre-copilot-sa) and automated GitHub Actions CI/CD validation.

Command Center Dashboard. Built a real-time FastAPI dashboard with Server-Sent Events (SSE) streaming the agent’s thought chain, diagnostic tool latency, telemetry metrics, and rendered Markdown post-mortem RCAs.

Tech Stack

• Cloud Platform: Google Cloud Platform (Cloud Run, Vertex AI Gemini 1.5, Cloud Logging, Cloud Monitoring, Cloud Pub/Sub, Cloud Firestore, BigQuery Log Analytics, Cloud Storage, Secret Manager, Cloud IAM)
• Infrastructure as Code: Terraform 1.7+ (Modular architecture, least-privilege IAM, scale-to-zero)
• Backend & APIs: Python 3.12, FastAPI, Pydantic, Server-Sent Events (SSE), Docker
• Agentic AI: Vertex AI Gemini Multi-Turn Tool Calling, Autonomous Diagnostics, Guardrailed Human-in-the-Loop Rollbacks

View GitHub Repository →

DatasetRadar — Dataset Intelligence Platform

I built DatasetRadar to keep an eye on news and journal websites and automatically spot which public datasets, surveys, or reports each new article mentions — no manual tagging required. The payoff: a live, searchable map of who’s citing which dataset, where, and how often.

Planning and architecture. Before writing any code, I did a full design walkthrough of the app end to end, then wrote a detailed technical architecture document covering the database design, the API, the crawling rules, and a short list of open questions I flagged for engineering sign-off.

The finished product. I shipped a complete, working app, not a demo: a React frontend talking to a FastAPI backend, background workers that scrape sites on a schedule, and a database with vector search built in for finding related datasets. I set up a self-hosted AI model that reads every article and figures out which datasets it’s talking about — even when the wording is different — so the same dataset never gets counted twice under two different names.

Human-in-the-loop by design. I designed it so not every match is treated the same: confident matches get accepted automatically, unsure ones wait in a review queue for a person to check (with the option to ask the AI for a second opinion), and weak guesses get dropped entirely. I built the app to cover a trending-datasets dashboard, an exportable usage report, per-site health monitoring, a simple screen for managing which sites get watched, and a master list of all known datasets.

Ask — retrieval-augmented Q&A. I added an Ask feature: type a plain-English question and get back a cited answer pulled straight from the scraped articles — no need to know a dataset’s exact name. Because I run the AI model locally, there’s no per-question cost and no data ever leaves the system.

Deployment. I shipped it ready to run either way: a quick dev setup for local testing, and a production-ready setup with load balancing, resource limits, and a locked-down internal database.

Stack: FastAPI, SQLAlchemy 2.0, Alembic, Pydantic v2, Celery + Celery Beat, Redis, PostgreSQL 16 + pgvector, React 18, TanStack Query, Tailwind CSS, Playwright, LangChain, Ollama (nomic-embed-text embeddings), Docker Compose, Nginx.

View the product demo → — screenshots of a running instance, walked through slide by slide.

LangGraph Playground Monorepo — Stateful Multi-Actor Agents

I architected and implemented LangGraph Playground, a modular Python monorepo for experimenting with, engineering, and deploying stateful, multi-actor AI agent workflows using LangGraph.

Monorepo architecture with editable shared packages. I structured the codebase cleanly around modular shared packages and decoupled applications:

• packages/core: Implements shared state schemas (including BaseAgentState backed by add_messages reducers, KeyValueState, and SQLAgentState), ASCII graph visualization (print_ascii_graph), and message-formatting helpers.
• packages/tools: Encapsulates reusable agent tools, including safe arithmetic evaluation (calculator), database tool suites (SQLDatabase, create_sql_tools), automated mock e-commerce database bootstrapping, and forbidden SQL keyword guardrails (FORBIDDEN_SQL_KEYWORDS).

Ready-to-run pattern examples. I developed four end-to-end reference agent workflows:

• Linear Stateful Graphs (ex01_basic_graph): Foundational node execution sequences, state mutation, and graph compilation.
• Tool-Calling Agent (ex02_tool_calling_agent): Dynamic conditional branching, tool invocation cycles, and model-tool message exchanges.
• Stateful Memory & Checkpointing (ex03_memory_and_checkpoints): Multi-turn conversational persistence across sessions using LangGraph’s MemorySaver checkpointer.
• Self-Healing SQL Agent (ex04_sql_agent): Natural language to SQL query generation with automated syntax error correction loops and guardrail validation against destructive operations.

Applications & developer experience. I built deployable surfaces including an HTTP API server scaffold (apps/api) for service invocation and an interactive terminal REPL agent runner (apps/cli), backed by a comprehensive 13-test integration suite, Jupyter experimentation notebooks, and Makefile shortcuts (make run-tools, make run-sql, make test).

Stack: Python, LangGraph, LangChain, SQLite, Pydantic, Make, Unit testing.

View GitHub Repository →

Dataset Pipeline Skill Suite (Factly Datasets ETL)

I built a modular set of 6 custom Claude Code skills that encode the entire ETL convention for the factly-datasets repository, so any dataset project — new or existing — gets built to the same directory structure, coding standards, and validation contract without me having to re-explain it each time.

dataset is the router I built: it resolves the repo root via git rev-parse, enforces that every path stays inside projects/, blocks direct writes on the develop branch (prompting to check out or create a feature branch first), and hands off to one of three flows depending on what’s needed.

dataset-create (Flow B) is what I use to scaffold a brand-new dataset project from scratch: it runs my team’s cookiecutter template, then generates a scraper (scrape_raw_data.py), an optional interim-cleaning step, and the final create_dataset.py — all with consistent path-resolution (Path(__file__).resolve().parents[N]), docstring and naming conventions, and incremental-update logic (concat, sort, dedupe on save). I built it to handle four source formats, including a genuinely detailed PDF/OCR pipeline I designed: dynamic page detection by header text (no hardcoded page numbers), a dual extraction path that routes text-rich pages through pdfplumber and image-only pages through an open-source OCR library (e.g. Tesseract), idempotency skips so re-runs don’t reprocess existing output, and indicator/category-name cleanup logic (footnote-digit stripping that’s careful not to mangle things like “by age 18”, plus OCR category canonicalization maps). It then calls my validation and workflow sub-skills, updates pyproject.toml, and runs poetry install plus each script with an automatic error-diagnose-and-fix retry loop I built in.

dataset-correct (Flow A) is the audit-and-repair counterpart I built: given an existing project, it checks for missing pipeline files, flags code issues (missing docstrings, single-letter variable names, wrong sort order, fiscal-year sort edge cases, missing append-then-sort logic), regenerates anything absent, and re-runs the same validation/workflow audits and script-fixing loop as dataset-create.

dataset-add-category (Flow C) is the same flow as Flow B, which I reused for adding a new sub-path/category inside a project that already exists, skipping the cookiecutter bootstrap.

dataset-validation is a skill I built to generate or audit the Pandera schema (rules.py) and validations/config.json for a project, then run valid validate-all with an error-fix loop I backed with a lookup table of common schema errors (dtype mismatches, nullable mismatches, incomplete isin= enums, duplicate-key issues) and their fixes.

dataset-workflow generates or audits the src/workflows/config.json that defines the cron schedule, script dependency graph, and validation step — the exact config file I have the Workflow Failure Resolver (below) read to know what to run and in what order.

I gave every skill the same safety scaffolding: abort keywords (stop/abort/cancel) checked on every turn, an interactive/non-interactive mode toggle, and checkpoints with “go back and re-run from step N” navigation, backed by an explicit dependency table of what needs regenerating. Together, the six skills I built form a self-consistent pipeline-generation system — that’s agent/skill engineering in its own right, not just prompting.

Automated Workflow Failure Resolver (Factly Datasets)

I built a production scheduled agent that monitors the “Workflow Notifications” Google Chat space for failed data-pipeline runs on the factly-datasets repository — which produces government/public datasets like CPCB air quality, NPCI, GST, RBI remittances, EPF, MNREGA, and similar releases — and autonomously fixes the ones on an approved whitelist.

I designed it to: read the latest failure notifications via Chrome browser automation, extract workflow names by regex, filter against a whitelist file (workflo-names.txt), skip anything already replied to, post an acknowledgment to the relevant Google Chat thread, create a git fix branch, run and validate the affected dataset script (falling back to my dataset-correct skill above when a script needs an actual fix), generate the rclone upload commands, then commit, push, and open a pull request against develop before checking back out.

I iterated on it repeatedly rather than building it once: I swapped Step 1 from screenshot-based reading to a direct DOM query via JavaScript for reliability, added a text-based fallback for detecting thread replies (Google Chat’s reply indicator isn’t a stable selector), added a safety check that halts the whole run if the local repo isn’t on the develop branch, and extended the final step to handle the full git → PR → checkout sequence automatically. I run it unattended on a Monday–Friday schedule, and I’ve watched it correctly identify runs with nothing in scope, or halt and ask for human input when Google Chat needed re-authentication or the sandbox couldn’t reach docs.google.com.

I also produced a small supporting toolkit in helper-functions/ (fiscal-year lookup, validation logging, Wasabi upload script) with its own README, and worked out a token-cost estimate for running the scheduler regularly (roughly $1–3/month quiet, $5–10/month during active failure periods).

Stack: Claude Code scheduled tasks, Claude in Chrome (Google Chat automation), git/GitHub CLI, rclone, Wasabi.