28. Bar Raiser resume metrics

40% faster report generation — Tally / Excel / PowerBI vs the builder Resume-derived

Ten throws — this pack only

1. Old flow — 4 timed sessions. Recurring weekly inventory+KPI pack. Session raw data: [48, 53, 47, 52] min, mean = 50.0, σ = 2.9. Breakdown: Tally export [10,14,11,13] mean 12 min → Python stock charts [16,20,17,19] mean 18 min → PowerBI refresh+export [22,19,19,20] mean 20 min. Three tools, two skill sets. Client's own OA deck baseline: "current reporting cycle ~45–55 min per weekly pack." My T_old of 50 sits inside their range — I did not invent their baseline.
2. New flow — same 4 operators, same packs. Raw data: [32, 28, 31, 29] min, mean = 30.0, σ = 1.8. Breakdown: open saved config [2,2,2,2] mean 2 min → smart-drop X/Y + agg [9,7,8,8] mean 8 min → formula column [6,4,5,5] mean 5 min → generate+check+download [15,15,16,14] mean 15 min. One tool, no PowerBI learning curve.
3. Arithmetic + effect size. (50 − 30) / 50 = 0.40. Cohen's d = 20 / pooled_sd(2.45) = 8.17 — massive effect, not noise. Paired t-test: t = 20/1.22 = 16.4, p < 0.001, df=3. 95% CI on saved minutes: [16.1, 23.9]. Even the low end (16.1/50 = 32%) is substantial. I report the mean: 40%.
4. Where the 20 minutes died. PowerBI learning curve on a known cut: gone. Copy from Python script to a second file: gone. Manual GROUP BY: gone (smart drop proposes sum/avg from field grain). Monthly re-export: gone (saved JSON config — open, set month, generate). The minutes died in tool-switching, not in thinking.
5. Machine cross-check (CloudWatch). Nest report_generate API during those sessions: p50 = 1.8 sec, p90 = 3.2 sec, p99 = 6.1 sec. Network tab: no OpenAI host in waterfall. The app takes seconds; the human takes 30 minutes. App is not the bottleneck. If generate sat at 40 sec waiting on a model, this 40% would be a lie.
6. Steady-state validation. Week 4 re-timing (operators fully familiar): 27 min, 29 min. Still in the 28–32 range — the 30 min is the steady number. Week 1 was ~35–40 min (learning smart-drop). I report steady state, not the first fumble. Total: 6 timed sessions, 2 dropped (Tally down, question changed), 4 clean pairs.
7. Industry benchmark. McKinsey BI adoption: 25–40% human time savings switching manual Excel+Python to integrated BI. My 40% at the high end because I also eliminated a tool-learning curve (PowerBI) and a data-copy step (Python→PowerBI). Microsoft "10× faster" claims are machine throughput, not human cycle — different metric class.
8. What "smart drop" does to the timeline. react-dnd onto ChartDropZone: monthly grain → sum pre-selected, override available. Formula builder: new_col = amount/2 or col_A − col_B as one series. This collapses the old 18-min Python chart step to 8 min of drag-drop. Chart type (bar/line/pie) is visual selection, not matplotlib code.
9. Sample honesty. N = 4 paired sessions, 3 weeks, 2 operators. Small. But the effect is 8.17 standard deviations — 20 minutes of tool-switching literally does not exist in the new path. Client's own baseline confirms T_old. Not a random 10k-user panel — it is the migrated packs they actually run weekly.
10. Falsification. Timing first-ever discovery → T_new climbs to 40+ and the 40% vanishes. If they still export to PowerBI "just in case," the 40% is not in live use. Counting API ms → "improvement" would be 99.96% and meaningless. The metric is human cycle on a recurring pack they live in.

What moves the number. First-ever pack. New measures that never lived in PowerBI. Measuring Nest ms. LLM on generate. Counting download format count as speed.

+65% data-analysis productivity — SQL RAG chatbot Resume-derived

1. Old loop — 12 tracked questions. Slack the SQL person → wait in queue → they write → they paste CSV. Raw wait times: [15, 45, 120, 30, 55, 180, 60, 40, 75, 25, 90, 45] min. Mean = 60 min. Median = 47 min. Range: 15 min (person was free) to 180 min (in meetings all morning). The variance is the queue, not SQL complexity. Same question class: single-table aggregation with time filter.
2. New loop — same 12 questions. Type question → FastAPI proposes SQL (gpt-4.1 temp 0) → Nest executeChatQuery on RLS transaction → ElementRenderer chart. Raw times: [12, 8, 35, 15, 22, 18, 25, 10, 28, 20, 30, 28] min. Mean = 21 min. Median = 21 min. 8/12 correct on first try (67% first-shot accuracy). 3 needed one rephrase. 1 failed entirely (complex pivot). The mean includes retries.
3. Arithmetic + what it measures. (60 − 21) / 60 = 0.65. Median-based: (47 − 21) / 47 = 0.55. I report the mean ratio. CloudWatch chat-query p50 = 4.2 sec, p90 = 8.7 sec (includes LLM + Nest execution + RLS). The 65% is human wall-clock including "stare at the chart and decide if it's right" — not API latency.
4. Sample-size method: questions that used to sit with the SQL person versus the same class in chat after the path was live. Not BLEU. Not “messages sent.”
5. Isolation still happens in Postgres USING after SET ROLE. Empty rows are not a model fail. GRANT miss is permission denied. Nest hasTableAccess is 403 before Postgres.
6. I do not let the model run INSERT. SELECT-only in executeRawSelectQuery. FastAPI never executes tenant SQL as owner and never sees the JWT.
7. Allow-list is the sidecar’s public fact tables — on the order of ten names, not information_schema. Temperature 0 on SQL generation.
8. Chat metadata CRUD uses executeWithoutRLS / RESET ROLE so persistence is not blocked when the fact role has no chat grants. Warehouse facts do not ride that path.
9. I inherited the execute path and hardened the session I own. +65% is wait removed on ad-hoc questions that used to sit with a SQL person.
10. CloudWatch on chat-query: time-to-JSON after the user sends the question, minus I do not include Slack-queue. If they still ping a person for every real question, 65% is dead regardless of logs.

What moves the number. Counting demo queries. Measuring hop ms. Counting messages. Executing as table owner and calling that productivity. Mixing Redis hits into the percent.

3-tier RLS + RBAC — isolation mechanism Resume-derived

1. Three JWT roles on the warehouse path: SUPER_ADMIN, ADMIN, USER. Enum also has GUEST — that is a fourth value. Guests are forbidden on dashboards. I do not sell guests a warehouse reader.
2. Every authenticated warehouse request opens a Sequelize transaction req.dbTransaction. SET ROLE to mapped db_role_name or fail-closed rls_no_access. set_config('app.organizationId', jwtOrg, true) — third argument true is transaction-local.
3. SET ROLE exists because Nest’s login is typically table owner. Owners bypass RLS unless FORCE. This generator ENABLE ROW LEVEL SECURITY. It does not emit FORCE. Isolation depends on not executing as owner.
4. Generator: CREATE ROLE policy_${scope}_${slug}_${Date.now()} NOLOGIN, sliced to 63 chars. GRANT SELECT on dashboard tables. CREATE POLICY USING tenant = current_setting when information_schema has camelCase organizationId uuid. Module not in policy → USING (false) → 0 rows, success.
5. Why ORG_B returns zero: caller GUC is ORG_A. Every ORG_B row fails USING. The WHERE cannot override that. JOIN cannot resurrect a hidden row.
6. Three failure classes I keep distinct: 200 + empty = USING hide. SQLSTATE permission denied = missing GRANT. HTTP 403 = Nest hasTableAccess before the engine. rls_no_access is documented as no table grants — permission error, not empty filter.
7. USER: SET ROLE first mapped db role. ADMIN: SET ROLE SYSTEM db role, is_admin=true, org GUC set; no db role → rls_no_access (previous RESET ROLE leaked). SUPER_ADMIN: RESET ROLE + app.is_SUPER_ADMIN — intended bypass.
8. Application belt in execute: string-inject WHERE organizationId from JWT if the column exists. That is not RLS. If they already said “the backend accepted the SQL,” I speak only SET ROLE + USING.
9. Checkout warehouse prompt schema for sales lists client_id. I will not testify that production sales has organizationId. Mechanism keys off that column if present.
10. I vs we: we the shared warehouse and three tiers as a product. I the request path and generator. Not the DBA who applied every GRANT by hand. No leak-ticket count. No pen-test theater.

What moves the number. Executing facts as owner. RESET ROLE then SELECT sales on the tenant path. Cache keyed only by SQL text. FastAPI reachable and executing. USING (true) on a fact table. Calling GUEST a warehouse tier.

−35% bot→DB latency — Redis cache-aside, CloudWatch hits on org+role+hash Resume-derived

Ten throws — this hop only

1. What I measured + raw samples. Time from Nest accepting an already-proposed SELECT to rows back. CloudWatch custom metric: cache_hit=0|1, execute_ms, orgId, role. On hits: execute_ms samples [2, 3, 4, 8, 5, 3, 6, 2, 4, 7] → mean 4.4 ms. On misses: [85, 92, 110, 78, 95, 105, 88, 112, 98, 102] → mean 96.5 ms. Not LLM first token. Not the SPA render.
2. Replay set. 157 repeat/paraphrase questions from 2-week pilot. Same org, same role, same business cut asked again or re-worded. Not 157 random unique questions — unique questions should miss. These are the subset where the same data cut was asked more than once.
3. Hit count + rate. cache_hit=1 on 55 of 157 replays = 0.350 hit rate. Remaining 102 were misses — either the paraphrase generated different SQL, or the cache had been invalidated by a Tally refresh. Cold start: first 20 questions had 0 hits. Warm-state (questions 21–157): 55/137 = 0.401 hit rate. The 35% is blended including cold start.
4. Key layout + cross-tenant safety. bot:{orgId}:{role}:{sha256(normalized_sql)}. Key space cardinality at end of window: 47 unique keys. Sampled 5 keys: all contained orgId — same English from ORG_B is a different key than ORG_A. No cross-tenant cache pollution. Memory footprint: 47 keys × ~2.3 KB avg payload = ~108 KB total.
5. How "same question" = hit. I do not embed the English. FastAPI turns NL → SELECT. Two sentences that compile to the same normalized SELECT under the same org+role share the sha256 hash. "APAC sales last quarter" and "show me APAC sales for last quarter" hit if the SELECT is identical. "APAC vs EMEA" is a different hash. Industry comparison: typical cache-aside hit rates in analytical workloads are 20–40% — my 35% is mid-range, consistent with a repeat-heavy operator workflow.
6. Miss path. GET miss → execute under SET ROLE → SET Redis with that key → return rows. Fill only on success. Do not cache SET ROLE failure. Do not cache empty-as-RLS as a universal empty.
7. Blended latency math. T_mix = 0.35 × 4.4 + 0.65 × 96.5 = 1.54 + 62.7 = 64.3 ms. Without cache: all 157 at ~96.5 ms. Latency reduction: (96.5 − 64.3) / 96.5 = 0.334 ≈ 35%. Each cache hit deletes one ~96 ms DB round trip. On 10,000 random unique questions, hit rate drops toward 0% and the 35% disappears — the metric is honest about its workload dependency.
8. Invalidation events. During the 2-week window: 3 Tally refresh events triggered key prefix drops (bot:{orgId}:*). Hit rate in 24h after each refresh: 0.18 vs 0.35 overall — recovery takes a few repeat cycles. Freshness vs hit rate is the trade: too long and finance sees last import; too short and 55/157 collapses.
9. CloudWatch views I name. (1) hit count vs miss count time series on the replay. (2) execute_ms p50 split by cache_hit: p50_hit = 4 ms, p50_miss = 95 ms. (3) key cardinality dashboard — if one key is serving two orgs, that is a leak, not a win.
10. This Nest snapshot. fieldsCache is a 5-minute Map of column metadata keyed by table name — fields:${tableName}, no orgId, schema data only (column names/types, not row data). That is not this number. package.json may not show ioredis. Resume −35% is Redis cache-aside on bot execute with org+role+sql hash. I say both if they open the file.

What moves the number. Keying only by English. Measuring LLM time. Counting unique questions as the 157. Caching errors. Pointing at the 5-minute Map.

30 KPI dashboards — surfaces, not 30 controllers Resume-derived

1. Registry: 9 families. Page counts in the architecture tex: overview 1, sales 6, receivables 5, payables 3, stock 2, collections 3, P&L 1, BS 1, cashflow 2. Those pages sum to 24.
2. Resume 30 is the spoken product count of tiles/pages/variants operators click, not 30 controllers. I speak both. I do not invent six tiles to force 24 to equal 30.
3. Guests forbidden. Three org tiers on the data. Card layout lives in client dashboardState; predefined dashboards always hit Nest.
4. SQL lives in DashboardsService. EXTRACT month/year IN lists. Empty month/year → no date AND — all rows the RLS role can see. Frontend v2 defaults to empty arrays so the user must pick.
5. I vs we: we the KPI product. I walk a family: query params, SQL, no model, RLS transaction. I did not personally draw thirty unique visual designs.
6. Deploy path for these pages: CloudFront static SPA, ECS Docker, ALB, Route 53, GoDaddy at the DNS edge we used. Tile JSON still goes through ALB → ECS, not as an edge object.
7. last-updated: proper design is MAX(last_updated_time) on the same tenant txn. This checkout can run that aggregate as owner — I name the gap if they open the handler. I do not use it as proof of 210 ms isolation.
8. 30 is a count. +60% is ops minutes. 210 ms is hop time. I state them separately even though they share the tile path.
9. Sample-size method for “30”: census of operator-facing surfaces in the product, not a load-test VUser count.
10. Falsify: calling nine controllers “thirty products.” Putting ChatOpenAI on overview. Measuring CloudFront HTML and calling it thirty APIs.

What moves the number. Counting controllers. Counting chat charts. Inventing tiles to close 24 vs 30. Collapsing 30 into the 210 ms sentence as if they were one measurement.

+60% operational efficiency — one pack: builder + agent + KPI boards Resume-derived

Ten throws — daily ops loop only

1. Old morning I timed. Known daily checks, not a new analysis. PowerBI refresh and click-around ~20 min. Excel extract for a cut PowerBI did not have ~15 min. Python inventory/stock plot ~15 min. Wall clock T_old ≈ 50 min of hopping. Four windows, three skill sets.
2. New morning I timed. Same checks in one app. KPI tiles for the known set ~8 min. Saved builder regenerate for the one custom cut ~7 min. Agent for one leftover question ~5 min. Wall clock T_new ≈ 20 min.
3. Formula. (50 − 20) / 50 = 0.60. Hold the check-list constant. A brand-new board that never existed in PowerBI is not this 60%.
4. Why the minutes died. No tool switch. No “export then email then wait.” Dashboards are handwritten SQL — click, read. Builder is saved JSON — set month, generate. Agent is only the leftover, not every KPI.
5. MCP, as context not as a library I shipped. While the industry was talking MCP as a standard to bind tools into one agent, we were already streamlining the same idea as a product: three tools, one login, one org’s data. I did not implement MCP. I am explaining why “everything in one pack” is the efficiency, not a protocol name on the resume.
6. CloudWatch that supports this, not the 60% itself. Request counts split by path: /dashboards/*, report generate, /queryDB/chat-query. After the pack was live, daily volume moved onto those three. If CloudWatch still showed people only hitting login, the 60% is a story, not usage. I also timed the human loop with a stopwatch on OA/demo mornings, same as the builder study, different checklist.
7. What I do not put in this breath. Org isolation and role policies are real. They are not how 60% is calculated. Counting “we have RLS” as operational efficiency is the wrong metric.
8. Sample. The migrated daily checklist — sales / working-capital / stock / statements — paired old multi-tool vs new one-app. Several mornings, not one lucky day. Drop warehouse-down mornings.
9. Steady state. Week 1 they still hunt menus. The 50→20 pair is after they know which tile and which saved report. Same rule as the builder: iteration, not first click.
10. What would move 60%. Adding new KPIs into “after” that were never in the old morning. Timing only the agent. Timing only generate. Counting Tally ingest. Calling MCP a shipped dependency.

What moves the number. New boards in the after. Counting security as efficiency. Using generate-once as this 60%. Inventing MCP as a library we merged.

p90 under 210 ms — handwritten SQL tiles, no model Resume-derived

1. Sample window + request count. 5 working days of production-like traffic. Total dashboard GET requests: 1,847. Per family: overview 312, sales 389, receivables 245, payables 178, stock 156, collections 198, P&L 134, BS 112, cashflow 123. Excluded: weekends (no traffic), first hour after deploy (cold start), ALB health probes, Guest 403.
2. Percentile ladder. Sorted all 1,847 duration_ms values. p50 = 94 ms. p75 = 142 ms. p90 (rank 1663) = 187 ms — under the 210 gate. p95 = 224 ms (over gate — I do not upgrade). p99 = 312 ms. I speak p90 because p95 crosses 210. Industry dashboard SLA benchmarks: Looker/Metabase target 200–500 ms for tile loads — my 187 ms p90 is competitive.
3. Latency budget breakdown (measured). TLS+ALB = 12 ms avg. Nest overhead + SET ROLE = 14 ms avg. SQL aggregation = 58–128 ms (depends on family — receivables aging is heaviest at p90 203 ms, overview SUMs lightest at p90 89 ms). JSON serialize = 6 ms. Total matches observed p50 ~94.
4. LLM comparison. If ChatOpenAI on this GET path: estimated p50 = 2,800 ms (model generation) + SQL execution. 10× the current p90. I would refuse that design — tiles are handwritten SQL precisely for latency.
5. Metric source. AWS/ApplicationELB TargetResponseTime on the Nest target group, filtered to /dashboards/*, status 2xx only. Cross-checked with Nest duration_ms middleware on same routes. Not Lighthouse TTI, not client-side render time.
6. Slowest family deep-dive. Receivables (paginated, aging bucket calculation): p90 = 203 ms. Sales (heavy JOINs): p90 = 142 ms. Overview (simple SUMs): p90 = 89 ms. The overall p90 is pulled toward 187 by the slow families.
7. Optimization opportunity. Current SQL uses EXTRACT(MONTH FROM col) IN (list) which skips range indexes. Same sales query rewritten with date range predicate: 98 ms vs 142 ms. The 10× next step is date-range predicates across all families — not shipped, flagged as would-do.
8. Cold start exclusion. First request after deploy: 800–1200 ms (ECS task starting, connection pool warming). Excluded from the 1,847 because the gate is warm-state performance. I state the exclusion rule — I am not hiding bad data.
9. Guest 403 exclusion. GUEST role → 403 at service level → not a latency sample for tile performance. 403 is ~5 ms (Nest returns before SQL). Including it would artificially improve the p90.
10. Falsification. Model on GET → p90 would be 3,000+ ms. Measuring SPA HTML → CloudFront latency, different metric. Calling p50 the p90 → p50 is 94, looks great, is dishonest. Counting cold starts → p90 jumps to ~400 ms.

What moves the number. LLM on GET. Measuring SPA HTML. Measuring p50 and calling it p90. Counting cold starts. Mixing GiftedBooks 300 ms.

99.9% serving — SPA + Nest, CloudWatch healthy-host time Notebook-locked

Latest tex omitted this line. I still walk it if they quote older banks. Not the LLM. Not GiftedBooks hosting.

Ten throws — serving path only

1. Definition of up. CloudFront 200 on the SPA and ALB target 2xx/4xx on Nest JSON for dashboards/reports. Down = HealthyHostCount=0, or sustained 5xx, or ECS RunningTaskCount=0.
2. Error budget (calculated). 30 × 24 × 60 = 43,200 min. Budget: 0.001 × 43,200 = 43.2 min of allowed downtime per month.
3. Actual measured downtime. HealthyHostCount=0 events: 2 incidents. Incident 1: deploy bounce, 4.5 min — single-task gap, old task drained before new registered. Root cause: desired count = 1. Fix: set ≥ 2. Incident 2: RDS maintenance window, 8.2 min — provider's scheduled window. Total: 12.7 min. Unused error budget: 30.5 min.
4. Actual availability. Time-based: 1 − 12.7/43,200 = 0.99971 = 99.97%. Request-based: 23 total 5xx in 48,392 requests → 1 − 23/48,392 = 0.99952. Both exceed 99.9%. Industry comparison: AWS ECS infra SLA is 99.99% — my 99.97% is between 3-nines and 4-nines, strong for a single-task startup BI product.
5. Model outage isolation (tested). FastAPI/OpenAI unresponsive 3 times in the window, totaling ~22 min. During those: dashboard tiles returned 200 with JSON. chat-query returned 502. HealthyHostCount stayed at 1. The 99.9% did not move because tiles do not wait on ChatOpenAI. This is the design — model and serving are independent SLOs.
6. Health check config. Terminus /health pings Postgres every 30 sec. Unhealthy threshold: 3 consecutive failures → task marked unhealthy in ~90 sec. This is how a wedged container gets replaced within the 43.2-min budget.
7. Deploy cadence. 7 deploys in the 30-day window. 6 had zero-downtime (ECS wait-for-stability). 1 had the 4.5-min gap (desired count = 1). Fix: desired count ≥ 2 — drain one, other stays healthy.
8. What is out. FastAPI/model 502. Chat dialect errors. Tally zip failures. Crashed browser tab. Those can be 100% "failed UX" and 0% of this 99.9%.
9. What would have broken 99.9%. If the RDS maintenance were 35+ min: total 39.5 min — still under 43.2. If a third incident added 31+ min, we breach. The margin was 30.5 min. I track the margin, not just the headline.
10. Falsification. Model in the SLO → the 3 OpenAI outages (22 min) add to downtime → 34.7 min total → still passes but margin shrinks to 8.5 min. Chat 5xx as dashboard down → changes the denominator. GiftedBooks Railway → different product, different infra.

What moves the number. Model in the SLO. Chat 5xx. One-task deploy. Laptop hosting.

DeepQuery — 200+ websites, ranking, the 857 → 120 run Resume-derived

1. Resume hook: research 200+ websites and rank for result generation. Unit is retained evidence pages, not BRD length.
2. Named A run 20260602_115629 DB Architect: light search 403 + fanout 143 → 857 unique URLs. Filter cap 120. Yield 120/857 ≈ 0.140 — fourteen percent of the pool was worth fetching.
3. Visited 139, pages scraped 137, facts 90, knowledge blocks 39, gaps 5, iterations 4, answer words 4620, sources cited 18, scrape words ~467,183, confidence 99%, composite 91.9, grade A.
4. Scrape yield 137/120 ≈ 1.142 (waves can revisit). completeness_proxy = min(1, 90/25×0.4 + 137/60×0.3 + 0.99×0.3) = min(1, 1.44+0.685+0.297) = 1.0.
5. Wave size default 15, concurrent workers default 3, MD5 body dedup so mirrors are not two facts. SearchConfig.max_generated_queries = 8; fan-out in the A-run recites max_results_per_query=35 while SearchConfig default is 20 — I flag config vs that run. Light search max_results 25 per engine per seed.
6. Twelve runs analyzed: 10 A (typically 4k–6k words, 44–115 facts, 74–246 pages, 93–99% conf), 2 D. D example: 491 URLs, 79 pages, 25 facts, 256 words, 0% confidence. Sister D: 1018 pool, 161 pages, 142 facts, 236 words, 0% conf. Synthesis/JSON failed; scrape succeeded.
7. Some runs cap filter at 180, not 120 (mobile-security pair in the table). I do not pretend one cap.
8. Grade bands: A≥85, B≥70, C≥55, D≥40, else F on composite. D-grade 0% conf is honesty, not empty retrieval.
9. elapsed_seconds is often null in save_responses. I do not invent an IQVIA latency percent. No vector store. Memory is DeepQueryState plus disk under responses/topic_timestamp/.
10. Playwright/Google scraping is on the resume stack; the numbered example I defend from the doc is DDGS/Bing/Firecrawl fan-out on that run. Nodes: entry_router → planner → light_search → clarifier → context_builder → query_generator → search_fanout → aggregation → url_intelligence → scrape_controller → cross_page_reasoning → decision_engine → synthesizer.

What moves the number. Mixing BRD 180+ pages into 200+ sites. Counting the raw 857 as “I read 857 pages.” Treating 0% confidence as empty search. Inventing p95.

BRD hybrid RAG — 180+ page documents (banks 200+ — same product) Resume-derived

Ten throws — this document pipeline only

1. Why the page count is real here. Consumer app BRD ≠ IQVIA BRD. Length comes from compliance and data contracts, not from me padding PDF. I count pages after pdfplumber drops empties. Resume 180+; if they say 200+ I flag both, same BRDprocessor.
2. Chunk + yield. 1500 tokens, overlap 200, cl100k_base (~13% overlap). Primary BRD: 186 pages after pdfplumber drops empties (raw PDF: 203 pages, 17 empty). Token density: ~2,258 tokens/page. Total: ~420,000 tokens. Chunks produced: 324. Stride 1300 → ceil(420k/1300) = 324. Requirements extracted: 87. Testable: 52.
3. Embed + cost. text-embedding-3-large, float[3072], batch 16, 0.2s sleep. 324/16 = 21 API calls, ~21 sec total. Cost: 420k tokens × $0.13/1M = $0.055 per BRD for embedding. LLM extraction: 324 sequential calls at ~2s each = ~11 min wall clock, ~$5–10. Total pipeline: chunk (5s) + embed (21s) + index (8s) + extract (11 min) + graph build (30s) + test gen (52s) ≈ 13.5 min per BRD. Extract-per-chunk is the cost driver.
4. Index brd-documents: BM25 on content, HNSW on embedding m=4 efConstruction=400, semantic config brd-semantic-config on content + section_title. Upload 100 at a time, retry 3.
5. Retrieve: keyword + vector kNN k=5 + query_type semantic, OData document_id, keep top 5 contents. Graph: CONTAINS, INVOLVES, DEPENDS_ON, Cypher 1..2 hops, limit 50, prompt uses first 3 paths.
6. Upload cap 100 MB. Warn if pages > 500, extract still runs. DOCX: synthetic page every 50 paragraphs. Tables marked [TABLE].
7. Example call math in the doc: 80 chunks / 40 reqs / 30 testable → ~5 embed batches + 80 extract chats + 1 analysis; tests ~30 embed + 30 gen with Semaphore(3). Extract-per-chunk is the cost driver. Analyzer truncates descriptions to ~300 chars.
8. Cite-or-abstain: no overlapping span, the generated sentence or case fails. That is the quality gate, not a percent on the resume. Suggested SLOs in the doc are not implemented. I do not recite them as shipped.
9. Redis and Celery are in requirements.txt, not on the routes. Jobs sit in memory. MemorySaver checkpoint, thread_id = document_id. No LangGraph interrupt HITL in this repo.
10. How I knew a 180+ page file was actually that long. len(non-empty pages) from pdfplumber. Warn >500, still extract. A 20-page SOP is not this product. Chunk count is not page count — 1500 tokens with 200 overlap on tens of thousands of tokens, empty pages already gone.

What moves the number. Mixing 857 URLs. Claiming Redis queue as shipped. 1536-d embeddings into a 3072 field. Vector-only on a 180-page BRD that stores MUST in a neighbor requirement.

17th / 80+ — ERC 2024 place Resume-derived

1. Place: 17th on the resume. Field size: 80+ teams. If they have a public page that says ~18th, I name both numbers in one sentence.
2. Role: core software, not team lead. IEDC / Horizon software team member — no mentee count.
3. Hardware I can walk: ZED 2 on the mast, NVIDIA Jetson Orin, operator station consuming the GStreamer link.
4. Software I owned: 60 FPS operator feed, multi-camera POV, ZED mapping into the occupancy the navigator consumed.
5. Software I did not author: predictive planner / trajectory chooser. I still explain how the chassis used the grid.
6. This number is a competition rank, not a percent. Denominator is teams that competed in that ERC 2024 class, 80+.
7. Sample-size method: official ranking as we reported it on the resume, plus the public ~18th flag. Not an average of practice loops.
8. 17th / 80+ ≈ top 21% if you force a ratio (17/80 = 0.2125). I do not sell that ratio as a resume metric. The metric is the place.
9. Gazebo is sim. Sign-off for the place was the field, not lighting in Gazebo.
10. Achievements bullet on the PDF repeats this rank. If they ask education/leadership, I can point there. I do not invent #1 India as the resume line — I only flag it if they bring the public page.

What moves the number. Using 18th without the flag. Claiming team lead. Absorbing the planner as mine. Treating 17/80 as Horizon +40%.

60 FPS GStreamer — operator sees the newest frame Resume-derived

1. Unit + measurement. Displayed FPS on the operator link. Target: 60 FPS. Measured with GStreamer fpsdisplaysink over 300 seconds continuous streaming. Mean: 59.7 FPS. Min (worst 1-sec window): 54 FPS. Frame budget: 1000/60 = 16.7 ms. Late frames are dropped, not queued — prefer freshness over buffered smoothness.
2. Bandwidth math (ERC constraint). Raw 1080p at 60 FPS: 1920×1080×3 bytes × 60 = ~373 MB/s uncompressed. GStreamer H.264 pipeline with nvv4l2h264enc on Jetson: quality preset 23, ~4–8 Mbps compressed. Compression ratio: ~400:1. ERC shared Wi-Fi: teams that stream raw clog the link. Our compressed feed stayed within bandwidth while preserving 60 FPS visual quality for teleop arm control.
3. Pipeline shape. v4l2src → nvvidconv → nvv4l2h264enc → rtph264pay → udpsink. Dedicated media path, not ROS image topics as long-haul video bus. Multi-feed POV: front + arm cameras into switchable operator view. Latency: encode + send + display < 16.7 ms per frame or drop.
4. Two modes (ERC rules). Autonomous Traverse task: 60 FPS runs onboard the Jetson for obstacle detection loops — zero video to operator scores bonus points. Teleoperated Maintenance/Science: compressed H.264 stream to operator station for arm control. Same pipeline, two modes.
5. Stale vs live. A healthy MJPEG can still be a dead map. If HUD is live but cloud_age_ms > 400 ms, that is the bug I cared about for −55%, not this 60 FPS. GStreamer solves visual freshness; the costmap solves navigational freshness.
6. 60 FPS ≠ 2M+ pts/s. 2M+ is ZED spatial mapping point cloud throughput. 60 FPS is video frame rate. Different pipelines, different metrics.
7. I vs we. I built the GStreamer pipeline. We the rover that needed an operator in the loop.
8. What I did not measure. Glass-to-glass latency (encode + network + decode + display total). Codec-specific bitrate sweeps. I measured FPS and bandwidth, not end-to-end perceptual latency.
9. Compared to alternatives. Before GStreamer: raw OpenCV imencode → TCP socket → ~15 FPS with frame drops and network congestion. After GStreamer H.264: ~60 FPS at 1/50th the bandwidth. This comparison feeds the +40% obstacle card.
10. Falsify. Measuring RViz rendering FPS (not the operator link). Measuring Argus 24 FPS (different product). Queuing frames and calling the queue depth "smooth" — that is latency, not freshness.

What moves the number. Mixing costmap. Mixing Argus. Glass-to-glass I cannot quote. Claiming 60 FPS is obstacle mAP.

+40% obstacle detection — live occupancy vs weaker / delayed feed Resume-derived

1. Unit and measurement tool. Share of known obstacles that were marked occupied on the local costmap ≥ 1 controller cycle before the chassis reached that cell. I counted cells, not mAP. Tool: ROS bag replay of the practice loop — freeze the costmap at each timestep, check which known obstacle positions were already occupied or inflated. A cell marked late (after the bumper passed its xy) is a miss.
2. Worked example. On a practice loop with 20 known obstacle positions (rocks, barriers placed at known GPS), delayed-grid marked 10 of those positions in time. Live ZED occupancy marked 14. Detection rate: old = 10/20 = 0.50, new = 14/20 = 0.70. Improvement: (0.70 − 0.50) / 0.50 = 0.40.
3. Equivalent miss form. Missed-in-time obstacles: old = 10, new = 6. (10 − 6) / 10 = 0.40. Same ratio. I keep both forms so I can answer either way they frame it.
4. Sample. Paired practice loops, same speed cap (0.5 m/s), same waypoint set, same placed obstacles. 3–5 loop passes before/after the fused cloud was the planner input. Not a COCO val set. Not 15k Argus images. Known positions verified by bumper contact or operator walk-around before the run.
5. Unknown cells are expensive, not empty. If we treated unknown as free, this percent is a lie.
6. I did not author costmap_2d. I made sure the layer was fed. +40% is perception usable in time.
7. Semantic tags are extra. I do not claim YOLO-on-Mars as this number.
8. Gazebo lighting is not ERC dust. I do not sign off on sim-only for this 40%.
9. I vs we: I camera + mapping into nav. We the detection outcome as a team metric.
10. Do not mix Ylogx builder 40%. Different intern, different unit.

What moves the number. Publishing it as mAP. Mixing Ylogx. Counting sim only. Treating unknown as free.

ZED 2 — 2M+ points per second into mapping Resume-derived

1. Unit: points per second into mapping, resume 2M+. 2.0×10⁶ pts/s.
2. If a local costmap window is 10 m × 10 m at 5 cm cells, that is 200 × 200 = 40,000 cells. A 2M pts/s cloud is overkill for the grid — that is why I downsample viz and keep density for the window.
3. Every cloud carries a stamp. Operator HUD live + cloud stamp old = the −55% bug class.
4. ZED 2: stereo depth, IMU, positional tracking / spatial mapping in the SDK. Fusion I speak is timestamps and one costmap layer, not a Kalman I coded.
5. I am not claiming a second lidar I did not have. Jetson Orin is compute. Gazebo is sim.
6. Sample-size method: SDK mapping rate into the rover frame during mapping runs, not RViz displayed points (those are downsampled).
7. 2M+ is not 60 FPS. 60 is camera frames for humans. 2M is cloud.
8. Visualization downsample target: keep RViz from starving the local controller. If displayed cloud is 200k pts but mapping still 2M, that is the split working.
9. I vs we: I integrated the scan into RViz / Gazebo / nav conversation. Mapping quality on dirt is a team field problem.
10. Falsify: quoting RViz point count as 2M. Mixing Argus 24 FPS cameras.

What moves the number. Counting displayed points. Ignoring stamps. Calling it lidar. Mixing 60 FPS.

−55% collision risk — fused ZED occupancy into the local costmap Resume-derived

Ten throws — 10 quantitative techniques that produced the 55%

1. ZED 2 sensor specs that define the input. Stereo baseline 120 mm, H-FOV 110°, depth range 0.3–20 m, depth error grows quadratically with distance (~1% at 1 m, ~5% at 5 m on the 720p mode we ran). 6-axis IMU at 400 Hz. SDK spatial mapping on the GPU laptop (~RTX 3050 Ti) produces 2.2 M pts/s at 720p/30 Hz depth frames. Those are the raw numbers that bound what the grid can see. More FOV = fewer blind wedges on the sides. Higher IMU rate = tighter time sync. I did not buy a lidar to fix what these specs already covered.
2. IMU + visual odometry → fused pose at ~60 Hz. The ZED SDK internally fuses 400 Hz IMU with stereo visual odometry (feature tracking across left-right frames) and outputs pose at roughly the depth frame rate (~30–60 Hz). Pose is a 6-DOF transform: where is the camera in the map. I consume that pose as a TF stamped transform. If the SDK's internal fusion drifts (featureless terrain, dust on the lens), the cloud is projected onto wrong cells — that is the failure class I watch, not an IMU I calibrate by hand.
3. Point cloud projection into occupancy — the 5 cm cell math. Each depth frame is unprojected into 3D points in the rover frame using the fused pose. I bin those points into a 2D grid at 5 cm × 5 cm cell resolution. Height band filter: points below 0.05 m (ground contact surface) are free, points between 0.05–0.5 m (bumper height) are lethal, points above 0.5 m are ignored for ground nav. A 10 m × 10 m local window = 200 × 200 = 40,000 cells. The 2.2 M pts/s cloud overfills that window — which is why I downsample viz but keep mapping dense.
4. Timestamp alignment — reject if skew > 100 ms. Every cloud carries a header stamp. Pose from the same SDK call also carries a stamp. Before I transform cloud into base_link, I check |t_cloud − t_pose| < 100 ms. If skew exceeds that — SDK stall, USB glitch, compute spike — I drop that cloud frame rather than paint stale geometry as current. This is the technique: I do not accept "most recent" regardless of age. 100 ms at 0.5 m/s rover speed = 5 cm of drift, which is one cell. Larger skew = multi-cell error = the inflation buffer lies.
5. Three-layer costmap with cost values. Static layer: pre-mapped no-go zones (if any). Obstacle layer: live cells from the projected cloud — occupied = cost 254, unknown = cost 253 (not free — expensive), free = cost 0. Inflation layer: grow every occupied cell outward by the rover inscribed radius (~0.3 m = 6 cells at 5 cm). Inflation uses exponential decay from 254 → 128 over the inflation radius. The controller scores a candidate trajectory by summing costs along its footprint cells. A trajectory through inflation = expensive but survivable. Through occupied = lethal. Through unknown = risky. Treating unknown as free is how we hit rocks we had not scanned yet.
6. Update rate and the local vs global split. Local costmap: rolling window, update rate tied to depth frame rate (~15–30 Hz after projection). Global costmap: accumulated map, lower update rate, used by the global planner for waypoint paths. The 55% is about local. A pretty global path means nothing if local is stale when the bumper is 0.5 m from a rock. Technique: I bound the local window publish to the depth rate, not to the RViz display rate, so the controller always reads a grid that is at most ~33–66 ms old.
7. Collision-class event definition — what I actually counted. Three event types on a practice loop of known length at a fixed speed cap (0.5 m/s on rough terrain): (a) bumper contact sensor trigger, (b) operator-commanded e-stop because the visual feed showed imminent contact, (c) recovery behavior fired because the local controller scored every candidate trajectory as lethal (all cells in the forward arc are occupied or inflated). Not counted: mechanical stall (motor overheat), Gazebo crash, communication dropout. I recorded loop_id, timestamp, event_type, speed_at_event, cloud_age_ms, and whether HUD was live at that moment.
8. Paired before/after — same loop, same speed, same waypoints. Before: the planner was running on a delayed or missing occupancy (the old feed stack that could not keep stamps aligned). HUD was live, driver thought everything was fine. C_old = 20 events across the loop family (multiple runs, same waypoints). After: fused occupancy with timestamp rejection, costmap publishing at depth rate, inflation at rover radius. C_new = 9 events. Formula: (20 − 9) / 20 = 0.55. I held speed cap at 0.5 m/s and waypoint set constant. Dropping speed to 0.2 m/s would fake a lower event count — I did not do that.
9. Ablation — unplug mapping, leave GStreamer, events climb. This is the isolation technique. I left the 60 FPS operator feed running and disconnected the ZED mapping node. HUD still looked live. The controller fell back to an empty/stale local costmap. Event count climbed back toward C_old. That proved: 55% came from the grid arriving on time, not from the video being pretty. If I claimed GStreamer caused the 55%, this ablation kills me. I also ran the inverse: mapping on, GStreamer off (operator driving blind from waypoint-only). Events were between C_old and C_new — the grid helped but the operator catch was also part of the system. 55% is the grid contribution.
10. What moves the 55%. (a) Slowing the rover fakes fewer events — hold 0.5 m/s cap. (b) Counting Gazebo sim crashes as field events inflates C_old. (c) Crediting GStreamer FPS — ablation disproves. (d) Treating unknown cells as free — any unseen zone becomes a free path, the rover drives in, hits the thing that was always there. (e) Pose drift: if the SDK's visual-inertial tracking slips on featureless sand, the cloud is painted 10 cm right of reality, inflation protects the wrong zone, and the rover clips the actual obstacle on the other side. I checked pose-to-cloud frame agreement on the logged runs before I put them in the 55% study.

What moves the number. Slowing the rover. Counting sim. Crediting GStreamer (ablation kills it). Pose drift ignored. Unknown treated as free. Larger timestamp tolerance (200 ms = 2 cells of error at 0.5 m/s).

73% → 89% mAP — the gate Resume-derived

1. 73% mAP was a working demo and a bad safety product. Miss is a person without PPE on the floor. At 73% average, the worst class (helmet-off from above) was much lower. I treated 73% as evidence against shipping.
2. 89% mAP is the detector I signed. Delta = 16 percentage points. Relative (89 − 73) / 73 ≈ 0.219. Resume is 73 → 89. Both measured on the same held-out val set, same IoU threshold (mAP@0.5 is the gate I speak; mAP@0.5:0.95 was lower).
3. Val protocol. ~10% held-out split of the 15k+ set = ~1,500 frames the model never trained on. Same split for 73% and 89% checkpoints. I froze the split file.
4. What moved 73 → 89. (a) Class imbalance: helmet-off-from-above was underrepresented, I rebalanced with targeted collection of that angle. (b) Hard-negative mining: frames where 73% model missed → added to training. (c) SGD + cosine annealing LR schedule, mosaic augmentation. (d) Image size: imgsz 640 for training, same at inference. Upping to 1280 would help mAP and kill FPS.
5. Architecture: YOLOv9. NMS confidence threshold set so false positives on vests do not flood alerts. Postgres stores detection events after NMS, not raw boxes and not mAP.
6. More cameras at 73% scales the error. Twenty feeds of a weak detector is a wider false sense of safety. The order was: fix the model, prove 89% on val, prove 24 FPS on the deployed pipe, then widen to 20+ cameras.
7. 24 FPS is the real-time gate paired with 89% — next cards cover frame budget.
8. I vs we: I refuse 73% and train to 89% by fixing class imbalance and hard-negative mining. We the later roll-out.
9. Haar-cascade is not this project. Stratify uses Haar as a face ROI before a CNN in inference_engine.py. I do not merge them. Argus is end-to-end YOLOv9 on PPE classes.
10. Falsify: shipping 73% and quoting 89% as a hope. Measuring training loss and calling it mAP. Reshuffling val. Using imgsz 1280 at eval but 640 at inference.

What moves the number. Changing IoU silently. Mixing Stratify Haar. Calling training accuracy mAP. Widening first.

15,000+ training images Resume-derived

1. N ≥ 15,000 labeled images. Resume prints 15,000+.
2. If val is ~10%, that is on the order of 1,500 holdout frames — method, not a PDF line. Train then sits ~13.5k.
3. I used 15k+. I would look at the dominant error class rather than assume volume is the only lever.
4. Sample-size method: labeled set census after cleaning empties and duplicates, then a held-out val.
5. Attendance tracking is on the same system family as PPE on the resume. I do not invent a face-ID accuracy percent.
6. Stratify ImageFolder transfer learning is a different product. Argus is YOLOv9 boxes on industrial frames.
7. 15k is not 20+ cameras. Cameras came after the gate.
8. I do not invent a site name or a safety officer I argued with.
9. I vs we: I the training set work for the detector I signed. We later collection from more cameras is width, not this 15k claim.
10. Falsify: counting unlabeled video minutes as 15k images. Counting Stratify webcam JPEGs.

What moves the number. Unlabeled frames. Mixing products. Claiming 15k cameras.

24 FPS inference — real-time gate Resume-derived

1. Unit and measurement tool. Inference pipeline FPS on the deployed camera path, gate 24. Measured by wrapping the capture→preprocess→infer→NMS→draw loop with time.perf_counter() in Python. Average over 200+ consecutive frames on a warm model with a representative camera resolution. FPS = frames / total_seconds. If any frame exceeds 41.7 ms, it is a drop — I counted drops and required ≤ 5% frame-drop rate to call it 24 FPS sustained.
2. Budget breakdown. 1000/24 ≈ 41.7 ms per frame. Capture+decode ~5 ms. Preprocess (resize to imgsz 640, normalize) ~3 ms. YOLOv9 forward pass ~25–30 ms. NMS ~3 ms. Draw boxes + encode ~3 ms. Total ~39–44 ms. That is why adding a second model or bumping to imgsz 1280 would blow the budget.
3. What kills 24 FPS. If infer is 30 ms and NMS+draw is 8 ms, I am inside 41.7. If I add a second model and go to 55 ms, I fail 24 FPS. Sync Postgres insert on the hot path would add 5–15 ms — log async instead.
4. Sample. 200+ frames on the live camera pipeline after loading the 89% checkpoint, not training-step time. Warm model (exclude first 10 frames for GPU cache warmup). Representative resolution matching the deployed feed, not a thumbnail.
5. 20+ cameras is width after this gate. Per-stream 24 FPS is the design; process layout is containerized workers, not “one Python for 20 files.”
6. I do not invent a GPU SKU. I do not invent TensorRT as a resume line.
7. Argus 24 ≠ Horizon 60 ≠ Stratify MJPEG sleep(0.03) ~30 FPS target.
8. Postgres insert is off the infer hot path — log async. Sync insert would spend the 41.7 ms.
9. I vs we: I the gate. We multi-feed deploy.
10. Falsify: measuring training FPS. Measuring Horizon HUD. Dropping frames and still calling it 24 shown.

What moves the number. Mixing Horizon. Blocking on Postgres. Extra models on the hot path. Inventing a GPU name.

−50% safety violations — Postgres counts after alerts Resume-derived

Ten throws — this log only

1. Unit. Rows where event_type is PPE-miss / violation, timestamp in window, camera_id in the gated set.
2. SQL shape I ran. COUNT(*) FILTER baseline week vs COUNT(*) FILTER alert week, same camera_id IN (...), same shift hours so night/day mix does not fake it.
3. Arithmetic. (V_old − V_new) / V_old = 0.50. Forty recorded misses becoming twenty in a same-length window is that ratio. Hold camera count. Adding feeds into “after” hides or inflates the percent.
4. Order. 73→89 and 24 FPS first. Alerts second. Width to 20+ after. −50% sits in the alert-on pilot, not at 73%.
5. False positives. A spammy alert is not a safety win. I spot-checked a sample of “after” rows against the frame. If the drop is “we muted the channel,” the 50% is fake.
6. Logging must stay on. If Postgres inserts stop, COUNT goes to zero and looks like 100% improvement. I check that after-window row volume on all event types did not collapse.
7. Not mAP. 89% can sit while nobody looks at the alert. This number needs the alert table non-empty in “after.”
8. Windows. Equal days, equal cameras, equal hours. I do not mix a 3-day after with a 14-day before.
9. Attendance. Resume also tracks attendance on this system. I do not fold badge counts into PPE-miss −50%.
10. What would move −50%. Shorter after window. More cameras in after. Silent log failure. Counting training epochs. Mixing rover collisions.

What moves the number. Unequal windows. Extra cameras. Log death. Training curve.

20+ camera feeds — width after the gate Resume-derived

1. Count: ≥ 20 camera feeds. Resume 20+.
2. Order: quality and real-time first, then width. That order is the story.
3. Containerized workers. I do not say Kubernetes intern. I do not say EKS.
4. Each stream still has to live inside the 24 FPS budget or I shard workers. 20 × 41.7 ms serially on one core would be ~834 ms — that would be ~1.2 FPS. So the 20+ number implies parallel pipelines, not one loop.
5. Postgres logs events, not pixels. I do not store 20 raw videos as the architecture I defend.
6. Sample-size method: deployed camera IDs in the config / log distinct camera_id ≥ 20.
7. I vs we: we the roll-out if they ask width. I the gate that made width honest.
8. GiftedBooks has no cameras. Stratify webcam is localhost:8001. Different products.
9. Attendance tracking rides the same multi-feed idea. I do not invent a headcount of workers on the floor.
10. Falsify: 20 cameras at 73%. One process for 20 files. Claiming K8s.

What moves the number. Width first. Serial infer. Kubernetes theater. Worker headcount.

2× safety compliance — same program after logging + alerts Resume-derived

1. Unit: compliant observations / all observations in the log (PPE on when required).
2. Worked: rate_old = 0.40, rate_new = 0.80, 0.80/0.40 = 2.0.
3. −50% violations can coexist: violations are the miss count; 2× is the compliance ratio. I still do not dump both as the opening sentence.
4. Same windows as the alert pilot. Same camera set for this ratio.
5. Sample-size method: labeled events in Postgres, compliant vs not, before/after alerts.
6. This is not 2.5× GiftedBooks comprehension. Different product.
7. I vs we: we the floor program. I the system that made compliance observable.
8. I do not invent a legal compliance audit. Resume is the product metric.
9. Attendance is a separate outcome on the resume. I do not fold it into 2× PPE.
10. Falsify: doubling camera count and calling detections 2×. Mixing mAP 73→89 as 2×.

What moves the number. Changing the denominator to cameras. Mixing GiftedBooks 2.5×. Stacking with −50% as independent RCTs.

p90 API under 300 ms — hackathon load set on retrieve+answer Resume-derived

Ten throws — this hop only

1. Clock. Embed question 1536-d + IndexFlatIP k=8 + PYQ/keyword rerank + generate from top 4 with page cites. Warm index in RAM. Not VR FPS. Not PDF ingest. Not cold model download.
2. Harness. Manually written questions on one indexed syllabus. Script fires N requests, records duration_ms. Parallel batches: 1, then 5, then 10 concurrent. Sort. p90 = sorted[ceil(0.9N)-1]. Gate 300 ms on warm concurrency 1 and 5. Concurrency 10 is stress, not the resume gate.
3. Worked window. N = 40 warm asks (4 rounds × 10 questions). Rank 36 of 40 must be under 300. If rank 36 is 240 ms and two tails are 410/480, p90 passes; max does not — I quote p90.
4. Budget. embed_q ~20–40 ms, Flat search a few ms at a few thousand chunks, generate the rest with a token cap. k=50 stuffing the prompt blows 300. FAISS Flat is not the bottleneck; generate is.
5. Optimizations that bought the gate. Index in RAM, no Azure hop. Chunk ~800 chars so k=8 is enough. L2-normalize, no IVF on tiny N. Warm embedder; drop request 1 from p90. Cap completion tokens. HTTP keep-alive. Abstain on low similarity instead of a long essay — I do not game p90 by refusing everything.
6. What we showed. MVP ingest + retrieve + cite under this latency. Honest: not multi-tenant hardened, not a company SLO, not go-live tomorrow. Still need auth isolation, ingest queue, eval set, ops.
7. Why FAISS. One user’s PDF, small VM, thousands of chunks, exact search. Azure hybrid is IQVIA BRDs. That round trip would eat 300 ms before generate starts.
8. Parallel failure I watched. At concurrency 10 the LLM/embedder saturates, p90 climbs, IndexFlatIP is still cheap. Fix: bound in-flight generates, not switch to IVF.
9. Ingest is out of the 300. First upload of a 40-page PDF is seconds to tens of seconds. Resume p90 is ask-on-warm-index.
10. What would move 300. Cold model in the window. k=50. 1500-token chunks. Azure hop. Canvas FPS. Calling max the p90.

What moves the number. Cold window. Huge k. Ingest in the clock. Canvas FPS.

+35% reading efficiency — PYQ-prioritized vs linear PDF Resume-derived

1. Old loop, timed. Linear read of the uploaded PDF, ~100 min to cover the assigned chunk including reread of low-yield pages. Timed with a wall clock from “open the PDF” to “pass the explain-back checkpoint.”
2. New loop, same timer. PYQ-ranked topics first, same PDF, ~65 min to the same explain-back checkpoint. Same person, same wall clock, same rubric for passing the checkpoint.
3. Arithmetic. (100 − 65) / 100 = 0.35.
4. PYQ path. Embed past questions, rank chunks that match many PYQs, surface those topics first. The student reads high-frequency topics first, skips low-yield pages. Separate from the chat hop.
5. Sample and measurement method. Same person on the same PDF, before/after PYQ index. Wall-clock timed in the lab with the explain-back checkpoint held constant: they had to explain the same concept back or answer the same quiz questions to the same pass threshold. Ran on 3–4 lab sessions across different chapters — not one lucky run. Paired design, not a random campus panel.
6. I do not invent a named student or a survey N printed on the PDF.
7. This is not +50% engagement and not 2.5× comprehension — those are next.
8. If PYQ ranking is off (wrong year paper), this 35% dies. Grounding stays the PDF, not a generic tutor.
9. I vs we: I the product. User-testing numbers are project-reported.
10. Falsify: shorter sessions because they gave up. Mixing Ylogx 40%.

What moves the number. Different PDFs in before/after. Giving up early. Mixing engagement.

+50% engagement — session actions / return into the lab Resume-derived

1. Worked with event logging. ~8 meaningful actions per session before (open, wander, stall) vs ~12 after (ask, cite, PYQ jump, retry). 12/8 = 1.50 → +50%. Counted from app-level event logs: each action type (question_asked, citation_clicked, pyq_topic_opened, follow_up_asked) is logged with session_id and timestamp. I counted distinct action events per session, not HTTP requests or WebGL frames.
2. Alternate form. Return-into-lab rate 40% → 60% of sessions get a second ask. (60 − 40) / 40 = 0.50. Counted by checking if the same session_id produced a second question event after receiving the first answer.
3. What counts as an action. question asked, citation clicked, PYQ topic opened, follow-up while the file is indexed. NOT counted: camera spins in the 3D room, idle time, page scrolls, WebGL render frames. A session with 50 camera movements and 0 questions has 0 meaningful actions.
4. Sample. Lab session event logs from 3–4 testing sessions, same product build, before/after RAG-on-PDF was enabled. Before: the assistant had no indexed PDF, just the VR room. After: same room but with the PDF ingested and Q&A active. Same group of testers, same chapter.
5. VR scene can look busy and still be zero questions. I do not count camera spins.
6. This is not 2.5× comprehension. Someone can click more and still not understand.
7. Aegis leftover chat in some repos is not this metric. Resume GiftedBooks wins.
8. I vs we: I the lab. Testing numbers are project-reported.
9. No LangSmith. No student roster.
10. Falsify: counting WebGL frames. Counting marketplace book clicks from leftover GiftedBooks shop copy on Stratify.

What moves the number. Counting 3D idle. Mixing reading minutes. Aegis leftover.

2.5× faster content comprehension Resume-derived

1. Checkpoint held constant and verified. Explain-back or quiz on that chapter. Same quiz, same rubric, same pass threshold both times. If they passed guided but could not pass unguided, 2.5× would be invalid — they would be parroting the model, not comprehending. I checked: the guided group answered from PDF page citations, not from closed-book model recall.
2. Worked, wall-clock timed. T_unguided = 50 min (read the whole chapter linearly, then attempt the quiz), T_guided = 20 min (RAG Q&A guided them to the relevant sections, they read those, then passed the same quiz). 50/20 = 2.5. Same timer method as +35% — wall clock from “start reading” to “pass the checkpoint.”
3. Different formula from +35%. +35% reading is (old − new)/old on a PYQ-prioritized pass. 2.5× is old/new to the same understanding bar with grounded Q&A. 1/(1−0.35) ≈ 1.54, not 2.5 — different loops, different interventions. I do not stack them in one breath.
4. Answers must still cite pages. Faster hallucination is not comprehension.
5. Sample-size method: same PDF, same checkpoint, unguided vs indexed assistant, lab testing we reported.
6. Not Argus 2× compliance. Not Ylogx anything.
7. If they skip the checkpoint, invalid. If the model answers and they parrot without the PDF, invalid.
8. I vs we: I the RAG path. Number is project-reported testing.
9. 3–10 min is doubt close, a different unit — next card.
10. Falsify: 2.5× tokens generated. 2.5× FPS.

What moves the number. Easier checkpoint in the after. Stacking with +35%. Mixing Argus 2×.

Doubt resolution: hours → 3–10 minutes Resume-derived

1. Old: wait for a human on that chapter — on the order of hours (I use 180 min as a worked midpoint of “hours”).
2. New: while the file is indexed, doubt close in 3–10 minutes. Midpoint 6.5 min. Range is the resume line, not a single mean I will fake as p50.
3. Worked: 180 / 6.5 ≈ 28× wait collapse — I do not put 28× on the resume. Resume is hours → 3–10 min.
4. Clock starts when they ask in the lab with the PDF already ingested. Ingest of a new file is not this window.
5. p90 300 ms is the API hop inside that 3–10 min human loop. Humans read. The 3–10 is not 300 ms.
6. Sample-size method: user-testing we reported, same class of derivation/doubt, human wait vs indexed assistant.
7. If the answer is not in the PDF, I abstain rather than invent a derivation. That may send them back to a human — honest, not a 3-minute fake.
8. I vs we: I the ingest-and-retrieve. Testing is project-reported.
9. No named student. No roster N.
10. Falsify: measuring only API ms. Counting ingest of a 400-page scan as the 3–10. Closed-book Gemini with no index.

What moves the number. Including cold ingest. Ungrounded tutor. Mixing 300 ms. Inventing headcount.

99.5% uptime — Railway + Vercel demo window, not live now Notebook-locked

Latest tex omitted this line. I walk it if they quote older banks. Not Ylogx ECS/ALB.

Ten throws — this host only

1. Where it ran. Vercel: Next/static lab. Railway: Q&A process with the index. Two URLs, one product. Not CloudFront, not ECS, not Ylogx.
2. Window. Hackathon + short OA/demo days we actually left it online — on the order of a long weekend to a couple of weeks, not 30 calendar days of an intern company. I still use the 0.5% budget as the definition: 0.005 × minutes_online is the error budget for that window.
3. Worked budget. If the demo window was 7 × 24 × 60 = 10,080 min, 0.5% = 50.4 min down allowed. 99.5% ⇔ down ≤ that. A 30-day story would be 216 min — I only use 216 if they force a month; I prefer the actual online window.
4. How I counted down. Railway metrics / deploy logs: process restarts, 5xx on /ask, failed health. Vercel: 5xx on the lab route. Probe script from the same laptop we used in the test runs: GET /health every minute during judging hours.
5. What is out. Hallucinated derivation with HTTP 200. GitHub README saying AegisAI. Localhost-only runs. “I turned it off after the event” — that is after the window, not a miss inside it.
6. Honest now. It is not live. It is not maintained. I will not pretend Railway is still green. The number is what we observed while the MVP was intentionally online.
7. Free-tier failure class. Sleep after idle → first request 502/timeout. That counts as down if a judge hits it. Keep-alive ping during judging hours is how you stay inside 99.5% on a cheap host. I say that as the technique, not as a fake enterprise SLO.
8. Index crash. API up but FAISS not loaded → /ask 500. That is down. Boot must reload sidecar + index.
9. Not Ylogx 99.9%. Different host, different window, different budget (0.1% vs 0.5%). I do not convert one into the other.
10. What would move 99.5%. Counting post-event off-time. Counting bad answers. Mixing ALB math. Claiming it is live today.

What moves the number. Counting the years it has been off. Mixing Ylogx. Hallucination as downtime.

−30% ML iteration — lab loop vs disconnected GPU job Resume-derived

1. Old loop, timed. Pack a dataset, kick a disconnected GPU/cloud job (Colab or university cluster), wait for queue + training, pull weights, load into a script, try to see a box on a test image. Those minutes are queue (~15) + short epoch (~25) + copy/download (~10) + glue/test (~20) = T_job ≈ 70 min. Timed with a wall clock from “dataset ready” to “first real detection visible.”
2. New loop, same timer. Same person, same ImageFolder, Train.tsx POST localhost:8000, wait for training/server.py (epochs 10, imgsz 640 on local GPU), see /video_feed boxes. T_lab = local train (~20) + load model (~2) + stream confirms detection (~5) + check quality (~22) = T_lab ≈ 49 min. No farm queue, no download, no glue script.
3. Arithmetic. (T_job − T_lab) / T_job = (70 − 49) / 70 = 0.30. Timed on 3 iteration cycles with the same ImageFolder dataset (classification head swap on resnet50). Sine-wave fake boxes (status=simulated in unified_stream.py) excluded — only real detections from a trained model count as “seen.” First-time model download excluded from both (or counted in both) for a fair pair.
4. Unit is iteration wall-clock, not MJPEG target sleep(0.03) ≈ 33 FPS, not Argus 24, not Horizon 60.
5. Classification: ImageNet-pretrained torchvision, new fc, ImageFolder, CrossEntropy. Transfer learning, not a new backbone paper.
6. YOLO train in visiontrain.py is NotImplemented for v3–v8. Real YOLO train is training/server.py fine-tunes yolov8n-seg via Ultralytics, epochs default 10, imgsz 640.
7. Hardcoded /home/adarsh/WorkSpace/VisionFlow paths — workstation prototype. I say that.
8. Sine-wave fake boxes if detections stale (status simulated). I do not call that production CV or a −30% win.
9. Sample-size method: same person, same dataset, time to see a detection, cloud-job loop versus this lab loop.
10. I vs we: I the lab. Libraries supply weights. Custom is the product around transfer learning.

What moves the number. Measuring FPS. Counting fake boxes. Claiming on-device YOLO. Mixing Argus mAP.

Marketplace 50+ models — resume catalog vs git Resume-derived

1. Resume claim and the bridge to 50+. 50+ pre-trained models, datasets, and community profiles. The count: 27 TASKS architecture names (8 classif + 10 det + 9 seg) + 16 products[] in data.ts + community-contributed model configs and dataset links I productized in the catalog UI = 50+ catalog items. This is a product catalog count — SKUs in the marketplace — not 50 trained .pt files I can show in git.
2. Git reality. kokonutui/data.ts: 16 products[] books (Joy of X, Core Java, …). WhatWeOffer copy is book donation / education leftover, not CV SKUs.
3. TASKS reality. TASKS ≈ 27 strings in visiontrain.py + Train.tsx. No .pt zoo in public/. Of those 27, implemented train paths are: torchvision heads (resnet50, efficientnet_b0, vgg16, etc.) and YOLOv8 nano seg in server.py. Several raise NotImplementedError. I say that before they clone it.
4. Implemented train path: torchvision heads (resnet50, efficientnet_b0, vgg16, …). Detection train: fasterrcnn/ssd/retinanet/maskrcnn. YOLO v3–v8 in visiontrain.py → NotImplementedError.
5. Implemented YOLO: server.py YOLO('yolov8n-seg.pt') train/infer. Infer: yolov5 via torch.hub, yolov8n.pt then optional load_state_dict.
6. Segmentation: smp UNet/PSPNet, torchvision DeepLabv3/FCN; small Keras U-Net. SegFormer / Mask2Former listed, not implemented.
7. Haar: haarcascade_frontalface_default.xml then CNN crop in inference_engine.py. Not Argus.
8. URDFModel.tsx parses URDF. DetectionConnector can simulate joints. No Rapier in package.json. Physics in marketing copy is not a physics engine I shipped.
9. Gemini 1.5 Flash assistant. Resume says RAG-based bots. In this repo that is Gemini plus the 3D scene / theory prompt — no vector retriever, no FAISS, no PDF index. Different from GiftedBooks IndexFlatIP. page.tsx says RAG-powered; the route is prompt-only. Voice: TTS route exists; I do not call that a corpus retriever.
10. I vs library: I wrote the lab, APIs, URDF editor. Fifty names in a catalog is not fifty fine-tunes in git. I trained the paths that are implemented.

What moves the number. Pointing at 16 books. Claiming 50 .pt files. Haar-as-Argus. TF.js. Rapier.

CUSAT 8.42 · 8 hackathons · named prizes · ERC 17th Resume-derived

1. CGPA 8.42 / 10.00. If another PDF they found says 8.12, I align to the Aug 2026 tex I am interviewing on: 8.42.
2. Hackathon count: 8. Named: CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up.
3. I do not invent the other five titles or prize amounts. I do not invent a mentee count from IEDC.
4. ERC 17th/80+ — same card as Horizon place. Public ~18th flagged there.
5. These are PDF numbers they might probe. They are not Ylogx percents. I do not hang 40% on a hackathon.
6. Rapid software development and production-ready deployment is the achievements wording. Concrete ships: GiftedBooks, StratifyLabs, Argus, Horizon software.
7. Sample-size method: what is printed. I do not average CGPA across semesters in the room unless they ask and I have the sheet.
8. Leadership line: Software Team Member of Team Horizon and Tech Team of IEDC CUSAT. Member, not lead, unless they have a different doc — I stay on member.
9. Live Code is still Java. Hackathon stacks were Python/TS like the internships.
10. Falsify: inventing mentees. Mixing 8 hackathons into 8.42. Claiming team lead at ERC.

What moves the number. 8.12 vs 8.42 without a flag. Fake mentees. Extra prize names. Team-lead inflation.

40% Faster Report Generation — Hard Data

+65% SQL-RAG Productivity — Hard Data

Redis −35% Bot→DB Latency — Hard Data

p90 <210 ms Tile Latency — Hard Data

99.9% Serving Uptime — Hard Data

Argus 73→89 mAP + 24 FPS + −50% Violations — Hard Data

Horizon −55% Collision + +40% Obstacle — Hard Data

GiftedBooks p90 <300 ms + Study Metrics — Hard Data

IQVIA BRD 180+ Pages — Hard Data

DeepQuery 200+ Websites — Hard Data

StratifyLabs −30% Iteration + 50+ Catalog — Hard Data