# Tech why / 10× scale — R3/R4 (Adarsh Vishwakarma)

Notes for a later live if they ask **why that stack**, **why not the obvious alternative**, or **how would you scale this**. Java is Live Code. Production was Python FastAPI, TypeScript NestJS/React, LangGraph, YOLOv9, ROS2. Job **10454435** still has no public IE that names a live-round design. These are answers to what **other** SDE I / UTA / AUTA candidates grilled on resume tech. Unnamed stays unnamed. Metrics only from `Resume_Adarsh_Vishwkarma_Aug26.pdf`. I did **not** shard. I will not invent Qdrant-as-shipped, Haar, Kafka-as-operated, EKS-as-Ylogx, an AWS bill, p95, TTL, a missed 99.9%, ticket IDs, or mentee counts.

**How to use in the room.** They ask “why X.” Speak: who hurt without it → what you considered → what you shipped (walk the hops) → why the alternative dies → 10× without lying → the failure class. Then stop. Eight follow-ups below are probes, not a lecture. If they already heard the 60-second pitch, skip the product tour and start at the alternative.

**Java once.** Same graph of nodes, same cache-aside, same RLS idea. Syntax here is Java. Intern path was Python/TS/ROS2.

---

## 1. Why LangGraph, not a linear LangChain chain

**Problem without it.** Deep Research is not “call an LLM, then call a scraper, then write.” Analysts need coverage across **200+** websites. A linear chain dies the first time Playwright times out: you lose Bing hits you already paid for, you cannot fan four tools, you cannot loop retrieve → grade → retrieve again, and you have no checkpoint to resume a long run. Hybrid RAG on **200+** page BRDs has the same shape: adaptive retrieval is a *choice* of hop, not a fixed pipeline.

**Alternatives considered.** One-shot ChatGPT over the query. A LangChain sequential chain: plan → scrape → write. A homegrown `for` loop of tools with a global dict. Fine for a demo. Wrong when a failed scrape must retry without restarting the run, when Firecrawl / Bing / DuckDuckGo / Playwright must run in parallel, and when the writer must see ranked state, not the last tool’s stdout.

**What I shipped (data flow).** (1) FastAPI receives the research query. (2) A planner node writes a search plan into typed graph state. (3) Parallel tool nodes fan out: Firecrawl, Bing, DuckDuckGo, Google Playwright. (4) Each tool **appends** documents into `docs` with a reducer — a dead Playwright does not wipe Bing. (5) Checkpoint persists state keyed by a thread id after the fan-out. (6) Ranker scores quality, recency, and **agreement**. (7) Writer synthesizes only from ranked state. (8) Optional cycle: grade citations, hop again, cap iterations so the graph cannot loop forever. (9) Hybrid RAG sibling: LangGraph **chooses** lexical vs semantic vs GraphDB hop instead of always embedding. (10) LangSmith traces the node order. Resume claim is **stateful agent orchestration** and **200+** sites ranked. I do not invent a Postgres checkpointer topology.

**Why not the alternative.** A linear chain is a linked list of side effects. Parallel tools need a graph. Retries need a checkpoint. Cycles need an edge back to retrieve. HITL (spot-check generated tests) needs resume-from-state. That is LangGraph. I did **not** retrofit LangGraph onto the Ylogx chatbot; Ylogx is LangChain **SQL RAG**.

**10× scale (honest).** Ten times the sites is **more ranker and more cache of scrapes**, not Playwright on every URL. Cap fan-out. Prefer Bing snippets over full renders when cost spikes. Do not re-run a 200-site graph because one domain 404’d — that is why checkpoint exists. I did not shard a research index. I have no IQVIA latency percent on the resume.

**Failure mode.** Empty scrape still feeding the writer. Two high-ranked pages contradict; first-hit looks confident. Unbounded retrieve-grade cycle. Fluent paragraph with no overlapping span (LangSmith must fail that).

**Eight follow-ups.**

**Q. Isn’t LangChain enough?** A. LangChain is the tools and the SQL-RAG pattern at Ylogx. Deep Research needs retries, parallel tools, checkpoint, and cycles. That is a graph. I name the product: LangGraph Deep Research on FastAPI.

**Q. What is state?** A. A typed dict the graph reads and writes: query, docs, ranks, answer, errors. Nodes return partial updates. Parallel tools append. I will not dump a proprietary IQVIA schema.

**Q. What is a checkpoint?** A. Persist after a node, keyed by thread id. Failed Playwright retry does not erase Bing. Resume wording: stateful agent orchestration. I do not invent the storage engine unless they ask conceptually.

**Q. Can it loop forever?** A. Cap iterations. Retrieve → grade → retrieve is allowed; unbounded is a bug. Fail closed to “need a human” rather than another fluent paragraph.

**Q. HITL product UI?** A. Checkpoint is why a human *can* resume. Test-case gen from BRDs is a traced job; humans spot-check a sample. I do not claim a shipped HITL console that is not on the resume.

**Q. Why not one mega-prompt?** A. **200+** pages and **200+** sites do not fit. Citations invent themselves. No eval.

**Q. Java?** A. Same graph of nodes. I shipped Python. Live Code is Java. I can sketch an interface of retrieve strategies; I did not ship a JVM agent.

**Q. Ylogx chatbot is LangGraph?** A. No. Ylogx is LangChain SQL RAG behind RLS. Mixing them is how you get caught.

---

## 2. Why Azure AI Search Hybrid + Semantic, not vector-only FAISS, not stuff-the-PDF, not Qdrant

**Problem without it.** **200+** page BRDs. Stuffing the PDF invents citations and blows the context window. Vector-only FAISS (skills list) is cosine on embeddings: it misses clause IDs like a requirement token, table names, and exact lexical hits. Qdrant is **not** on this resume. IQVIA retrieval is **Azure AI Search (Hybrid + Semantic) + GraphDB**.

**Alternatives considered.** Dump the PDF into the prompt. Local FAISS index because it is on the skills line. A pure vector store I would have to operate. A keyword-only search that misses “what is the retention policy” when the clause never uses that phrase.

**What I shipped (data flow).** (1) BRD/PDF is chunked **with structure** — headings, clause IDs, tables — not random 512-token windows only. (2) Chunks go to Azure AI Search. (3) Query hits **hybrid**: lexical (BM25-like) **plus** vector in one query. (4) Azure **semantic ranker** reorders for meaning — I did not invent an embedder. (5) If the question is a dependency, GraphDB hop (next card). (6) LangGraph adaptive retrieval picks lexical vs semantic vs hop. (7) Writer sees a **small** set of chunks, not 200 pages. (8) Cite-or-abstain: no overlapping span, no sentence. (9) LangSmith gold questions with expected citation ids. (10) Secrets for Azure in env/secret store, not in traces. Resume: process **200+** page BRD/PDF documents. No extra percent.

**Why not the alternative.** Stuff-the-PDF cannot cite. Vector-only misses `REQ-1044`. Qdrant would be a different ops story I did not ship. FAISS is a **skill**; intern retrieval for BRDs is Azure. GiftedBooks is a smaller PDF RAG (student’s file) — do not steal Azure into that sentence.

**10× scale.** Do not re-embed a BRD on every question. Hybrid retrieve a small set. Graph hop is cheaper than another generation when the question is relational. If cost spikes: fewer Playwright renders on the *research* sibling; tighter recency. I have **no bill** to quote. I did not shard Azure.

**Failure mode.** Semantically similar annex, wrong clause. Fluent paraphrase with no span overlap. Logging full confidential BRD text into traces.

**Eight follow-ups.**

**Q. Hybrid vs semantic — are those two products?** A. Hybrid on Azure = lexical plus vector in one query. Semantic **here** = Azure’s semantic ranker on top. Lexical hits IDs; semantic hits policy language.

**Q. Why not FAISS? It is on your skills.** A. Listed. Intern evidence for BRDs is Azure AI Search. I will not fake a FAISS-at-IQVIA prod story. Vector-only misses clause IDs — that is the architecture reason even if FAISS can store vectors.

**Q. Did you use Qdrant?** A. No. I will not say Qdrant.

**Q. Embeddings you trained?** A. I will not claim a private embedder. Resume is Azure Hybrid + Semantic + GraphDB.

**Q. How many chunks in the prompt?** A. Small set — think 5–20, not 200 pages. I will not invent a token invoice.

**Q. GiftedBooks used Azure too?** A. No. GiftedBooks is the student’s PDF, sub-300 ms. IQVIA is Azure + GraphDB. Stores stay in lanes.

**Q. Multi-tenant BRD SaaS?** A. I will not invent a multi-tenant model the resume does not state. JWT/RLS theatre is Ylogx.

**Q. Latency SLA?** A. None on the IQVIA bullets. Do not borrow Ylogx sub-210 ms.

---

## 3. Why GraphDB hops (requirement dependencies) vs cosine

**Problem without it.** Requirements **depend on each other**. “What else breaks if this clause changes” is an edge, not a nearest neighbor. Cosine returns a semantically similar paragraph in the wrong annex. Test cases generated from the wrong section are how you ship a confident, wrong QA pack.

**Alternatives considered.** Only vector search. Only keyword. Stuff more chunks and hope the model “sees” the dependency. A SQL foreign key dump of every requirement into the prompt.

**What I shipped (data flow).** (1) Structured chunks already have clause IDs. (2) Graph nodes are requirements / sections; edges are dependencies (DEPENDS_ON-shaped). (3) Adaptive router: clause ID → Azure hybrid (keyword-heavy). (4) “Depends on” / impact question → GraphDB hop to neighbors. (5) Meaning-only question → hybrid + semantic ranker. (6) Writer receives retrieved chunks **plus** hopped neighbors. (7) Cite-or-abstain still applies to hopped text. (8) LangSmith fails a generated test with no overlapping span. Resume says **GraphDB**. Skills list says Graph DB (Neo4j). I speak **GraphDB** for the intern bullet. Neo4j specifics only if they ask the skills line — I will not fake Cypher I operated as a named prod DBA.

**Why not cosine.** Cosine has no hop. A neighbor in embedding space is not a neighbor in the requirements graph. Graph hop is also **cheaper** than another LLM call when the question is relational.

**10× scale.** Hop bounded (one or two hops), not “load the whole graph into the prompt.” More BRDs means more indexed nodes, not a fourth search tool without an eval slice. I did not shard a graph cluster I will name.

**Failure mode.** Hop to a related-looking but non-dependent clause. Unbounded expansion. Treating Neo4j-on-skills as if I ran a production cluster topology I cannot defend.

**Eight follow-ups.**

**Q. Why not just a bigger k in vector search?** A. Bigger k still will not follow DEPENDS_ON. It will add more similar prose.

**Q. Neo4j?** A. Skills line. IQVIA bullet is GraphDB. I will not fake a cluster diagram.

**Q. What is a hop in one sentence?** A. Start at the matched requirement, walk dependency edges, retrieve those chunks too.

**Q. SQL graph?** A. Recursive SQL can express a tree. The intern story is GraphDB hops plus Azure. I will not invent a warehouse graph I did not print.

**Q. Cycles in the requirement graph?** A. Cap hop depth. Same discipline as LangGraph iteration caps.

**Q. Cosine after hop?** A. Hop is for structure. Hybrid still ranks text. Do not replace Azure with “we only graph.”

**Q. Test-case gen without graph?** A. Tests hang off the wrong section. That is the failure LangSmith is supposed to catch.

**Q. 10× BRDs?** A. Freeze an eval slice of sections → expected tests **before** adding a fourth retrieval tool.

---

## 4. Why LangSmith (fluent ≠ cited; fail if no overlapping span)

**Problem without it.** A fluent paragraph is not a test. Analysts will trust a wrong citation. Generated test cases from the wrong BRD section look professional. Without traces you cannot see empty scrapes feeding the writer or wrong tool order.

**Alternatives considered.** “It sounded good.” BLEU on English. Manual spot-check only, with no gold citations. Logging full documents into a chat UI.

**What I shipped (data flow).** (1) Every node traced: query, retrieval set, tool order, answer. (2) Gold questions with **expected citation ids**. (3) Eval **fails** if the answer has no overlapping span with retrieved chunks. (4) Test-case generation is itself a traced job. (5) Humans spot-check a sample. (6) Secrets not in traces. (7) Do not log full confidential BRD text in production traces. (8) Deep Research: traces catch empty scrape → writer. Resume: evals, test case generation with LangSmith tracing. **No extra %.**

**Why not the alternative.** Fluency is the failure mode. Span-overlap is the gate. I do **not** claim LangSmith on Ylogx, GiftedBooks, or StratifyLabs. SQL RAG eval is expected **SQL shape / result set**. Argus eval is **mAP**.

**10× scale.** More gold items on a frozen slice, not more tools. Tracing cost: trace ids and chunk ids, not raw annexes. I will not invent a LangSmith bill.

**Failure mode.** Eval that checks grammar. Trace that dumps the PDF. Stealing this sentence into GiftedBooks.

**Eight follow-ups.**

**Q. Isn’t the model’s confidence enough?** A. No. Confidence is fluency. Span overlap is the fail.

**Q. BLEU?** A. Wrong family for citations. Gold is citation id / span, not n-gram overlap with a pretty paragraph.

**Q. Ylogx LangSmith?** A. No. Ylogx = SQL shape + denied-tier fixtures.

**Q. Full BRD in the trace?** A. No. Query, chunk ids, answer. Credentials in env, not traces.

**Q. Who spots-checks?** A. Humans on a sample of generated tests. I do not invent a headcount.

**Q. Pass rate?** A. Not on the resume. I will not invent one.

**Q. LangSmith vs unit tests?** A. Unit tests catch crashes. LangSmith catches fluent ungrounded text and wrong retrieval.

**Q. Java tracing?** A. Same idea: structured spans. Intern was Python.

---

## 5. Why multiple scrapers (Firecrawl, Bing, DDG, Playwright) not one Google API

**Problem without it.** One scraper misses **families** of sites. One Google API hits rate limits and coverage gaps. Analysts needed ranked information across **200+** websites, not the first SERP card.

**Alternatives considered.** Single Google Custom Search. Firecrawl only. Playwright on every URL (slow, expensive, brittle). RSS-only.

**What I shipped (data flow).** (1) Planner decides which families to hit. (2) Firecrawl for crawlable pages. (3) Bing and DuckDuckGo for search snippets / alternate index. (4) Google Playwright when the page needs a real browser. (5) Parallel write into graph state. (6) Failed tool retries or degrades. (7) Ranker sees **all** survivors. (8) Writer uses ranked set. Resume names Firecrawl, Bing, Duck Duck Go, Google Playwright. Ranked **200+** websites.

**Why not one Google API.** Coverage gaps and rate limits. A JS-heavy page needs Playwright; a snippet may be enough from Bing. Frugality: fewer Playwright renders when snippets suffice.

**10× sites.** More ranker, **not** more Playwright on every URL. Cache scrapes. Cap concurrency. I did not shard crawlers. No IQVIA QPS on the resume.

**Failure mode.** All tools return the same syndicated paragraph (agreement looks high, diversity is zero). Playwright on a 200-site run without a budget. Treating an empty scrape as a document.

**Eight follow-ups.**

**Q. Why DuckDuckGo if you have Bing?** A. Different index, different gaps. Agreement across engines is a ranking feature, not a vanity list.

**Q. Is Playwright “Google”?** A. Resume: Google Playwright scraping — browser automation when search APIs are not the page.

**Q. Legal/ToS?** A. Research tools for analysts; I will not lecture scraping exploits. Stay on ranking and evals.

**Q. Why not crawl everything with Playwright?** A. Cost and latency. Parallel *search* plus selective render.

**Q. Ordering of tools?** A. Parallel, then rank. Serial Google-first is first-hit confidence.

**Q. Cache?** A. Cache scrapes; do not re-render the same URL every question. No TTL invented.

**Q. 10× domains?** A. Budget Playwright. Ranker quality matters more than a fifth scraper.

**Q. valAgent?** A. GitHub ETL-validator, not this 200+ metric. Do not mix.

---

## 6. Why ranking by agreement, not first-hit

**Problem without it.** Two high-ranked pages contradict. First-hit retrieval looks **confident**. That is how you ship “e-sign is fine” when another page says wet ink only.

**Alternatives considered.** Take the top SERP. Rank by PageRank-like popularity only. Rank by recency only. LLM “pick the best” without showing disagreement.

**What I shipped (data flow).** (1) All tool outputs land in state. (2) Score quality (source type, scrape completeness). (3) Score recency. (4) Score **agreement** across sources. (5) Down-rank isolates that contradict a cluster. (6) Writer must not hide disagreement. (7) Refuse a sentence without a retrieved span. (8) LangSmith shows empty scrape still feeding writer — ranking never sees junk as a vote. Resume: properly ranking information for result generation across **200+** websites.

**Why not first-hit.** First-hit is a demo. Agreement is the product. Recency without agreement still picks a fluent blog.

**10× scale.** Ranking cost grows with candidates; cap the candidate set. Do not 10× Playwright to 10× the ranker input. I did not invent a ranker ML model name.

**Failure mode.** Syndicated copies vote as independent agreement. Source-type ignored (forum vs spec). Writer averages two opposites into mush.

**Eight follow-ups.**

**Q. What is agreement?** A. Overlapping claims across independent sources, not three mirrors of the same wire story.

**Q. Who wins a real contradiction?** A. Do not paper over it. Surface disagreement; cite spans; abstain if ungrounded.

**Q. Recency vs agreement?** A. Both. A new post that contradicts a spec is not an automatic win.

**Q. Is the ranker an LLM?** A. Scoring quality, recency, agreement on graph state. I will not invent a second model card.

**Q. Hardest bug?** A. Ranking class, not a named outage. Primary Dive Deep if they only want one bug is still Ylogx. This is backup.

**Q. Metric?** A. **200+** sites ranked. No extra percent.

**Q. Why not PageRank only?** A. Popular ≠ correct for a BRD-adjacent research question.

**Q. 10×?** A. Better filters before rank, not a larger unfiltered pile.

---

## 7. Why NestJS + FastAPI + Postgres at Ylogx, not one Flask

**Problem without it.** Full-stack AI BI: custom report builder, SQL-RAG chatbot, **30** KPI dashboards, auth, **3** organizational tiers. One Flask app that does auth, CRUD, RAG, and Recharts APIs becomes a ball of helpers. Modular **roles** (who may call what) want a structured TypeScript API. Python wants the LangChain SQL RAG loop. Facts need joins, aggregations, transactions, **RLS** — that is Postgres, not a JSON file.

**Alternatives considered.** One Flask monolith. Django everything. NestJS everything including the LLM. Mongo for “speed.” GraphQL first (skills) because nested dashboards.

**What I shipped (data flow).** (1) Browser: React + Recharts dashboards + chatbot UI. (2) CloudFront → ALB → ECS. (3) NestJS: auth, RBAC, report CRUD, REST. (4) FastAPI: LangChain SQL RAG. (5) Redis cache-aside on the bot path. (6) Postgres with RLS + RBAC for **3** org tiers. (7) Dashboard GETs never call the LLM. (8) CI/CD rolls Docker tasks. Resume: Python, FastAPI, NestJS, REST, PostgreSQL. **40%** faster reports, **99.9%** uptime, analysis **+65%**, bot DB **−35%**, ops **+60%**, **sub-210 ms**.

**Why not one Flask.** Modular DI for role modules in NestJS. FastAPI for the Python AI path. Postgres for BI facts. REST because over-fetch was not the first pain — GraphQL is a skill, not the intern warehouse protocol. Mongo would make three-tier RLS a second product I did not ship.

**10× users.** Connection pooling, cache, RLS tests, ECS desired count. **I did not shard.** Not a bigger laptop. Not “we moved to EKS.”

**Failure mode.** LLM on the dashboard path. Superuser DSN in FastAPI. One Flask god-object that cannot test RBAC separately from RAG.

**Eight follow-ups.**

**Q. Why two languages?** A. NestJS for typed API/auth modules; FastAPI for SQL RAG. Live Code is still Java.

**Q. Why not Spring?** A. I did not rewrite Ylogx in Spring. Ideas are language-agnostic.

**Q. Why REST not GraphQL?** A. **30** KPIs did not need a graph query language first. Over-fetch was not why tiles were slow — origin and cache were.

**Q. Prisma?** A. Skills. Warehouse bullet is PostgreSQL. I will not claim Prisma shipped the intern warehouse.

**Q. Flask later?** A. Flask is on skills. This intern app was FastAPI + NestJS.

**Q. Warpflow / ConvBI?** A. GitHub adjacent, not the internship bullet. SQL RAG + RLS + Redis is the intern story.

**Q. 10× reports?** A. Faster generation is already **40%**. Scale the query path and pooling; do not put SQL RAG on every tile.

**Q. Kafka?** A. I did not operate Kafka. Do not invent a Ylogx topic.

---

## 8. Why SQL RAG (NL → SQL as user role), not dump tables into the LLM

**Problem without it.** Non-technical users could not pull analysis without an analyst. Dumping warehouse rows into a context window hits token limits and **hallucinates counts**. A free-form essay over raw facts cannot be RLS-enforced the same way a `SELECT` can.

**Alternatives considered.** Dump last 90 days of rows into the model (Deepak-style “highest KFC orders” trap). Fine-tune a model on CSV. Only dashboards, no NL. LLM with a **service-role** connection.

**What I shipped (data flow).** (1) User asks NL. (2) Redis: tier-scoped schema / repeat answers (**−35%** bot DB latency). (3) LangChain SQL RAG: schema + allowed metrics + “return SQL only.” (4) Allow-listed views, not `pg_catalog`. (5) Execute **as the user’s DB role** — RLS applies. (6) Parameterized, read-only, timeout, row cap. (7) Return result set (and show SQL; do not hide grain bugs). (8) Never a table-owner DSN for model SQL. Resume: AI chatbot using LangChain SQL RAG, analysis productivity **+65%**.

**Why not dump tables.** Token limits. Hallucinated totals. Prompt injection becomes a dump if the connection is superuser. Pre-aggregate in SQL; the model returns SQL. **+65%** is analysts stopped waiting on engineers — not “the bot is a superuser.”

**10× users / 10× data.** Cache schema and hot NL. Connection pool. Fail closed on unknown tables. Read replicas for dashboards is a **would-do**, not a shipped claim. I did not shard. I will not invent a warehouse size.

**Failure mode.** Hallucinated table name (fail closed). Syntactically fine SQL, wrong grain. Service-role execution.

**Eight follow-ups.**

**Q. Highest KFC orders last 3 months?** A. `GROUP BY` / `ORDER BY` / `LIMIT` in SQL. Do not dump 90 days of rows into the LLM. Same pattern as Ylogx.

**Q. Why LangChain not LangGraph here?** A. NL → schema → SQL → exec is a chain with guardrails. Not a 200-site research graph.

**Q. Eval?** A. Golden NL → expected SQL shape, not English BLEU. Not LangSmith.

**Q. Injection?** A. Parameterized. Allow-list. RLS. Deny catalog. Still parse/allow-list before bind.

**Q. Can the user see SQL?** A. Showing SQL is how wrong grain shows up. Hiding it hides the bug.

**Q. Write queries?** A. Read-only role. This intern bot is analysis, not UPDATE.

**Q. 10× tables?** A. Semantic layer / allow-list so the LLM cannot invent joins. Same RLS.

**Q. Java?** A. Same: model emits SQL string; Java executes with a role-bound DataSource. Prod was Python.

---

## 9. Why RLS in Postgres, not app-only `WHERE org_id`

**Problem without it.** App-only `WHERE org_id = ?` dies the first missed JOIN, the first generated query, the first replica path, the first intern who copies a handler. A BI chatbot that emits SQL is **exactly** that handler. Fast leak is not a delivered result.

**Alternatives considered.** NestJS middleware only. Views without RLS. “We always use the helper.” Trust the LLM to put the filter in.

**What I shipped (data flow).** (1) Caller authenticates at NestJS. (2) Map caller → **DB role** for their tier. (3) Connection / `SET ROLE` as that role (see live file for depth). (4) Postgres RLS policies on row read. (5) JOIN cannot outrun the policy. (6) LLM SQL runs on the **same** role. (7) Fixtures **deny** cross-tier rows. (8) Cache keys include tier so Redis cannot undo this. Resume: RLS and RBAC for **3 organizational tiers as role**.

**Why not app-only.** Defense in depth. Scaling ECS **without RLS scales leaks**. Table owner bypasses RLS — RAG DSN must not be owner.

**10× orgs.** Policy tests scale with tiers, not with a new WHERE in every handler. I did not shard by org_id. One primary with RLS is what shipped.

**Failure mode.** JOIN leak. Owner connection. Cached answer for the wrong tier (next cards).

**Eight follow-ups.**

**Q. Isn’t WHERE enough if we code review?** A. Generated SQL and JOINs will not go through your helper. RLS still filters.

**Q. Performance?** A. Policies are the product. I will not invent a p95. Bot latency we **did** move is **−35%** via Redis, still tier-scoped.

**Q. RLS vs encryption?** A. Different. RLS is which rows the role may see.

**Q. Sketch?** A. Yes — labeled sketch in `07-ylogx-horizon-live.md`, not a dumped prod schema.

**Q. Mongo RLS?** A. Mongo is a skill. Warehouse is Postgres.

**Q. IQVIA RLS?** A. Do not invent BRD multi-tenant fiction. RLS is Ylogx.

**Q. Bypass for admin analytics?** A. A higher **tier role**, still in the database, not a hidden superuser in the bot.

**Q. 10× tenants?** A. More RLS tests. Not shard-as-the-first-sentence.

---

## 10. Why RBAC three organizational tiers (role vs row)

**Problem without it.** Role without row: a “viewer” can still SELECT another org if the query is wide. Row without role: any authenticated user can hit a dangerous endpoint. Resume: **3 organizational tiers as role** — RBAC **and** RLS.

**Alternatives considered.** One admin flag. Only endpoint checks. Only RLS. Flatten to two tiers because three is hard.

**What I shipped (data flow).** (1) JWT (or session) at NestJS identifies the caller. (2) **RBAC**: which endpoints/actions (build report, ask bot, see which dashboards). (3) Map to one of **three** org-shaped tiers. (4) **RLS**: which rows even if the handler is wrong. (5) Bot, reports, dashboards share that isolation. (6) Tests: three roles before prod. (7) Do not invent table names as dumped schema — speak **org / team / user-shaped** isolation as the *shape*. (8) Result: **+65%** analysis you can trust; **99.9%** is not a faster leak.

**Why not role-only or row-only.** Role = what you can **do**. Row = what you can **see**. Three tiers because the product had three organizational levels, not because a blog said so.

**10×.** More members in a tier is still one policy. Do not explode custom roles per user as the first scale move. I did not shard.

**Failure mode.** Endpoint allows, RLS forgotten on a new table. Bot uses service role. Dashboard cached JSON without tier.

**Eight follow-ups.**

**Q. Role vs row in one breath?** A. RBAC = actions. RLS = rows. Both. Three tiers.

**Q. Exact tier names?** A. Resume does not print `org_admin`. I speak org/team/user-**shaped** isolation without dumping a schema I do not have.

**Q. Can RBAC live only in NestJS?** A. For HTTP verbs, yes. For SQL the bot emits, no — Postgres must enforce rows.

**Q. JWT in the database?** A. No. Token at API; role in DB. Do not put secrets in JWT payload.

**Q. Auth0?** A. Skills. I will not fake Auth0-as-Ylogx-prod. Tokens at the API is the honest line.

**Q. GraphQL authZ?** A. App was REST.

**Q. Conflict?** A. Backbone: I would not ship the bot without DB RLS. No named personal fight on the resume.

**Q. 10× roles?** A. Keep three tiers. Do not grow an unbounded role enum without tests.

---

## 11. Why Redis cache-aside on the bot path (−35%), not a bigger RDS first

**Problem without it.** Uncached SQL RAG hit Postgres on **every** NL turn. It felt like “the model is thinking.” The database was the cost. Repeat questions and schema lookups are cache-shaped.

**Alternatives considered.** Bigger RDS instance. Cache only at CloudFront (wrong layer for tenant JSON). Cache NL strings without tier. Skip cache and hope.

**What I shipped (data flow).** (1) NL in. (2) Build a cache key that includes **tier/role** + query fingerprint (not raw NL only). (3) Redis GET. (4) Hit: return if still the right tier. (5) Miss: run SQL RAG **as user role**. (6) SET. (7) Return. (8) Redis down: fail-open to Postgres for analysis **availability**; **never** fail-open RLS. Resume: reducing bot database latency by **35%** via caching. **I will not invent TTL or p95.**

**Why not bigger RDS first.** Frugality: repeat NL and schema metadata are a cache, not a larger instance. CloudFront is the **edge** for static; Redis **−35%** is **application** cache next to ECS. Different layer.

**10× QPS on the bot.** Cache hit ratio on hot questions; pool; still RLS on miss. I did not shard Redis or RDS. Do not cache tenant JSON at CloudFront.

**Failure mode.** Cached answer for the wrong tier. Caching a denied result as empty for everyone. Treating Redis as the system of record.

**Eight follow-ups.**

**Q. Why cache-aside not write-through?** A. App owns the fill: miss, query as RLS role, set, return. Warehouse writes are not the bot’s job.

**Q. TTL?** A. Resume does not name TTL. I will not invent one. Claim is **−35%**.

**Q. Key design?** A. Must include tier/role. Otherwise you leak. Sketch: `tier|role|sql-hash`, not a dumped prod key.

**Q. Schema cache vs answer cache?** A. Both are hot. Schema lookups every turn were part of the DB cost.

**Q. Dashboards use this Redis?** A. Bot path is the **−35%** claim. Dashboards are sub-210 ms without LLM — pooling + edge, not “the same bot cache.”

**Q. Rate limiter?** A. I did not ship one. Ylogx Redis is this cache. Independent SDE I Rate Limiter count stays 1, not UTA.

**Q. Redis vs Memcached?** A. We used Redis. I will not invent a bake-off.

**Q. 10×?** A. More cache, more pool, more RLS tests — not shard.

---

## 12. Why no LLM on the sub-210 ms dashboard path

**Problem without it.** **30** real-time KPI dashboards had to hold **sub-210 ms**. An LLM on a tile makes that number a lie. Operators needed tiles for **+60%** ops efficiency, not a paragraph.

**Alternatives considered.** “Just ask the bot to fill the chart.” Stream tokens into Recharts. One model call per KPI.

**What I shipped (data flow).** (1) Browser loads JS from CloudFront. (2) API GET for tile JSON. (3) ALB → ECS NestJS. (4) Pooled Postgres (RLS still on). (5) Optional app cache for hot aggregates. (6) Recharts render. (7) **No** SQL RAG in that loop. (8) Bot is a **separate** path with Redis **−35%**. Resume: **30** dashboards, **sub-210 ms**, **+60%** ops.

**Why not LLM on the tile.** Latency, cost, non-determinism, and isolation. Fluency is not a KPI. Sequence: dashboards first for ops; bot only behind RLS.

**10× tiles.** N+1 queries will kill you before the model does. `include` / one query / join. I will not invent a WebSocket fan-out bus for all 30 tiles unless they ask WS as CS — describe live-ish REST/poll.

**Failure mode.** Product asks to “AI-ify” the dashboard. That is a refuse: **sub-210 ms**.

**Eight follow-ups.**

**Q. Real-time means WebSockets?** A. Resume says real-time KPI dashboards. I describe poll/REST. I will not invent a socket bus that is not on the resume.

**Q. Can we LLM a tooltip?** A. Not on the hot path that defends sub-210 ms.

**Q. 210 vs 300?** A. Ylogx dashboards **sub-210 ms**. GiftedBooks API **sub-300 ms**. Do not mix.

**Q. 99.9% includes LLM?** A. Uptime is this serving path + CI/CD, not a model vendor SLA I invented.

**Q. Recharts SSR?** A. Tiles consume JSON. I will not invent an SSR metric.

**Q. N+1?** A. Do not loop findUnique per tile.

**Q. 10× dashboards?** A. Aggregate in SQL; cache; still no LLM.

**Q. Why 30?** A. Resume number. I will not invent a 31st.

---

## 13. Why CloudFront → ALB → ECS, not a single EC2, and why not Lambda for always-on BI

**Problem without it.** Users worldwide hitting one VM: no edge cache, no L7 routing, no task replace, patch-the-box. Always-on BI (**30** dashboards, chatbot, **99.9%**) is a long-lived process, not a 15-minute function.

**Alternatives considered.** Single EC2 + Nginx (Nginx is a **skill**, not the named Ylogx edge). Lambda per request. Hitting ECS for every JS bundle.

**What I shipped (data flow).** (1) Client DNS. (2) GoDaddy registrar ≠ Route 53 hosted zone; NS delegate. (3) Route 53 Alias → CloudFront or ALB. (4) CloudFront: TLS at PoPs, cache **static**. (5) ALB: L7 HTTP, target groups, health checks, ACM. (6) ECS tasks: NestJS + FastAPI Docker. (7) Redis / Postgres. (8) CI/CD rolling replace. Resume: CloudFront, ECS, Docker, CI/CD, **sub-210 ms**; GoDaddy DNS with Route 53 through an ALB. **99.9%** uptime.

**Why not single EC2.** I did **not** run EC2 by hand as the architecture. IE.in listed EC2 as CS. Tasks in private subnets; ALB/CloudFront public. **Why not Lambda:** cold start, time cap, always-on BI, long RAG loop. Fine as CS. Not on the Ylogx bullet.

**10× traffic.** CloudFront offloads static. ECS **desired count**. ALB health checks. Do not cache **tenant JSON** at the edge. I did not go multi-region. I did not shard. No AWS bill.

**Failure mode.** CloudFront 403 vs ALB 502 vs origin 5xx vs RLS 403 — isolate the hop. DNS misconfig class (live file). Caching private JSON at the edge.

**Eight follow-ups.**

**Q. CloudFront vs Redis?** A. Edge vs application cache. **−35%** is Redis on the bot. Sub-210 ms is edge + pooling + no LLM.

**Q. NLB?** A. ALB is L7 HTTP. NLB is L4. We used ALB.

**Q. Fargate vs EC2 launch type?** A. I will not invent which. Task definition: image, CPU/mem, ports, env.

**Q. IAM?** A. Task role for AWS APIs; env for DB URL. Never commit creds.

**Q. Public subnet?** A. Users never speak task IPs. ALB public; tasks private. I will not dump a named VPC.

**Q. HTTP/3?** A. CS if they push. I will not claim HTTP/3 in prod.

**Q. Nginx?** A. Skills. Named hop is CloudFront → ALB → ECS.

**Q. 10×?** A. Desired count + CDN + pool. Not one bigger EC2. Not Lambda for the dashboard.

---

## 14. Why Docker / ECS; Kubernetes is skills, not a Ylogx bullet

**Problem without it.** “Works on my laptop” is not **99.9%**. You need a repeatable image, a service that keeps desired count, rolling replace, ALB attachment.

**Alternatives considered.** SSH to a VM. EKS because Kubernetes is on the skills list. Compose on one box forever.

**What I shipped (data flow).** (1) CI builds a Docker image. (2) Push. (3) ECS task definition: image, CPU, memory, env, ports. (4) Service keeps desired count. (5) Attach ALB. (6) Rolling replace. (7) Cluster is the pool. (8) Scale = desired count, not resize the intern laptop. Resume: Docker containers, ECS, CI/CD.

**Why not EKS-as-Ylogx.** Kubernetes is **listed**. I was **not** platform owner of a cluster. I will not say “my EKS cluster.” Intern path = **ECS + Docker**.

**10×.** More tasks. Still one primary Postgres with RLS. **I did not shard.** I will not invent Fargate vs EC2 launch, vCPU, or ECR vs Docker Hub as a brag.

**Failure mode.** Faking k8s ops. Putting secrets in the image. Desired count 1 with no health check.

**Eight follow-ups.**

**Q. You listed Kubernetes.** A. Listed. Intern evidence is ECS + Docker. I will not fake a prod EKS story.

**Q. What is a task vs service?** A. Task = running copy. Service = keep N healthy, rolling deploy.

**Q. GitHub Actions?** A. Skills / CI/CD on resume. I will not invent a 20-stage textbook pipeline.

**Q. Argus containers?** A. Argus is containerized **20+** cameras — different product. Ylogx is the ECS intern story.

**Q. Local Docker Compose?** A. Dev. Prod serving is ECS.

**Q. Sidecar service mesh?** A. I will not invent Istio.

**Q. 10× images?** A. One app image, more tasks. Not a microservice explosion I did not ship.

**Q. Java on ECS?** A. Could. This intern image was Python/TS.

---

## 15. Why GStreamer 60 FPS; UDP-family honesty vs TCP for rover video

**Problem without it.** Operators need a live camera on a semi-autonomous Mars rover. Naive TCP MJPEG / Flask webcam stalls on loss: TCP retransmits, the picture freezes, **60 FPS** dies. ERC date does not move. Dirt is not Gazebo.

**Alternatives considered.** HTTP MJPEG over TCP. Raw ROS image topics over a lossy link without a real pipeline. Record-only, no live operator feed.

**What I shipped (data flow).** (1) Camera source. (2) GStreamer pipeline. (3) UDP-family transport — drop-over-stall. (4) Operator display / autonomy consumers. (5) Separate from ZED mapping node. (6) Field test: dust and lighting. (7) Supporting GitHub `Gstreamer-UDP` is a **webcam analogue**, not a second product. (8) Result: real-time camera feed at **60 FPS**. Obstacle **+40%** is the **pipeline**, not a weights file.

**Why not TCP as the live video default.** TCP is reliable ordered — good for reports, bad for live video when the alternative is freeze. UDP is datagrams, no handshake. Honest CN example for GFG sde-1-17. Argus **24 FPS** is a **detector budget**, not this transport. I will not invent a radio spec.

**10× cameras on a rover.** You rarely 10× rover cams the way Argus 10× plant cams. If they mean 10× resolution: downsample for viz, keep what planning needs. I did not shard a video cluster.

**Failure mode.** Operator feed looks live; that is not the costmap (next cards). Treating TCP retry as “more reliable video.”

**Eight follow-ups.**

**Q. TCP vs UDP one sentence?** A. TCP: reliable ordered byte stream. UDP: datagrams, lossy, low latency. Live video prefers drop-over-stall.

**Q. Is GStreamer UDP on the resume?** A. Resume: 60 FPS with GStreamer. UDP-family is the honest transport story; public repo supports it.

**Q. WebRTC?** A. I will not invent WebRTC on the rover.

**Q. 60 vs 24?** A. Horizon camera **60 FPS**. Argus YOLO **24 FPS**. Do not mix.

**Q. Java GStreamer?** A. Rover was ROS2 Python/C++. Live Code is Java. CN answer can stay conceptual.

**Q. Why not just ROS image_raw?** A. Integration bus is ROS2. Holding 60 FPS in the field needed a real pipeline, not a notebook.

**Q. Packet loss?** A. Drop frames; do not stall the operator. I will not invent a BER number.

**Q. 10× FPS?** A. 60 is the resume number. I will not claim 120.

---

## 16. Why ZED 2 at 2M+ pts/s; downsample viz vs keep density for costmap

**Problem without it.** A pretty point cloud on a laptop is not occupancy the planner can trust. Stereolabs ZED 2 produces **2M+** data pts/sec. That cloud **cannot all go to a remote laptop**. If you thin it everywhere, the local costmap lies. If you ship it all offboard, the link melts.

**Alternatives considered.** Viz-quality cloud everywhere. Skip dense mapping, drive on camera pixels. Buy another depth sensor (next card).

**What I shipped (data flow).** (1) ZED 2 depth/cloud. (2) ROS2 mapping node. (3) **Dense** cloud stays for **local costmap**. (4) **Downsample** for RViz / offboard viz. (5) Gazebo for sim. (6) Field for dust. (7) Time-sync with the camera feed — stale occupancy is the bug class. (8) Planner consumes costmap, not the pretty cloud. Resume: 3D environmental mapping, **2M+** pts/sec, RViz and Gazebo.

**Why not one resolution.** Viz and planning are different consumers. Frugality: student hardware, not a cloud GPU bill I will invent.

**10× points.** More thinning for viz; **do not** thin the local costmap just to make RViz smooth. I did not shard a map.

**Failure mode.** Operator sees a healthy feed; occupancy is last second’s rocks. That is Horizon’s live bug class.

**Eight follow-ups.**

**Q. Why ZED not a webcam?** A. Depth → occupancy. A webcam is the GStreamer story, not the map.

**Q. All 2M+ to RViz?** A. No. Downsample viz; keep density for local costmap.

**Q. Gazebo = field?** A. No. Lighting and dust differ. Field time existed.

**Q. YOLO on Horizon?** A. No. mAP is Argus. Horizon is occupancy and fusion.

**Q. Units of 2M+?** A. Resume: data pts/sec. I will not invent a voxel size.

**Q. Java octree?** A. I can analogize a grid in Live Code. Field code was ROS2.

**Q. 10× map size?** A. Local costmap window, not a global pretty mesh.

**Q. Missed ERC?** A. Resume does not state a miss. **17th / 80+**. I will not invent one.

---

## 17. Why costmap fusion vs extra hardware

**Problem without it.** Perception without planning is a fast video that still collides. Bump-and-turn is not **−55%** collision risk. Extra LiDAR the week of ERC is a purchase order against an **immovable date**.

**Alternatives considered.** Another sensor. Giant vision model as the stack. Pixel-red stop. Wait for a perfect map.

**What I shipped (data flow).** (1) Camera 60 FPS (operator). (2) ZED occupancy. (3) Other onboard sensors into **fusion**. (4) Costmap. (5) Predictive / planning algorithms on that map. (6) Actuators. (7) All ROS2 nodes. (8) Result: obstacle detection **+40%**, collision risk **−55%**, **17th / 80+**. Frugality + Bias for Action: software fusion vs extra hardware.

**Why not extra hardware as the default spend.** Date does not wait. Fusion on what we had. A weights file is **one node**; ERC is localization + planning + comms.

**10× sensors.** Still fuse into one costmap. Do not 10× hardware as the interview default. I will not invent a BOM.

**Failure mode.** Stale costmap while video looks live. Starting a new middleware in May 2024.

**Eight follow-ups.**

**Q. Frugality or Bias?** A. Both map here. Primary Bias/Deliver is Horizon. Frugality primary is Ylogx Redis — do not double-primary.

**Q. Predictive algorithms?** A. Resume wording. Planning on fused occupancy over time, not stop-if-pixel-red.

**Q. Who owned what?** A. I owned camera, mapping, costmap as core software. 17th is a **team** score.

**Q. Hardware wanted LiDAR week-of?** A. We fused what we had. Collision still **−55%**. No named fight.

**Q. Safety skipped?** A. Compromise is software vs PO, **not** skip safety.

**Q. 10× speed of rover?** A. Then the stale-occupancy class gets worse — time-sync first.

**Q. Sim-to-real?** A. Would invest more in dust lighting. Same ROS2 split. Still ship 60 FPS + costmap first.

**Q. Java planner?** A. Grid analog in Live Code if they want DS. Prod was ROS2.

---

## 18. Why YOLOv9 one-stage vs Detectron / two-stage (24 FPS, 20+ cameras)

**Problem without it.** Industrial PPE and attendance. Two-stage (propose regions, then classify) wins laptop accuracy and **loses** **24 FPS × 20+** feeds. A detector that is late is not live.

**Alternatives considered.** Detectron / Faster R-CNN family. OpenCV color/HOG as the detector (will not take you to **89% mAP**). LLM caption on the frame. Heavier backbone × 20 copies.

**What I shipped (data flow).** (1) Decode/resize with OpenCV. (2) YOLOv9 one-stage: box + class in one pass. (3) Multi-scale maps; NMS. (4) Prefer drop a stale frame over a delayed alert. (5) Event to Postgres (camera, class, conf, ts, box). (6) Alert path. (7) Containers for **20+** feeds. (8) Gate: **73% → 89% mAP** on **15,000+** images **before** scale. Violations **−50%**, compliance **2×**. README 404 — no invented routes. I will **not** invent Haar. I will not claim I benchmarked Faster R-CNN on 20 cameras.

**Why one-stage.** End-to-end budget = decode + infer + NMS + I/O. Two-stage is the accuracy-on-a-laptop trap. Fluency of an LLM is not mAP.

**10× cameras.** Do not scale **73%** mAP. Workers per stream or batch; thinner model that still holds **24 FPS**. Postgres events, not video blobs. Wrong alerts at 20 cameras scale **alarm fatigue**.

**Failure mode.** Heavier model dies at camera 12. Alerts before NMS. LLM-on-frames.

**Eight follow-ups.**

**Q. Why not Detectron?** A. 24 FPS across 20+ feeds. I did not print a Detectron bake-off. One-stage is the defense.

**Q. Haar / HOG?** A. Naive baseline that cannot take industrial PPE to 89% mAP at 24 FPS. I will not invent a Haar chapter. OpenCV still decodes.

**Q. TensorFlow?** A. Skills. Argus resume is **YOLOv9**. I will not fake a TF serving story.

**Q. mAP vs −50%?** A. mAP is the detector gate. **−50% / 2×** are **site** outcomes after humans got alerts. Not the same number.

**Q. NMS?** A. One object, many boxes. Keep highest conf; suppress neighbors. Too aggressive merges two workers.

**Q. Purplle YOLOv8?** A. Prep-only unless confirmed. Resume is YOLOv9 15k / 73→89.

**Q. EKS?** A. I did not run EKS here. Containerized is the claim.

**Q. 10× FPS?** A. 24 is the budget. Drop stale frames.

---

## 19. Why 73% was not shippable; 15k images → 89% before scale

**Problem without it.** **73%** mAP is a model card. You do not page a floor on it. Lighting / PPE color / dusk are dataset problems. Scaling **20+** cameras at 73% scales **wrong alerts**.

**Alternatives considered.** Ship the demo GIF. Add a heavier backbone. Threshold the OpenCV pipeline. Call 73% “progress” and wire alerts.

**What I shipped (data flow).** (1) Honest start: **73%** mAP. (2) Treat it as **not shippable** for safety (negative feedback / mistake I will own). (3) **15,000+** images, iterate data + eval gate. (4) Held-out mAP to **89%**. (5) Confirm **24 FPS** under multi-cam. (6) **Then** support **20+** feeds. (7) Alerts after NMS. (8) Site: violations **−50%**, compliance **2×**. I will not invent a train/test split the resume does not name. I will not invent Haar as the quoted jump.

**Why not ship 73%.** Highest Standards / Are Right. Success and Scale: gate then multiply. 89% mAP ≠ 89% of pixels.

**10× cameras.** Still refuse to multiply a 73% detector. Would add a held-out **camera** so 89% is not leak — say **would**, resume does not name that split.

**Failure mode.** Alert fatigue. Treating site **−50%** as if it were mAP.

**Eight follow-ups.**

**Q. Describe a mistake.** A. I treated 73% as progress. Gate + 15k images before scale.

**Q. Last negative feedback.** A. Same: 73% is not a page-the-floor number.

**Q. 95% mAP?** A. Not on the resume.

**Q. Precision/recall?** A. I will not invent beyond mAP.

**Q. Why data not architecture?** A. Lighting and PPE color. Architecture was already one-stage YOLO for FPS.

**Q. LLM to label 15k?** A. I will not claim an auto-label mill. Resume is training 15,000+ images.

**Q. 10× images more?** A. Diminishing returns; keep the FPS gate. No invented dataset size beyond 15k+.

**Q. Java training?** A. Detector is Python. Live Code is Java.

---

## 20. Why Postgres event logs, not video-in-DB

**Problem without it.** Safety needs an **audit trail**: which camera, which class, when, box, attendance. Video blobs in Postgres blow storage, backups, and RLS stories you did not ship. Files on disk with no query path cannot answer “what fired on camera 7.”

**Alternatives considered.** Store MP4 in bytea. Only files. Only a dashboard GIF. Mongo because “video metadata is document-shaped.”

**What I shipped (data flow).** (1) Frame decoded. (2) YOLO + NMS. (3) Event row: camera, class, conf, timestamp, box. (4) Postgres insert. (5) Alert consumer reads events. (6) Video stays **off** the database (object store / files — I will not invent a named bucket). (7) Attendance as events, not a clip. (8) Containerized workers. Resume: PostgreSQL logging, **20+** camera feeds.

**Why not video-in-DB.** Wrong storage class. Events are queryable. Video is bulk. Mongo is a skill, not this log.

**10× cameras.** More event rows, still not blobs. Index time+camera. I did not shard. I will not invent retention days.

**Failure mode.** Alerts with no persist. Public `/stream` URL (auth the dashboard; 404 README — no invented routes).

**Eight follow-ups.**

**Q. S3?** A. Object store if they ask as CS. Facts/events stayed Postgres. I will not invent an intern S3 design as a Ylogx/Argus merge.

**Q. Time-series DB?** A. Would-do. Shipped: Postgres logs.

**Q. ProtoBuf for frames?** A. Skills: reasonable for **metadata**, not the JPEG. Dashboards can stay JSON.

**Q. RLS on Argus?** A. Deep RLS is Ylogx. Camera feeds are still sensitive — auth, no public URLs.

**Q. Notification LLD?** A. Event → persist → notify. Nitesh-shaped. Resume: Postgres, 20+, **−50%**.

**Q. 10× retention?** A. I will not invent a retention SLA.

**Q. Kafka topics for events?** A. I did not operate Kafka.

**Q. Why not only files?** A. No audit query. Safety needs logs.

---

## 21. Why GiftedBooks RAG on the student’s PDF, not a syllabus-guessing LLM; PYQ is analytics

**Problem without it.** Students in VR labs still have doubts. A generic tutor hallucinates a syllabus. Dumping a textbook into context misses **sub-300 ms** and invents formulas the professor did not use. Mixing another student’s notes is a trust failure.

**Alternatives considered.** Generic ChatGPT tutor. Stuff-the-PDF. LLM guesses exam topics from vibes. AegisAI README (GitHub **mismatch** — resume wins).

**What I shipped (data flow).** (1) Auth. (2) Student uploads **their** PDF. (3) Chunk/embed **once**. (4) Vector + metadata retrieve. (5) Small generate, grounded. (6) **Sub-300 ms** API. (7) Per-user isolation. (8) **PYQ topic ranker is separate** — deterministic analytics on past papers, not an LLM guessing the syllabus. (9) VR labs + avatars are the client. (10) Hosting **99.5%** uptime. Resume: doubts hours → **3–10 min**; reading **+35%**; engagement **+50%**; comprehension **2.5×**. Skills include FAISS — this is the **skill-lane** store, not Azure, **never Qdrant**. I do not claim LangSmith here.

**Why not syllabus-guessing.** Earn Trust / Customer Obsession. PYQ honesty is analytics. Latency is retrieve + small generate.

**10× users / 10× pages.** Embed once; cache retrieval; do not re-embed every question. Smaller chunks + top-k. Isolation still per user. I did not shard. No student headcount on the resume — I will not invent one.

**Failure mode.** Chunks too big miss **sub-300 ms**; too small drop page 14’s worked example. Cross-user retrieval. Claiming 99.9% (that is Ylogx). Mixing AegisAI.

**Eight follow-ups.**

**Q. GitHub says AegisAI.** A. Mismatch. Resume wins. Stop mixing.

**Q. Azure Search?** A. IQVIA. GiftedBooks is the student’s file.

**Q. FAISS?** A. Skills. Vector + metadata RAG. I will not fake a FAISS cluster topology.

**Q. LangSmith?** A. Would-add citation eval. Do not claim it shipped here.

**Q. 99.5 vs 99.9?** A. GiftedBooks **99.5%**. Ylogx **99.9%**. Do not convert nines.

**Q. PYQ inside the LLM?** A. No. Separate analytics.

**Q. 10× PDFs per user?** A. Same ingest-once. Still isolate.

**Q. Java?** A. Prod TS/Python + VR. Live Code Java. Sub-300 ms is the API number, not a JVM benchmark.

---

## 22. Why StratifyLabs browser inference / marketplace

**Problem without it.** CV people spin a full GPU training loop to tweak a scene, a URDF, or a small inference. Colab-per-person. Native Gazebo-only excludes people who are not ROS. A one-model demo dies with one intern.

**Alternatives considered.** Everyone gets a training box. Horizon-style Gazebo as the SaaS (wrong product). Marketplace of 50 GPUs per user. Generic chatbot instead of scene-conditioned bots.

**What I shipped (data flow).** (1) Next.js client (GitHub README is default Next — **resume wins**). (2) 3D sim lab, WebGL URDF editor. (3) **Browser-based inference** for small models. (4) Big train jobs **off** the request path. (5) Marketplace catalog **50+** pretrained models/datasets — a **catalog**, not 50 GPUs. (6) Community profiles. (7) Gemini RAG voice bots as 3D characters on **current sim state**. (8) Result: ML iteration **−30%** (time, not cluster size). Think Big = experiment → share → reuse. No LangSmith on this bullet. No GTM number. Do not merge Horizon ROS2 **60 FPS**.

**Why browser inference.** Invent and Simplify: iteration is the product. Frugality optional: do not buy a box for every tweak.

**10× users / 10× models.** Catalog grows; inference stays small-in-tab. I will not invent cluster size. I did not shard. RAG bot must not exfiltrate another user’s datasets — deep RLS wording stays **Ylogx**.

**Failure mode.** Model OOMs in the tab. Bot answers last week’s scene. README fiction.

**Eight follow-ups.**

**Q. Three.js?** A. Skill. Resume claim is URDF + WebGL + the lab.

**Q. Same as Horizon Gazebo?** A. No. Horizon is a field rover, **17th / 80+**. Stratify is a browser CV lab.

**Q. 50+ GPUs?** A. 50+ **catalog items**.

**Q. −30% is FPS?** A. No. Iteration **time**. Argus owns FPS. Horizon owns 60 FPS camera.

**Q. karyanode?** A. GitHub module, not a Stratify resume metric.

**Q. Stratify RLS?** A. Resume does not name it. Point depth to Ylogx. Still isolate users.

**Q. 10×?** A. Keep train off the click path. Eval bots on **current** sim state (would-add).

**Q. Java?** A. Client TS; inference Python/CV. Live Code Java.

---

## 23. JWT vs sessions (Standard CS + Ylogx)

**Problem without it.** Two ECS tasks without a shared session store: sticky sessions or lost logins. BI APIs need a caller identity to map to a **DB role**. Cookies auto-sent → CSRF. Tokens in localStorage → XSS risk (defensive, no theft recipe).

**Alternatives considered.** Server sessions only on one box. JWT forever with secrets in the payload. Auth0-as-prod because it is on skills.

**What I shipped (data flow).** (1) Login at NestJS. (2) **JWT-shaped** identity at the API (skills: JWT, OAuth 2.0, Auth0 — **tokens at the API**; I will not fake Auth0-as-Ylogx-prod). (3) RBAC on endpoints. (4) Map to Postgres role. (5) RLS on rows. (6) Bot SQL as that role. (7) Dashboards: same identity, no LLM. (8) Secrets: env / ECS task role. Cookie flags if they ask sessions: Secure, HttpOnly, SameSite. Refresh not in localStorage if you can avoid it.

**Why JWT vs sessions (CS table).** JWT scales without a session store; **revocation is harder** (short `exp` and/or denylist). Sessions need Redis once you have two boxes. CSRF: cookie auto-sent vs Bearer header not auto-sent by a random site. Kill-session-now prefers sessions or short JWT + denylist. Bhavya HM can stay a session if they never asked for tokens.

**10× tasks.** Shared session store **or** JWT. Still RLS. I did not shard auth. I will not invent a denylist TTL.

**Failure mode.** Secrets in JWT payload. RLS skipped because “the JWT has org_id.” XSS vs CSRF confused.

**Eight follow-ups.**

**Q. JWT vs sessions one table?** A. Store: server vs token-is-the-session. Revoke: delete row vs exp/denylist. CSRF: cookies vs Bearer.

**Q. Auth0?** A. Listed. Intern evidence is JWT/RBAC at NestJS + RLS. I will not fake Auth0 ops.

**Q. OAuth?** A. Skills. `state` is CSRF on the redirect. Deep product story is Ylogx RLS.

**Q. XSS vs CSRF?** A. XSS: attacker script in the page. CSRF: browser uses existing cookie. Encode output, CSP, HttpOnly. SameSite / CSRF token / Bearer.

**Q. CORS?** A. Browser rule. Allow-list. Not tenant isolation — **RLS** is.

**Q. Spring login layers?** A. Bhavya HM: validators without if-else. AuthZ `if (ADMIN)` does not live in the façade — that is RBAC/RLS.

**Q. Rover JWT?** A. No. Do not expose unauthenticated field telemetry. Point RLS to Ylogx.

**Q. 10×?** A. Short-lived tokens + RLS. Not a bigger JWT.

---

## 24. Skills listed but weakly evidenced — honest lines

I will not fake a production story. Listed ≠ intern bullet.

**Java.** Languages line. Live Code is Java. Internships shipped Python FastAPI, TypeScript NestJS/React, ROS2 Python/C++. Same HashMap/heap/graph ideas. I did not ship Spring LangGraph or a JVM warehouse.

**Kubernetes.** Skills. Ylogx intern path is **Docker + ECS**. I was not cluster owner. Not “my EKS.”

**GraphQL.** Skills. Ylogx BI was **REST**. Thirty KPIs did not need GraphQL first.

**ProtoBuf.** Skills. Dashboards stayed JSON. Honest maybe: Argus **frame metadata**, not the JPEG.

**MongoDB.** Skills. Ylogx warehouse is **PostgreSQL** (joins, aggregations, transactions, RLS). Redis is cache, not SoR.

**TensorFlow.** Skills. Argus resume is **YOLOv9**. Stratify is browser inference + Gemini bots. I will not fake TF Extended.

**FAISS.** Vector DB on skills. IQVIA BRDs are **Azure AI Search + GraphDB**. GiftedBooks is vector + metadata RAG on the student’s PDF — skill-lane, not a FAISS-ops novel. **Never Qdrant.**

**Neo4j specifics.** Skills: Graph DB (Neo4j). IQVIA bullet: **GraphDB**. I speak GraphDB. I will not fake Cypher ops as DBA.

**OAuth / Auth0.** Skills. Ylogx: tokens at the API, execution as DB role. Named hop is CloudFront → ALB → ECS. I will not fake Auth0 tenant admin.

**Nginx.** Skills. Named edge is **CloudFront**.

**Prisma.** Skills. Warehouse bullet is PostgreSQL.

**WebSockets.** Skills. 30 KPIs: poll/REST unless they ask WS as CS. No invented pub/sub fan-out.

**Kafka.** Not an intern I operated. igreaper CS only: order is per partition. Adjacent: Celery + Redis if they stretch async jobs — still not Kafka.

**InstaRecon / PhiSiFi.** Not a pitch. Security-awareness demo, consent, no production attacks. Then Stratify / Argus / Ylogx / IQVIA.

**Eight follow-ups (meta).**

**Q. Why list them?** A. Course/lab/adjacent use. I will say where intern evidence actually is.

**Q. Can you do Java at Amazon?** A. Live Code is Java. I write Java in the editor. Production intern was Python/TS. I will not pretend otherwise.

**Q. GraphQL vs REST holy war?** A. REST shipped. GraphQL if nested over-fetch becomes the pain — it was not the first cut.

**Q. Mongo vs Postgres holy war?** A. BI facts + RLS → Postgres.

**Q. FAISS vs Azure?** A. Azure for IQVIA BRDs. FAISS listed. Different products.

**Q. k8s interview question?** A. I can speak pods vs tasks as CS. My shipped orchestrator is ECS.

**Q. Auth0 deep dive?** A. Redirect to JWT + RLS. Do not invent a dashboard I did not operate.

**Q. ProtoBuf vs JSON?** A. JSON on BI tiles. ProtoBuf later for high-frequency internal payloads.

---

## 25. “How would you scale this project?” — 10×, honest limits

Job **10454435** still none. This is how I talk **10× users / cameras / pages** without sharding theatre.

### IQVIA — 10× sites / 10× BRD pages

Ten times the open web is **not** Playwright on every URL. Cap fan-out. Cache scrapes. Ranker quality and agreement beat a fifth scraper. Checkpoint so a 10× run does not restart from zero. Ten times the BRD pages: do not stuff them; hybrid retrieve a small set; hop bounded; **do not re-embed every question**. Freeze an eval slice before a fourth search tool. LangSmith still fails span-less sentences — wrong answers must not scale. Limits: no IQVIA latency % on the resume; I did not shard Azure; I will not quote a bill; confidential BRDs still do not belong in traces. Java would wrap the same retrieval interfaces; intern was Python.

### Ylogx — 10× users

Cache and connection pooling and **RLS tests**, not “we shard” — **I did not shard**. Redis still **tier-scoped** or 10× users is 10× leaks. Dashboards stay **sub-210 ms** with **no LLM** on that path; 10× tiles is N+1 and aggregates, not SQL RAG. ECS **desired count**, CloudFront for static, ALB health checks. Do not cache tenant JSON at the edge. SQL RAG still executes as the user role. Read replicas for dashboards = would-do, not shipped. Limits: no p95, no TTL, no AWS bill, no EKS, no Kafka, **99.9%** is not a miss I will invent. **40% / +65% / −35% / +60% / 30 dashboards** stay the numbers I defend.

### Argus — 10× cameras

**20+** is already the resume scale. 10× more feeds: do **not** scale **73%** mAP. Hold **24 FPS**; drop stale frames; one-stage YOLO; containers; **Postgres events not video**. Wrong alerts scale harm. Auth on streams; no 404-README routes. Limits: no EKS, no LLM-on-frames, no invented precision, no Haar chapter. Success and Scale is gate **89%** then multiply.

### Horizon — 10× (sensors / resolution, not “users”)

A rover is not a SaaS MAU problem. 10× points: downsample viz harder; **keep density for the local costmap**. 10× sensors: still **fuse**, do not default to a PO. 10× operator bitrate: UDP-family drop-over-stall, not TCP freeze. Limits: Gazebo ≠ dirt; date immovable; no missed ERC; no radio spec; **60 FPS**, **2M+** pts/s, **+40% / −55% / 17th of 80+**. mAP belongs to Argus.

### GiftedBooks — 10× users / 10× pages

Embed once per PDF; cache retrieval; retrieve + small generate so **sub-300 ms** stays plausible. Isolation **per user** — 10× students is 10× chance to mix notes if you get that wrong. PYQ stays analytics. Limits: no student headcount; **99.5%** not 99.9%; no LangSmith claimed; no AegisAI; no Qdrant; no Azure stolen from IQVIA.

**Closing line if they push shard.** I know what sharding is. I did not shard these intern systems. The honest 10× is cache, pooling, eval gates, RLS, FPS gates, and not putting an LLM on a latency path that already has a resume number.

---

*End of fragment. Do not edit Answer-BIBLE.md from here. R3/R4. Job 10454435 still none. No Qdrant shipped. No EKS-as-Ylogx. No shard. No TTL/p95/bill.*