Projects

Personal builds, shipped with intent.

End-to-end builds. Problem through deployment.

Interview Agent

Live

View project

Problem

I needed a live, grounded demonstration of applied RAG design that could answer real questions about my background accurately, with sources.

Approach

FAISS index over my CV and project notes. LangGraph routes between local retrieval and web search fallback. Citation injected on every response.

What I Built

  • FAISS vector index over resume, CV, and project documentation
  • LangGraph routing between retrieval and web fallback
  • Citation injection pipeline: every answer references its source
  • Streamed responses for a fast, interactive feel

Evaluation

Manual review against known queries. Tracked retrieval precision and citation formatting across versions.

Impact

Live. One artifact showing retrieval quality, prompt discipline, and system design end to end.

Lessons Learned

Retrieval quality is the hard problem. Chunk size, overlap strategy, and embedding model choice determine whether answers are correct.

Stack

RAGLangGraphFAISSOpenAIPython

Stock Screener

Live Demo

View project

Problem

A full stock screening product would need a systematic, repeatable signal for identifying undervalued positions. This is a working demo of that core logic.

Approach

Pull price and valuation data for a watchlist, then estimate time-to-grow-3–5% per ticker rather than showing raw price change.

What I Built

  • Watchlist tracker monitoring selected tickers for undervalued signals
  • Growth projection engine: estimated time-to-gain per ticker
  • Buy/watch signal based on valuation and momentum
  • Dashboard showing the full watchlist at a glance

Evaluation

Validated signal logic against historical data to verify growth projections matched observed price movement.

Impact

One view showing which watchlist stocks are worth acting on and when.

Lessons Learned

Time-to-target is more actionable than raw price change. It naturally incorporates time horizon and expected hold period.

Stack

PythonAPIsData ProcessingFinancial Modeling

Payment Retry Decision Engine

Live Demo

View project

Problem

A production payment recovery system needs to distinguish retryable failures from ones that will keep failing, maximizing recovery without burning retries on low-probability transactions.

Approach

Classification model trained on payment failure patterns. Each prediction returns a recovery probability, a confidence band, and a SHAP-based breakdown of the factors driving the score.

What I Built

  • Feature pipeline covering failure reason, payment method, retry count, customer tenure, and billing timing
  • Trained classifier predicting per-transaction recovery probability with confidence band
  • SHAP integration for interpretable factor attribution on every prediction
  • Flask API serving scored retry recommendations
  • Color-coded UI showing retry vs. escalate signal at a glance

Evaluation

Evaluated on precision-recall tradeoff between false retries and missed recoveries. Threshold tuned to minimize wasted retries on near-zero-probability transactions.

Impact

Input a failed payment, get a recovery probability, a recommendation, and the factors behind it. The full decision loop in one view.

Lessons Learned

The most useful output in payment ML isn't accuracy. It's explainability. Merchants need to know why a retry is recommended, not just whether.

Stack

Pythonscikit-learnSHAPFlaskFinancial Modeling