S-ASHWATH · TECHNICAL DOCUMENTATION
Use cases, agents,
and the stack behind them.
5 domains. Each one starts with a real problem in an industry where I have hands-on context. Each one ends with a working agent or system — built, validated, and live.
How many AI systems does it take to replicate what a marketplace team of 17 normally does? One person was the only way to find out.
200+
Self-generating pages
AUTONOMOUS CONTENT ENGINE
Batch LLM processing across 9,300 SKUs — staged apply/rollback with per-batch locks. Runs nightly, unattended.
FRONTEND
None — headless nightly batch job (no UI)
BACKEND
Python · Google Gemini Flash · MySQL · cron scheduler · staged apply/rollback with per-batch locks
// WHY THIS ARCHITECTURE
Optimising 9,300 SKUs is a bulk, unattended job — not a user interaction — so it runs as a scheduled backend batch, not an app. The staged apply/rollback and per-batch locks matter more than any UI: if a batch fails at 3am it must resume cleanly without corrupting the catalog.
CONVERSATIONAL STOREFRONT ASSISTANT
Buyer Q&A in plain language. Worked around the commerce engine stripping JS via a server-level injection layer.
FRONTEND
Vanilla JavaScript chat widget, injected at server level
BACKEND
PHP endpoints · Anthropic Claude
// WHY THIS ARCHITECTURE
The commerce platform stripped custom JS from the theme, so the assistant had to be injected through a server-level layer instead. It is kept dependency-free (vanilla JS, not a framework) so it survives platform updates; Claude handles the natural-language Q&A while thin PHP endpoints bridge to the catalog.
BUYER INTELLIGENCE TOOL
Location-aware recommendation engine — surfaces parts relevant to a regional market from a sprawling catalog.
FRONTEND
Lightweight JS embedded in product pages
BACKEND
Anthropic Claude · location lookup · rule layer
// WHY THIS ARCHITECTURE
Recommendations must be location-aware and fast, so a deterministic rule layer narrows the sprawling catalog to a regional shortlist before the LLM reasons over it. That keeps latency and token cost low while keeping results relevant to each market — the LLM is the last mile, not the whole pipeline.
VENDOR INTELLIGENCE DASHBOARD
Financial-terminal-style demand dashboard with live heatmaps across 15 regional markets + LLM demand reports on request.
FRONTEND
JavaScript real-time dashboard — financial-terminal-style heatmaps across 15 markets
BACKEND
Deterministic rule engine · Anthropic Claude (on-demand reports)
// WHY THIS ARCHITECTURE
Vendors need live demand at a glance, so the heavy lifting is a deterministic rule engine driving a real-time heatmap UI; the LLM is invoked only on request to write a demand narrative. Fast and cheap where it must be (the dashboard), intelligent where it adds value (the report) — not an LLM call on every refresh.
PRODUCT IMAGERY STUDIO
Bulk image-generation pipeline with dual-model A/B (Gemini vs GPT Image) and live cost tracking per batch.
FRONTEND
Batch console with live per-batch cost tracking
BACKEND
Python pipeline · Gemini Flash Image · GPT Image (dual-model A/B)
// WHY THIS ARCHITECTURE
Image generation is expensive and quality varies by model, so a dual-model A/B pipeline runs both and tracks cost per batch — letting the better model win on evidence rather than assumption. It is a backend pipeline because the work is bulk and unattended, not an interactive editor.
COMMERCE INTEGRATION LAYER
Payments, logistics, transactional email, order messaging, and government-API vendor verification wired as one.
FRONTEND
None — server-side integration layer
BACKEND
Payments · logistics · SMTP · order-messaging API · government verification (vendor KYC) APIs
// WHY THIS ARCHITECTURE
Payments, shipping, email, and vendor KYC are all fragile third-party calls. Wiring them as one server-side layer keeps the storefront thin and concentrates every external dependency in a single observable, retryable place — so when a provider fails, it fails in one known spot, not scattered across the app.
INFRASTRUCTURE & SAFETY LAYER
Linux admin, CDN/WAF, automated nightly backups, and a written ops runbook. The rules are the real product.
FRONTEND
None — operations layer
BACKEND
Linux server admin · CDN/WAF at the edge · automated nightly backups · written ops runbook
// WHY THIS ARCHITECTURE
A solo-run marketplace needs guardrails more than features. The real product here is operational discipline: a WAF at the edge, automated nightly backups, and a written runbook so that recovery is a checklist to follow — not a 2am improvisation with nobody to call.
India has a $530B MSME credit gap. The bottleneck is underwriters spending hours triangulating documents — not a shortage of capital.
$530B
MSME credit gap (India)
70%
Analyst time on doc review
SME CREDIT ANALYST AGENT
Triangulates GST annual turnover, 12-month bank credits, and ITR declared income. Applies underwriting scoring logic and generates a structured credit narrative with risk flags and recommended limit range. Runs in under 10 seconds.
FRONTEND
React · TypeScript · single-page agent UI (inputs → structured credit brief)
BACKEND
None — all triangulation and scoring runs in-browser; no API calls
// WHY THIS ARCHITECTURE
The underwriting logic is deterministic and lightweight, so it runs entirely client-side. That is a deliberate choice: sensitive financial figures (GST, bank, ITR) never leave the browser, decisions return in under 10 seconds with no network round-trip, and there is zero server cost or attack surface to host the demo.
Revenue management software on the airline side costs millions. A passenger booking LHR→JFK has no tools to model what a fuel spike, route disruption, or geopolitical event will do to fares over the following week. AirWave inverts this: pull live fares, run a deterministic P&L cascade model, deploy 8 independent market agents each with a fixed behavioral profile and fuel hedge position, then weight their votes by market share into a consensus fare prediction with a confidence band. A second system, SQUALL.IROPS, applies the same philosophy to operations: it predicts airline irregular-operations (IROPS) disruption risk before a flight is officially cancelled and drafts proactive passenger outreach — turning a reactive, siloed scramble into an early, coordinated response. Together: AirWave models revenue under pressure, Squall models operations under pressure.
2
Live systems (fare + IROPS)
3-day
IROPS nowcast horizon
AIRWAVE · FARE SCENARIO INTELLIGENCE ENGINEGITHUB ↗ 8 market agents (LCC Revenue Manager, Legacy Network Carrier, ULCC Revenue Manager, Premium Boutique, Enterprise Travel Manager, Price-Elastic Consumer, Online Travel Agency, Miles Optimizer) each receive live fare data, a cascaded P&L shock output, and their own behavioral profile. Each produces an independent fare vote and confidence score. Votes are market-share-weighted (Legacy 42%, LCC 28%, ULCC 12%, Premium 7%) into a consensus predicted fare with a ±band. Stack multiple shock triggers for compounded scenarios. A/B comparison mode for two concurrent runs. Rate-limited Flask API (5 req/60s). Simulation history in localStorage. PDF export. Open-source on GitHub.
FRONTEND
Vue 3 (Composition API) · Vite · reactive multi-step simulation UI · A/B comparison view · PDF export
BACKEND
Flask · Python · Gemini 2.5 Flash · deterministic P&L cascade engine · rate limiter (5 req/60s) · Duffel NDC · OpenSky · Yahoo Finance · SerpAPI · News RSS · AGPL-3.0
// WHY THIS ARCHITECTURE
Fares come from rate-limited, key-protected third-party APIs and the 8-agent simulation is compute-heavy — so it needs a real server to hold credentials, cache responses, and rate-limit. The P&L cascade is plain deterministic Python (not an LLM) so the maths stays auditable; the model only writes narrative. Vue + Vite was chosen for a fast, reactive UI to drive the multi-step "pick route → stack shocks → compare" flow without a heavy framework.
SQUALL.IROPS · AIRLINE DISRUPTION INTELLIGENCE ENGINEGITHUB ↗ The operations counterpart to AirWave. Enter an origin–destination pair; the Predictor fans out concurrently to live weather (Open-Meteo), disruption news (SerpAPI Google News), and air-traffic density (OpenSky) at both endpoints, then runs a deterministic risk cascade — each signal normalised 0–100, weight-blended (Weather 50% · News 30% · Traffic 20%) and renormalised over whatever is live, so it works from the busiest hub to a Tier-3 regional field. Real flights on the route (SerpAPI Google Flights) inherit the route risk plus a departure-window overlay. The Communicator then builds synthetic passenger personas grounded in the real flight and uses Gemini to draft tailored, proactive rebooking messages. A transparent business-case panel quantifies disruption cost avoided plus an Air-Canada-"On My Way"-style protection-fee revenue stream. Predictions are capped to a credible 3-day nowcast horizon. Honestly scoped: live where measurable, synthetic only for passenger identities — declared openly.
FRONTEND
React 18 · Vite · TypeScript · typed ops-dashboard UI · count-up + staged-load animations · Methodology drawer
BACKEND
FastAPI (async) · Python · gunicorn + uvicorn workers · nginx · Gemini 2.5 Flash · Open-Meteo · OpenSky · SerpAPI Flights + News · airportsdata (28k+ airports)
// WHY THIS ARCHITECTURE
Every request fans out to four live APIs at both airports, so the backend is async (FastAPI + asyncio.gather) — it fetches them concurrently, making total latency the slowest single call rather than the sum of all four. I deliberately chose a different stack from AirWave (FastAPI vs Flask, React vs Vue) for two reasons: async genuinely fits a live multi-source fan-out and streaming, and it demonstrates range across stacks. The risk score is a deterministic cascade in plain Python so it is fully auditable; the LLM only drafts the passenger messages.
A Bloomberg terminal costs $25,000 a year. Oxford Economics and Macrobond serve institutional desks. None of them produce a plain-English brief for the CFO, the startup founder, or the logistics professional who needs to understand what a macro shock means for their specific role. This platform replicates the same four-layer analytical pipeline — live news trigger detection, live market seeding, a calibrated sector cascade model, and AI narrative grounded in today's real events — and delivers institutional-rigour output in plain English, for any decision-maker, free.
// REPORT GENERATION PIPELINE — 4-LAYER ARCHITECTURE
01→
RSS NEWS SIGNALS
BBC World · BBC Business · NYT World · NYT Business
15-min server cache. Keyword-matched to 6 shock categories. Returns signal strength 0–3 and a live headline per trigger. Cards reflect real news — not static labels.
02→
LIVE MARKET SEEDING
Yahoo Finance · open.exchangerate-api.com
5-min cache. VIX is extracted and converted to a cascade depth multiplier (VIX 14 = 0.82×, VIX 38 = 1.45×). WTI and S&P500 changes dampen first-order impacts already priced in today.
03→
BFS CASCADE MODEL
13 sectors · 31 data-calibrated edges
Breadth-first search propagates shock impact sector-by-sector. Edge weights calibrated via event-conditional regression against 23 historical shocks (Gulf War 1990 → Ukraine 2022) using Yahoo Finance ETF data. Circuit breakers cap runaway cascades.
04
AI SEARCH GROUNDING
Gemini 2.5 Flash · Google Search API
Gemini receives the full 13-sector cascade output plus live market data. Google Search Grounding fires at inference time — the model searches the current web before writing. The brief must cite specific cascade numbers AND specific current events. 11 persona cuts.
Live
Search-grounded output
BFS CASCADE PROPAGATION ENGINE
Breadth-first search across 13 sectors and 31 directional edges. Each trigger fires first-order shocks; the BFS engine propagates them sector-by-sector with sector-specific lag, confidence, and circuit-breaker thresholds. Edge weights are data-calibrated — not authored — via event-conditional correlation analysis across 23 historical shock events using Yahoo Finance ETF return data. VIX is applied as a real-time cascade multiplier: same WAR_CONFLICT trigger produces different sector numbers at VIX 14 vs VIX 38. Already-priced-in dampening prevents double-counting sectors the market is already moving on today.
FRONTEND
TypeScript in the Next.js app · D3 force-directed network graph (13 nodes, 31 edges) · live cascade overlay
BACKEND
Next.js API route (TypeScript) · custom BFS propagation engine · yfinance-calibrated edge weights · VIX multiplier · priced-in dampening
// WHY THIS ARCHITECTURE
The cascade is deterministic graph maths, not generative — so it lives in plain code for auditability and millisecond speed, and the edge weights are calibrated offline from 23 historical shocks rather than guessed. It runs in a Next.js API route so it is co-located with the site and instantly callable, with D3 rendering the propagation visually on the client.
LIVE TRIGGER INTELLIGENCE · RSS ENGINE
Pulls BBC World, BBC Business, NYT World, and NYT Business RSS feeds every 15 minutes. Keyword-matches each headline to 6 shock categories (WAR_CONFLICT, OIL_SHOCK, RATE_HIKE, PANDEMIC, SUPPLY_CHAIN, MARKET_CRASH). Returns signal strength 0–1 and a real headline per trigger category — so every trigger card shows real news relevance, not a static label. ACTIVE badge fires when signal strength crosses threshold.
FRONTEND
Trigger cards in the Next.js UI · live signal-strength dots + ACTIVE badge
BACKEND
Next.js API route · BBC + NYT RSS · regex keyword engine · 15-min server cache · 6 shock categories
// WHY THIS ARCHITECTURE
News must be live, but RSS feeds are slow and rate-sensitive, so fetching and keyword-matching happen server-side behind a 15-minute cache — the browser only renders the scored result. Server-side keeps the app within feed limits and avoids CORS, while the cache keeps it fast and polite to the sources.
MACRO INTELLIGENCE BRIEF · GEMINI SEARCH GROUNDING
Receives the full 13-sector cascade output (all sectors, with impact %, lag, confidence, and propagation mechanism) plus live market data. Google Search Grounding fires at inference time — Gemini searches the current web before writing, not its training data. The system instruction requires the model to cite at least two specific cascade sectors by percentage AND anchor each claim to a specific current real-world event. Output: 4-section plain-English brief, under 500 words, specific to one of 11 decision-maker personas. Not a generic macro summary — a personalised analytical report.
FRONTEND
Brief panel in the Next.js UI · 11-persona selector · Scenario A/B toggle
BACKEND
Next.js API route · Gemini 2.5 Flash · Google Search Grounding · temperature 0.4 · full cascade context injected
// WHY THIS ARCHITECTURE
The brief must cite current real-world events, so Gemini runs with Google Search Grounding — and that has to happen server-side: the API key must never reach the browser, and the prompt carries the full 13-sector cascade plus live market data, which is too large and sensitive to expose client-side.
India processes over 250 million insurance claims annually. Adjusters spend 60% of their time reading FNOL attachments before making a single triage decision. Fraud patterns — early-inception claims, high-frequency claimants, over-valued amounts — surface only when you hold all signals together. Manual review processes them in isolation.
250M+
Claims filed in India / yr
₹45,000 Cr
Annual fraud losses (est.)
CLAIMS TRIAGE AGENT
Takes six FNOL parameters — policy type, incident category, claim quantum, filing delay, prior claims history, and policy age — and runs them through a multi-signal fraud scoring engine. Outputs fraud risk (LOW to CRITICAL), coverage likelihood, triage priority (FAST_TRACK / STANDARD / INVESTIGATE / REFER_SIU), indicative settlement range, specific risk flags, and a three-paragraph adjuster narrative with recommended next action. Runs in under 10 seconds. No API calls — all inference is in-browser via a rule-based scoring engine calibrated against standard insurance underwriting heuristics.
FRONTEND
React · TypeScript · single-page triage UI (FNOL inputs → adjuster brief)
BACKEND
None — fraud scoring and triage logic run entirely in-browser; no API calls
// WHY THIS ARCHITECTURE
Like the credit agent, triage scoring is deterministic and must be instant and private — so it runs client-side. FNOL claim data never leaves the browser, the adjuster brief returns in under 10 seconds, and there is no server to secure or pay for. The "product" is the calibrated scoring logic, not infrastructure.
06Portfolio Platform Stack
The site itself is a demonstration of the same approach — built end-to-end, no design system, no component library, no shortcuts.
Framework
Next.js 16.2 · App Router · React 19 · TypeScript 5
Static export where possible, dynamic API routes for LLM + market data
Animation
Framer Motion 12 · GSAP 3.15 + @gsap/react
Page transitions, scroll animations, marquee ticker, scramble text, section dividers
Visualisation
D3 7.9
Macro network force-directed graph — 13 nodes, 31 edges, BFS cascade overlay
Styling
CSS Custom Properties · Inline styles · Zero CSS frameworks
Design tokens in globals.css — all spacing, color, and typography via CSS vars
LLM
Google Gemini 2.5 Flash · Google Search Grounding
Persona briefs grounded in current real-world events via Google Search at inference time — 11 roles, 4 sections, <450 words
Market Data
Yahoo Finance API · open.exchangerate-api.com
5-min cache on /api/market — VIX, WTI, S&P 500, USD/EUR, GOLD, 10Y UST. VIX drives cascade multiplier in real time.
News Feed
BBC World · BBC Business · NYT World · NYT Business RSS
15-min cache on /api/triggers — keyword-matched to 6 shock categories, signal strength + live headline per trigger
Custom Systems
BFS Cascade Engine · Scramble text hook · Custom cursor · Fare analysis engine · SME credit scoring · Insurance claims triage scoring
All built from scratch — no third-party AI wrappers for domain logic
Hosting
Fly.io · GitHub
Three always-on services: s-ashwath.com (Next.js) · airwave.s-ashwath.com (Flask + Vue) · irops.s-ashwath.com (FastAPI + React). Singapore region. Env vars managed as Fly.io secrets.
// BUILD PHILOSOPHY
Every system here was built to answer a real question — not to demonstrate a stack or pad a portfolio.
The constraint I imposed: no scaffolding, no off-the-shelf agents, no pre-built workflows. The value of building this way isn't the output — it's what you learn when the system breaks at 2am and there's nobody to call. That's when you find out what you actually know.