Gaurav Kumar

The problem

Maintenance teams sat on years of work-order history — free-text fault notes, repair actions, downtime records — and could not use any of it in the moment a machine went down. The question a technician actually asks is compound: what is failing, how long until it fails, what did we do last time, and which parts do I need? No single model or single index answers that.

Architecture

flowchart TD
    U[User question] --> IC[Intent classifier]
    IC --> SC{Semantic cache}
    SC -->|hit| ANS[Answer]
    SC -->|miss| ORCH[LangGraph supervisor]
    ORCH --> REG[(Agent registry)]
    REG -.declares intents.-> ORCH
    ORCH --> A1[Asset agent]
    ORCH --> A2[KPI + prediction agent]
    ORCH --> A3[Visualization agent]
    ORCH --> A4[Reporting agent]
    ORCH --> A5[Work-order agent]
    ORCH --> A6[Knowledge search agent]
    A6 --> RR{RAG router}
    RR --> V[Vector search]
    RR --> G[Graph traversal]
    RR --> F[Full-text search]
    V --> RK[Reranker]
    G --> RK
    F --> RK
    RK --> SYN[Synthesis]
    A1 --> SYN
    A2 --> SYN
    SYN --> ANS
          

Request path: classify → cache → orchestrate → route → retrieve → synthesise.

Decisions that mattered

• The cheapest answer wins. An intent classifier and semantic cache sit in front of the orchestrator, not inside it. A repeated or near-identical question short-circuits the entire pipeline — no planning, no tool calls, no LLM inference. Putting the cache behind the orchestrator would have saved a fraction of the cost for all of the complexity.
• A registry, not a router switch. Agents declare the intents they handle and register themselves; the supervisor discovers them at runtime. Adding a capability became a registration rather than an edit to a growing conditional in the orchestrator — the file that otherwise becomes the bottleneck every team touches.
• Layered retrieval instead of one index. A router picks per query: vector search for semantic similarity, graph traversal for entity relationships ("which assets share this component?"), full-text for exact identifiers like work-order numbers, or a hybrid. Querying all backends every time is both slower and worse — the irrelevant backend contributes noise that the reranker then has to undo.
• Two prediction subsystems, deliberately. A classic ML pipeline (sentence embeddings plus temporal and asset features → failure category, time-to-failure, downtime regression) runs alongside an LLM failure-mode classifier grounded in a curated failure-mode taxonomy. The ML models are calibrated and explainable; the LLM generalises to descriptions the models never saw.
• Degrade, don't fail. Failure-mode candidate retrieval falls back through three tiers — embedding similarity, then vector-DB keyword scoring, then plain keyword overlap. An embedding endpoint outage downgrades answer quality instead of returning an error.

What it demonstrates

Orchestration design under real cost and latency constraints, hybrid ML + LLM systems, and service decomposition where every service owns its data and communicates only over HTTP — no shared business-logic libraries, no import chains between services.

The problem

OEE — availability × performance × quality — is the number a plant manager actually steers by, and it only becomes useful when it can be interrogated: why did availability drop on this line last week? Answering that conversationally means putting an agent platform inside an enterprise network, which is where most enterprise AI initiatives quietly stall. Not because the AI is hard, but because nobody can say precisely which permissions the workload needs.

Architecture

flowchart LR
    subgraph VPC["Enterprise VPC — private subnets, no internet gateway"]
        direction TB
        C[Analytics client] --> GW[Agent gateway
tool exposure + authz]
        GW --> RT[Agent runtime]
        RT --> MEM[(Session + long-term memory)]
        RT --> TOOLS[Tool targets
OEE metrics, work orders]
        RT --> EVAL[Evaluation harness]
    end
    TOOLS --> WH[(Warehouse
availability / performance / quality)]
    RT -. VPC endpoints .-> BEDROCK[Managed model + agent services]
    IAM[/Least-privilege IAM roles/] -.assumed by.-> RT
    IAM -.assumed by.-> GW
          

Private-subnet deployment reaching managed services over VPC endpoints rather than the public internet.

Decisions that mattered

• Permissions verified, not assumed. I built a systematic access-check harness that enumerates every platform component across both control plane and data plane and reports per-component status. "It returns access denied somewhere" became a precise matrix of which component, which plane, which API call.
• Dry-run the writes. Destructive and provisioning permissions were evaluated with IAM policy simulation rather than by attempting the call. That answers "does this role have permission to delete a runtime?" without a test that creates or destroys anything — and it can run against a role you are not currently assuming.
• Separate the calling role from the target role. The most common misreading of an access report is conflating the identity running the check with the identity being checked. Distinguishing them explicitly turned an ambiguous failure report into an actionable, reviewable list of policy changes for the security team.
• Private subnets and VPC endpoints by default. Agent workloads reach managed services over private endpoints, with no route to the public internet — the baseline expectation for any enterprise security review, and far cheaper to design in than to retrofit.

What it demonstrates

The half of enterprise AI architecture that has nothing to do with models: IAM boundary design, control-plane versus data-plane reasoning, evidence-based security review, and producing artifacts a security team can approve rather than argue with.

The problem

Capable-To-Build asks a deceptively simple question: given current inventory, lead times, supplier commitments and lot-sizing rules, can we actually build this? The source data spans hundreds of master-data attributes across multiple plants and source systems, and a large share of them are unreliable — sparsely populated, inconsistently maintained, or duplicated between a source-system field and its harmonised twin.

Feed those into a model and you get something that performs well in backtest and fails in production, because it learned to depend on a field that a particular plant stopped populating two years ago.

Architecture

flowchart TD
    SRC[(Multi-plant supply
planning master data)] --> PROF[Automated profiling
population %, cardinality, drift]
    PROF --> GOV{Inclusion gate}
    GOV -->|below population threshold| EXC[Excluded + reason recorded]
    GOV -->|passes| DICT[Governed feature dictionary
attribute · rationale · availability]
    DICT --> FE[Feature engineering]
    FE --> F1[Lead-time composition
procure → transit → dock → point of use]
    FE --> F2[Lot-sizing constraints
min / max / order multiple]
    FE --> F3[Yield + scrap adjustment]
    FE --> F4[Validity windows
time-phased sourcing]
    F1 --> M[CTB feasibility model]
    F2 --> M
    F3 --> M
    F4 --> M
    M --> OUT[Buildable quantity
+ binding constraint]
          

Profiling gates feature inclusion; every attribute carries a recorded rationale.

Decisions that mattered

• A feature dictionary as a governed artifact. Every candidate attribute carries three recorded properties: why it matters to build feasibility, its measured population rate, and an explicit include/exclude decision. This turned feature selection from a modeller's private judgement into a document supply-chain domain experts could review and challenge.
• Availability as a hard gate. Attributes below a measured population threshold were excluded regardless of how predictive they looked. A field that is 40% populated is not a weak feature — it is a systematic bias toward whichever plants happen to maintain it.
• Model the lead-time chain, not the total. Replenishment lead time decomposes into procurement, manufacturing, transit, dock-to-point-of-use and order issue. Keeping the components separate means the model can attribute infeasibility to a specific stage — which is the difference between a number and a decision.
• Reconcile source-system and harmonised fields deliberately. Where the same measure existed in both raw and harmonised form, one was chosen with the reason recorded, rather than feeding both and letting the model split importance across two representations of one fact.

What it demonstrates

Data architecture judgement on messy enterprise master data, and the discipline of making modelling assumptions explicit and reviewable — the thing that most often separates a model that ships from a model that demos.

The problem

Most RAG reference implementations are built against clean documents and evaluated by reading a few answers and nodding. I built this one and then pointed it at a genuinely hostile document — a 167-page public-works tender with repeated page furniture on every page, dense tables carrying the actual commercial terms, clauses that contradict each other, and identifiers like tender and clause numbers that embeddings are structurally bad at.

Every design decision below came from something that document broke.

Architecture

flowchart TD
    PDF[PDF corpus] --> DOC[Docling parse
page-tagged blocks + tables]
    DOC --> BP[Strip repeated page furniture]
    BP --> SPL[Table-aware splitter
section packing · row-boundary tables]
    SPL --> EMB[Ollama embeddings]
    EMB --> PG[(PostgreSQL + pgvector
HNSW + tsvector GIN)]

    Q[Question + history] --> RWQ[Rewrite to standalone query]
    RWQ --> VEC[Vector branch
cosine]
    RWQ --> LEX[Lexical branch
full-text]
    VEC --> RRF[Reciprocal Rank Fusion]
    LEX --> RRF
    PG -.serves.-> VEC
    PG -.serves.-> LEX
    RRF --> GRD{Context sufficient?}
    GRD -->|no, retry ≤ N| RWQ
    GRD -->|yes| SYN[CrewAI synthesis]
    SYN --> OUT[Answer + page citations + trace id]
    OUT -.spans.-> PHX[(Phoenix tracing
+ prompt registry)]
    OUT -.scored by.-> RAG[RAGAs + retrieval gate]
          

Ingestion (top) and the self-correcting query loop (bottom) over one shared store.

Decisions that mattered

• Hybrid retrieval, fused with RRF. Embeddings handle paraphrase and fail on literals — a tender number embeds near every other tender number in the corpus. Full-text nails the literal and is useless on paraphrase. I fuse them with Reciprocal Rank Fusion rather than a weighted score blend, because cosine distance and text-rank scores share no scale and no fixed weighting survives changing the embedding model. RRF consumes only rank order.
• Page provenance is not optional. Flattening a PDF to one Markdown string loses the page number, and a citation you cannot verify is worse than no citation. The loader walks document items and reads per-item provenance so every chunk carries a real page.
• Position-scoped content hashes. The original hash covered chunk text alone, so 166 of 167 identical page headers collided and were silently dropped by an upsert conflict rule. Scoping the hash to file plus position fixed a data-loss bug that produced no error and no log line.
• Tables are never merged with prose. They are chunked alone, split on row boundaries, with the header row repeated into each part — half a table with no header is unreadable to a retriever and worse than useless to the model.
• Citations report what was actually used. The original synthesis step wrote to a copied list, so returned citations diverged from the evidence the answer was built from. Confident, plausible, wrong provenance is the most dangerous failure mode a RAG system has.
• An evaluation set with teeth. 42 questions spanning single-fact lookups, multi-hop questions, table lookups, self-contradictory clauses, and questions the corpus cannot answer — the last category verifies the system declines rather than invents. CI gates on a deterministic retrieval scorer; the LLM judge is too slow and too noisy for a pull request.
• Fail closed. Auth returned success on an empty API key, and the ingest endpoint accepted traversal paths. Both fixed; containers run non-root with model weights baked into the image so there is no runtime download to fail or be intercepted.

Outcome

169 unit and contract tests running with no network, database or LLM dependency, an integration suite against real pgvector, and CI running lint, coverage on two Python versions and a dependency audit. Full REST plus an OpenAI-compatible /v1 endpoint, so it drops into OpenWebUI or any OpenAI client with no adapter code.

View source on GitHub →

The problem

Bid teams find out about tenders late, and they find out unevenly. Opportunities are scattered across corporate, government and EPC portals that share no format, no language and no notion of an API. The interesting event is rarely the initial publication — it is the amendment three weeks later that moves the deadline.

I built this against two deliberately dissimilar live sources so the "pluggable" claim would be tested rather than asserted: ExxonMobil Mozambique's static HTML expressions-of-interest table, and eniSpace's Bandi di Gara, which is JS-rendered behind an F5/Volterra bot defence and published entirely in Italian.

Architecture

flowchart TD
    Y[sources.yaml] --> LS[load_sources]
    LS -->|Send fan-out| SG[per-source subgraph]
    SG --> FE[fetch] --> PA[parse] --> NO[normalize] --> EM[emit]
    FE -.-> HA[HttpAdapter
requests + robots.txt]
    FE -.-> BA[BrowserAdapter
Playwright, drives portal UI]
    EM --> PD[persist + diff]
    PD --> DB[(SQLite
FTS5 + tender_events)]

    DOC[document graph] --> DL[download] --> EX[expand archive]
    EX --> TL{page has text?}
    TL -->|yes| NAT[PDF text layer]
    TL -->|no| OCR[OCR the page]
    NAT --> SUM[key details + 300-word summary]
    OCR --> SUM
    SUM --> TR[IT to EN glossary + offline MT]
    TR --> DB
    DB --> UI[Streamlit dashboard · CLI]
          

Two graphs: a fast listing scan, and a heavy document pipeline run separately.

Decisions that mattered

• Forged requests lose; driving the real UI wins. eniSpace's documented AJAX endpoint returns HTTP 200 with an empty body — not only to curl with valid cookies, but to a fetch() issued from inside a real Chromium page. A browser fingerprint alone is not enough. What works is loading the portal and clicking its own search button, so the site issues its own guarded request and renders the results itself.
• Identity needs a document-type dimension. The same gara number is republished as Bando, then Rettifica, then Chiarimenti. Hashing on the reference alone silently collapsed 25 of 341 records into each other — and the amendments are exactly the records a bid team cares about.
• OCR only where the text layer fails. OCR costs 10–20s per page, and most tender PDFs are digital-native. Pages are OCR'd only below a character threshold. That fallback earns its place: one scanned amendment with zero extractable characters hid a deadline change from 28/11 15:30 to 06/12 15:00, now recovered and full-text searchable.
• Table-aware PDF extraction, built then deleted. I assumed missing deadlines were trapped in table cells and implemented table parsing to free them. Tested against the real corpus it found no genuine tables and shredded two-column layouts into word fragments. The actual bug was a regex window too narrow to span a label and value 100 characters apart across a line break. The feature was removed.
• Wrong data is worse than missing data. Early extraction reported the activity-sector field as the contracting authority and a mid-sentence fragment as the subject. Patterns are now line-anchored with a plausibility check, so a bad match becomes not stated rather than a confident falsehood.
• Translation needs guardrails, not just a model. Generic MT renders bando di gara as "race call", so a procurement glossary runs first. ALL-CAPS titles produced outright hallucination — one became "IMPLEMENTATION OF THE EUROPEAN PARLIAMENT" — so case is normalised first. And Italian portals publish English notices, which the model corrupted ("surplus assets sale" → "salt"), so text with no Italian marker is left untouched.
• Silence is the dangerous failure. A scraper that breaks after a site redesign returns zero rows and no error. Every run records its item count, and a successful run that extracted nothing is surfaced as an alert rather than an empty table.

Outcome

420 tenders tracked across two live portals with a field-level audit trail of every change, 105 document pages parsed, and summaries capped at 300 words with a key-detail table that outranks prose when the budget is tight. Adding a portal is a YAML block, not a code change. 71 tests, all offline — no network, browser or model dependency.

View source on GitHub →

The problem

A maintenance technician standing at a machine has gloves on and both hands occupied. Typing a query is not a realistic interface. Voice is — but the obvious route, a commercial speech API, was not available: work-order audio contains operational detail that cannot leave the network, and every request would cross the public internet.

The whole pipeline therefore had to be self-hosted.

Architecture

flowchart LR
    subgraph NET["Private VPC subnet"]
        CALLER[Client applications
Python · Node · Java] -->|HTTPS / TLS 1.3| GW
        subgraph HOST["Inference host"]
            GW[FastAPI + Uvicorn gateway
TLS termination · CORS · limits]
            GW --> NORM[ffmpeg normalisation
16 kHz mono 16-bit PCM]
            NORM -->|gRPC| ASR[Riva ASR]
            ASR --> LLM[Nemotron LLM
local HTTP]
            LLM -->|gRPC| TTS[Riva TTS]
            TTS --> WAV[PCM → WAV wrap]
            WAV --> GW
        end
    end
    GW -.->|REST| R1["/transcribe · /tts · /voice-chat"]
    GW -.->|WebSocket| R2["/ws/voice — streaming"]
          

Single-host POC: gateway, speech models and LLM colocated, reached only from inside the subnet.

Decisions that mattered

• Normalise audio at the edge, once. Clients send whatever their platform produces — different containers, sample rates and channel counts. The gateway transcodes everything to 16 kHz mono 16-bit PCM before the recogniser sees it. Pushing that requirement onto three client languages would have meant three subtly different implementations and a class of bug that only appears on one platform.
• Composable endpoints alongside the convenience one. Transcription and synthesis are exposed independently as well as behind a single voice-chat call. Callers that already have text shouldn't pay for a speech round trip, and being able to test each stage in isolation is what makes latency regressions diagnosable.
• gRPC internally, HTTPS at the boundary. Speech models are reached over local gRPC for streaming and lower per-call overhead, while external callers see ordinary REST and WebSocket over TLS. The model runtime is never directly addressable.
• A WebSocket path from the start. Request/response is acceptable for transcription but not for conversation — perceived latency is dominated by time to first audio, not total time. Streaming was designed in rather than bolted on.
• POC compromises documented as follow-ups. Self-signed certificates, permissive CORS, no API key, and security-group rules broader than they should be were recorded explicitly as blocking items for production rather than left for someone to discover. A POC that hides its shortcuts is how they reach production.

What it demonstrates

Real-time inference architecture, self-hosted GPU model serving, protocol selection under latency constraints, and honest separation between what was proven and what remains before production.

The problem

Financial planning is a domain where fluent, confident, wrong output is actively harmful, and where the arithmetic has to be exactly right. It is close to a worst case for a language model used naively: plausible reasoning, unreliable numbers, and a user with no easy way to tell the difference.

Approach

• Deterministic maths, generative explanation. Projections, compounding and allocation arithmetic belong in Python, not in the model. The LLM's job is interpreting inputs and explaining results in terms a non-specialist follows.
• Structured input before free-form reasoning. Extracting a typed financial profile first, and reasoning over that, is far more reliable than reasoning directly over conversational text.
• Explicit scope boundaries. The system is built to state what it cannot responsibly advise on — a design requirement, not a disclaimer.

View source on GitHub →