Project Use Cases — Who Actually Uses These Things, and Why

Detailed, realistic scenarios for every active project in the Rust Learning Program

Ashwin Hebbar | June 2026

This document answers one question for every active project: who would realistically use this, at what scale, and what would change for them? Five scenarios per project, spread across three scales:

• 🏠 Enthusiast — individuals, hobbyists, students, homelab people. Adoption driven by curiosity and personal need.
• 🏢 SMB — startups, agencies, NGOs, small teams (2–200 people). Adoption driven by “we can’t afford the enterprise tool / the team to build this.”
• 🏛️ Enterprise — banks, large tech, government, regulated industries. Adoption driven by performance, compliance, and cost at scale.

Read these when motivation dips. Every project here has a person on the other end of it.

Retired projects (ticknorm, xlsxfmt, docforge) are excluded.

1. csvq — Command-Line CSV Query Tool

A single-binary, single-command query interface for CSV files. Think ripgrep for tabular data.

1. 🏠 The bank-statement analyst. An individual in Bengaluru downloads CSV statements from HDFC, ICICI, and their credit card portal at the end of every month — three files, three different column layouts, a few thousand rows each. Opening Excel means fighting auto-formatting that mangles dates and account numbers; opening a Jupyter notebook for a 30-second question feels absurd. With csvq, the monthly ritual becomes three shell commands: csvq hdfc_may.csv --filter "amount > 5000" --sort "amount desc" to spot large debits, --group-by "category" --agg "sum(amount)" against their hand-tagged export to see spending by category, and --stats to sanity-check that the bank’s totals match. The whole review takes four minutes, runs offline, and leaves no financial data in any cloud tool. This user is you, every month, forever — the most honest kind of dogfooding.

2. 🏠 The Kaggle competitor’s first ten minutes. A data science hobbyist downloads a new competition dataset: a 4GB CSV with 80 columns. Excel can’t open it. Loading it into pandas takes two minutes and 12GB of RAM just to answer “what columns are there and how many rows have a missing target?” With csvq, the first-look triage happens in seconds from the terminal: --count, --head 20, --filter "target == ''" --count, --select "id,target" --stats. The competitor decides which columns deserve real analysis before committing to a heavy environment — and because csvq streams, the laptop’s fans never spin up. For this user the value is iteration speed during the exploratory phase, when 90% of questions are trivially simple and the tooling overhead is the bottleneck.

3. 🏢 The D2C brand’s operations analyst. A 40-person direct-to-consumer brand sells on its own Shopify store plus two marketplaces. Every morning, three CSV exports land in a shared drive: orders, returns, settlement reports — 20k–100k rows each, different schemas. The ops analyst (not an engineer; comfortable with the terminal after a colleague’s demo) runs a small shell script of csvq one-liners: yesterday’s revenue by region (--group-by "state" --agg "sum(order_value),count(*)"), refund-rate outliers (--filter "status == 'refunded'" --group-by "sku"), and a top-20 SKU report piped straight into the morning Slack post. Previously this was a fragile Excel workbook with VLOOKUPs that broke whenever a marketplace renamed a column; now a schema change produces a clear error message at 7am instead of silently wrong numbers at 10am. No BI tool subscription, no data warehouse, no engineer on the critical path.

4. 🏢 The consultancy on a locked-down laptop. A data consultant arrives at a client site — a mid-size insurance firm — for a data-quality audit. The client-issued laptop has no admin rights, no Python, and an approval process measured in weeks for any software install. A single static csvq binary, however, passes the security review trivially (no installer, no runtime, no network access). The consultant spends the engagement slicing the client’s policy and claims extracts — filtering test records, counting nulls per branch office, cross-tabulating policy types — directly on the machine the data is allowed to live on. The deliverable cites exact reproducible commands, which the client’s own staff can re-run after the consultant leaves. The single-binary property isn’t a convenience here; it’s the difference between working day one and working day twenty.

5. 🏛️ The 2am production incident. A data platform engineer at a large logistics company gets paged: the nightly warehouse load failed on a 6GB vendor CSV sitting on an ingestion server. The server is a hardened production box — no pandas, no DuckDB, and installing anything requires a change ticket. The engineer scps the csvq binary (or it’s already baked into the base image, 4MB), and within minutes answers the questions that matter: --count (is the file truncated?), --stats on the date column (is there a malformed row?), --filter "order_id == ''" --count (how many bad records?), --head/--tail (did the vendor change the header row again?). The root cause — a vendor switching delimiters mid-file — is found in eight minutes instead of an hour of copying files across security zones. At enterprise scale, csvq’s value is where it can run, not just how fast.

2. schemaguard — Streaming Data Contract Validator (+ drift ML Extension)

A fast CLI that validates NDJSON/CSV streams against a schema contract, diffs schema versions, and (drift mode) detects distribution shift with PSI/KS tests.

1. 🏢 The agency that ingests other people’s files. A 15-person analytics agency runs nightly pipelines for a dozen clients, each of whom delivers data as CSV or NDJSON drops — from their POS systems, CRMs, and ERP exports. Client files break constantly: a renamed column after a software update, dates flipping from DD-MM to MM-DD, an integer field suddenly containing “N/A”. Today these breaks are discovered when a dashboard looks wrong and a client emails. The agency adds schemaguard validate --schema contracts/client_x.json --input drop.csv as the first step of every pipeline; exit code 1 halts the load and pages the on-call before bad data lands. The error report (line numbers, field, violation) goes straight into the client email — turning “your dashboard is broken” conversations into “your file changed, here’s exactly how” conversations. For a small team, this converts their scarcest resource (debugging hours) into a config file.

2. 🏛️ Contract testing between producer and consumer teams. At a large fintech, Team A produces a user_events stream that four downstream teams consume. Schema changes are coordinated through a wiki page — which is to say, not coordinated. The platform group adds two schemaguard gates: in Team A’s CI, schemaguard diff schema_v_current.json schema_v_next.json runs on every PR that touches the event schema, and any change classified as breaking (type change, removed required field) blocks the merge until downstream teams sign off. In consumers’ CI, sampled production events are validated against the contract they think they’re consuming. The expensive failure mode — producer ships Friday, consumer pipelines silently corrupt over the weekend, data backfill costs a week — becomes a red CI check on Tuesday. This is the Confluent Schema Registry workflow, without requiring every team to be on Kafka or the company to standardize on one platform.

3. 🏛️ The ML feature-store quality gate (validate + drift together). An ML platform team at a large insurer retrains thirty models on schedules. Twice in one year, a model retrained on corrupted features (an upstream join started producing 40% nulls) and quietly degraded for weeks. The team inserts a two-stage gate in the Airflow DAG before any training job: schemaguard validate confirms the feature extract matches the contract (types, ranges, required fields), then schemaguard drift --baseline last_training_set.ndjson --current candidate_set.ndjson computes PSI and KS per feature. PSI > 0.25 on any top-10-importance feature fails the DAG and opens a ticket with the per-field drift report attached. Training simply cannot proceed on data that doesn’t look like data anymore. At 100k+ records/second, the gate adds seconds to a pipeline, not minutes — which is precisely why it gets adopted instead of bypassed.

4. 🏢 The lending startup’s model-governance evidence. A 60-person NBFC-adjacent lending startup uses a credit scoring model. Their risk officer knows regulators and partner banks increasingly ask: how do you monitor your model inputs? The honest answer used to be “a data scientist eyeballs distributions when something feels off.” Now a monthly cron job runs schemaguard drift comparing the month’s scored applications against the training baseline, and archives the JSON drift reports. PSI per feature, timestamped, reproducible — the exact metric credit-risk reviewers expect, because PSI is the industry’s drift lingua franca. When the partner bank’s model-risk team audits, the startup hands over fourteen months of drift reports generated by an auditable open-source tool. Cost of compliance theater avoided: one cron entry.

5. 🏠 The open-data maintainer. A civic-tech enthusiast maintains a popular GitHub dataset: daily-scraped data from a government portal (election affidavits, pollution readings, mandi prices — pick one). The portal’s HTML changes without notice, and twice the scraper has silently produced garbage that hundreds of downstream users pulled. They add schemaguard validate to the scraper’s GitHub Action — every scheduled run validates the day’s output against a contract before committing; schemaguard drift compares each month against the previous to catch subtler rot (a field that’s suddenly 90% empty still type-checks). Broken scrapes now fail loudly in CI instead of poisoning the dataset. The contract file itself, checked into the repo, doubles as the dataset’s documentation — the first machine-readable answer to “what’s in this data?“

3. logr — Terminal-Native Activity Tracker

A zero-dependency CLI for logging activities, durations, tags, and notes to local JSON files. Honest scale note: this is a personal tool by design — its scenarios skew enthusiast, and that’s fine; it earns its program slot as a serde/chrono/CLI workout and as the data source for the Phase 3 HTTP server.

1. 🏠 This program, tracked by its own artifact. The most immediate user is you, during this exact program. logr log "rust study" --duration 90 --tags "week14,drift" --notes "PSI bins finally correct" after every session; logr streak "rust study" when motivation dips; logr stats --week feeding the Sunday check-in ritual in EXECUTION-SYSTEM.md. The 52-week program is a streak-maintenance problem, and the psychological literature on habit tracking is clear: visible streaks change behavior. There is also a quiet meta-lesson — by week 16 you’ll be using a tool you built in a language you couldn’t read in week 1, and the export (logr export --range "2026-06-01..2027-05-30") becomes the dataset for your end-of-program retrospective blog post.

2. 🏠 The freelancer’s billable-hours backbone. A freelance designer juggles four clients and bills hourly. SaaS time trackers want ₹800/month, a browser tab, and her data on their servers; she lives in the terminal anyway (static site workflows). logr log "client-acme" --duration 50 --notes "homepage revisions round 2" takes five seconds; at month-end, logr export --format csv --range "2026-06-01..2026-06-30" filtered by client tag drops straight into her invoice template. Disputes (“did we really spend 12 hours on revisions?”) are settled by the notes field with timestamps. Her business records are plain JSON files in ~/.local/share/logr/ — backed up with everything else, greppable, owned outright, readable in twenty years.

3. 🏠 The quantified-self person who quit the apps. A health-conscious engineer tracked medication adherence, workouts, and sleep in three different apps — then one shut down (data export: a useless PDF), one moved features behind a subscription, one sold to a data broker. They consolidate on logr: logr log "medication" --tags "morning", logr log "run" --duration 35 --notes "knee felt fine". logr streak "medication" answers the question that actually matters at the pharmacy. Because storage is monthly JSON, a 20-line Python script renders a yearly heatmap — the data is theirs to analyze. The XDG-compliant local-first design isn’t an implementation detail in this scenario; it is the entire reason this user exists.

4. 🏢 The two-person consultancy’s lightweight audit trail. A pair of security consultants work inside client networks where unapproved SaaS is contractually prohibited — no Toggl, no Notion, often no internet from the work VM. Each keeps logr on their machine: every assessment activity logged with engagement tags (logr log "nmap sweep" --tags "client-x,phase1" --duration 40). At engagement end, the merged CSV export becomes the activity appendix of the report — what was done, when, for how long — which their professional-liability insurer and some client contracts actually require. A single static binary that writes local files passes client security review where a cloud tracker never would. Small scale, real money: the export is the invoice’s evidence.

5. 🏠→🏢 The ML experimenter’s lab notebook (and the pattern it teaches). A data scientist running personal LLM fine-tuning experiments logs every run: logr log "train-lora-v7" --duration 120 --tags "mistral,rank16" --notes "loss plateaued 0.81, lr too high?". Weeks later, “didn’t I already try rank 16?” is a logr activities-plus-grep away — the failure mode of all hobby research (repeating dead ends) gets a cheap fix. The larger value is the pattern: local-first CLI + JSON + date-range queries + CSV export is a template this person will reuse for every small tool they build afterward — and in this program, logr’s files literally become the API payload served by your Phase 3 HTTP server, so the toy compounds.

4. HTTP/1.1 Server From Scratch (Phase 3A — Option A)

A learning exercise by design — but the artifact and especially the knowledge have realistic deployments. These scenarios are about what “I understand HTTP at the byte level” buys.

1. 🏠 The Raspberry Pi homelab dashboard. A homelab enthusiast wants a status page on a Pi Zero: temperatures, disk usage, their logr stats. The usual answer — a Flask app — means a Python runtime, 60MB of RAM, and pip dependencies on an SD card that corrupts annually. Your from-scratch server compiles to a ~2MB static ARM binary using ~3MB of RAM, serving JSON and a static HTML page over raw TCP. It survives apt upgrade breaking Python (it doesn’t care), reboots into service in milliseconds via systemd, and when something misbehaves, the owner can read their own request parser instead of spelunking through framework internals. For constrained-hardware enthusiasts this isn’t a toy — it’s the correct engineering answer.

2. 🏛️ The engineer who can read a 502. A platform engineer at a large company faces a classic production mystery: intermittent 502s between an ALB and a service, only under load. Colleagues stare at dashboards; this engineer — who has written an HTTP parser — pulls a tcpdump and reads the actual bytes: the service closes keep-alive connections without Connection: close while the load balancer reuses them, a race that manifests as 502s. The fix is a one-line idle-timeout alignment. This scenario repeats endlessly in industry (header-casing bugs, chunked-encoding mismatches, content-length vs actual body length, slowloris-style stalls) and divides engineers into those who can reason beneath the framework and those who escalate. The “use case” of this project is being the first kind — it pays off during incidents for the rest of a career.

3. 🏛️ The scratch-container healthcheck sidecar. An enterprise platform team runs hundreds of services in distroless/scratch containers for supply-chain-security reasons (every dependency must be justified to the CISO). They need a tiny internal endpoint per pod: serve /healthz, /buildinfo, and a config dump — and pulling in a full web framework (with its dependency tree of 100+ transitive crates to audit) for three endpoints is exactly what the security policy forbids. A from-scratch HTTP responder using only std is ~300 lines, audits in an afternoon, and adds zero CVE surface. Variants of this — metrics shims, admission-webhook stubs, debug endpoints on data planes — exist all over serious infrastructure, and they’re written by people who know exactly what HTTP/1.1 200 OK\r\n means.

4. 🏢 The embedded config page in a hardware product. A 30-person IoT startup ships an industrial air-quality monitor (note the synergy with airpost’s domain) on a microcontroller-class Linux SoC with 32MB of RAM. Customers need a local web page to configure Wi-Fi and thresholds — served by the device itself, with no internet dependency. There is no room for nginx + a Python app; there is plenty of room for a 2MB static binary speaking just enough HTTP/1.1: GET the config page, POST the form, restart. This is among the most common commercial uses of hand-rolled HTTP servers in the world — inside routers, printers, cameras, and lab equipment — and after this project you could be the person on the team who builds and maintains it confidently.

5. 🏠→🏛️ The framework evaluation that’s actually informed. Six months after this project, you’re choosing an HTTP stack at work or for inferd. Documentation says axum is “ergonomic” and actix is “fast” — marketing adjectives. Having built the layer they abstract, you evaluate them on real questions: how does it buffer request bodies (your server naively read-to-end; what happens at 2GB uploads?), where do timeouts live, what does the router actually do with path parameters, how are connections shared across threads (you used Arc<Mutex<T>> — what does tower do instead, and why?). This use case sounds abstract but is the program’s stated purpose made concrete: every framework decision afterward — and every code review of someone else’s handler — runs on understanding instead of vibes.

5. naivechain — Blockchain From the Opcode Up (Phase 3A — Option B)

The alternative Phase 3A exercise: SHA-256, Merkle trees, proof-of-work, UTXOs, and a script VM from scratch. Use cases are knowledge-shaped — listed honestly. (The critique recommends Option A for your path; these are here in case Option B’s pull wins.)

1. 🏠 Reading the Bitcoin whitepaper — and the source — with comprehension. The canonical enthusiast outcome. After implementing the hash chain, Merkle root, and UTXO set yourself, Satoshi’s nine pages read like a description of code you’ve written — because it is. Bitcoin Core’s CheckTransaction() and script interpreter stop being arcana and become “their production version of my Layer 3 and 4.” For someone who keeps adjacent to crypto markets (any finance professional in 2026), the difference between having opinions about blockchains and understanding them is exactly this project.

2. 🏛️ The due-diligence engineer in the room with vendors. A bank’s innovation team (LSEG itself has digital-asset initiatives — tread per COI guidance, this is about knowledge not publishing) gets pitched “enterprise blockchain” solutions weekly. Most are databases wearing a costume. An engineer who has built PoW, UTXOs, and a script VM asks the questions that collapse weak pitches in minutes: What’s your consensus mechanism if all validators are us? What does your “smart contract” execute on, and is it Turing-complete — and if so, what stops non-termination? Why is this not Postgres with an audit log? Procurement decisions worth crores get made better by one person in the room who can’t be hand-waved. That person is a use case.

3. 🏢 Tamper-evident audit logs — the pattern extracted. A 50-person healthtech startup must prove their access logs haven’t been altered (clinical-data regulations). Full blockchain? Absurd. But the first layer of naivechain — each record carrying the hash of the previous record, with periodic anchored checkpoints — is exactly right: ~100 lines, no consensus needed, tamper-evidence guaranteed by the same property you tested in naivechain validate (change block 5, every subsequent hash breaks). Hash-chained logging shows up in serious systems (certificate transparency, secure syslog, append-only ledgers in fintech back-offices), and engineers who’ve built a chain once implement it correctly — including the subtle parts like canonical serialization, which your deterministic to_bytes() taught the hard way.

4. 🏠 The workshop/teaching artifact. A Bengaluru Rust meetup needs a session; “build a blockchain in an evening, no crates” is a perennially packed talk. naivechain is unusually good teaching material because every layer is inspectable — attendees mine a block live with difficulty 8, tamper with a transaction, and watch validation fail with a precise error. As a blog series (“SHA-256 from FIPS 180-4 in Rust”, “A stack VM in 200 lines”) it’s exactly the kind of from-scratch content that builds a technical reputation — fasterthanli.me built a career on this genre. The use case is your visibility, which the OSS-contribution track values for the same reason.

5. 🏢 Fintech/crypto-infrastructure career optionality. Crypto infrastructure firms (custody, settlement, analytics — including very normal, regulated companies) hire systems engineers and consistently struggle to find candidates who understand both the cryptographic data structures and a systems language. UTXO-set management, script evaluation, and Merkle proofs are literal interview topics at these firms. A data scientist with a working naivechain repo and the ability to discuss why Bitcoin Script is deliberately non-Turing-complete clears a bar most applicants don’t know exists. This is the narrowest use case of the five — which is honestly why the critique leans Option A — but for one specific career branch it’s a key that opens doors.

6. airpost — Real-Time Air Quality Aggregator

A self-hosted service that polls OpenAQ, CPCB, PurpleAir, and WAQI, normalizes everything to µg/m³ with quality flags, and serves a unified query API.

1. 🏠 The Bengaluru parent with a sensor on the balcony. A parent in HSR Layout bought a PurpleAir sensor after their child’s third winter cough. Now they have two numbers that disagree: their sensor says PM2.5 is 95, the SAFAR app says AQI 132, and they have no idea whether to cancel the evening park trip. They run airpost on the ₹400/month VPS that already hosts their blog. It polls their own sensor, the two nearest CPCB stations, and OpenAQ; applies the humidity correction their raw PurpleAir reading badly needs (uncorrected readings run 30–50% high in Bengaluru’s humid months — so they’ve been over-restricting outdoor time); and answers one HTTP call: current corrected µg/m³, all sources, one scale. A 20-line script polls /aqi/current?city=bengaluru and pushes a Telegram message at 4pm: 🟢 park / 🟡 short / 🔴 indoors. The tool’s entire normalization machinery exists so that one decision can be made on one number.

2. 🏢 The environmental NGO’s hyperlocal campaign. A six-person Delhi NGO is campaigning about pollution disparity: their claim is that readings near an industrial corridor run consistently worse than the city’s official narrative, which leans on monitors placed in greener districts. To make the claim stick they need data that survives hostile review: government CPCB readings and citizen PurpleAir sensors, on the same scale, with quality flags, over months. They deploy airpost on a donated server; it builds the longitudinal dataset automatically while they do advocacy work. The /compare?sources=cpcb,purpleair endpoint becomes the centerpiece of their report — same-day, same-neighborhood comparisons, with the PurpleAir humidity-flagged readings excluded transparently rather than cherry-picked. When the report is challenged, they publish the airpost config and let critics re-run it. Self-hostability isn’t a feature here; it’s epistemic credibility for an organization nobody is obliged to trust.

3. 🏢 The data-journalism investigation. A national news outlet’s three-person data desk is investigating whether “smog season” official numbers dip suspiciously during high-profile events. They need readings from multiple independent source networks — if CPCB, OpenAQ mirrors, and citizen sensors diverge only during specific windows, that’s a story; if they track together, there’s no story (also worth knowing, cheaper). Their previous attempt died under data-wrangling: four APIs, four schemas, three unit systems, weeks of scripting before any journalism happened. With airpost ingesting all sources into one Postgres schema from day one, the desk queries normalized µg/m³ across networks with SQL and spends their time on the actual question. The investigation’s methods box cites the open-source aggregator and its unit-conversion rules — reproducibility that survives the inevitable rebuttal cycle.

4. 🏛️ The epidemiology research group. A university public-health lab is studying the relationship between PM2.5 exposure and pediatric asthma admissions across three Indian cities over two years. Their core methodological problem is exposure measurement: CPCB coverage is sparse (one station can “represent” 2 million people), so they want citizen sensors to densify the grid — but mixing AQI values with raw particle counts and µg/m³ would be methodologically indefensible. airpost, running on university infrastructure, gives them a defensible pipeline: everything in µg/m³, EPA-standard corrections applied and documented, suspect readings flagged rather than silently included, full provenance per reading (source, station, timestamp, quality flag). The methods section can describe the normalization in one paragraph with a citation to the tool. Two years later the archived database — built passively — is itself a publishable dataset.

5. 🏢 The school chain’s automated activity policy. A 12-campus school network in the NCR has an air-quality policy on paper: outdoor sports cancelled above certain thresholds. In practice, each campus admin checks a phone app sporadically, and enforcement is inconsistent enough that parents complain in both directions. The ops team deploys airpost centrally, mapping each campus to its nearest stations (plus PurpleAir units they install at the four campuses farthest from official monitors). A scheduled job hits /aqi/current per campus at 6:30am and 12:30pm and pushes a simple decision — normal / modified / indoor — to each campus WhatsApp group, logging every decision with the readings behind it. When a parent disputes a cancelled sports day, the log shows the exact readings and sources. The (tokio polling + normalization + API) machinery you built for learning is, here, the difference between a policy that exists and a policy that operates.

7. riskbook — Real-Time Portfolio Risk Engine

Black-Scholes and Greeks from formulas, VaR three ways (historical, parametric, Monte Carlo), EWMA/GARCH volatility forecasting — as a CLI, library, and PyO3 module. (Per the critique: build freely, check the employment contract before publishing.)

1. 🏠 The retail F&O trader’s expiry-week discipline. India runs the world’s largest equity options market by contract volume, and a serious retail trader in it holds a NIFTY iron condor, two stock option positions, and underlying shares — yet their broker app shows per-position P&L and nothing else. What they actually need before expiry week: portfolio delta (am I directionally exposed without realizing it?), theta (what’s time decay paying me daily?), and a one-day 99% VaR (what’s a realistic bad Tuesday?). They keep positions.csv updated and run riskbook compute each evening; riskbook greeks answers “what happens to the condor if India VIX jumps 4 points” before the morning open rather than after. The discipline this enforces — knowing aggregate exposure, sizing against VaR — is precisely what separates surviving retail options traders from the statistics. A spreadsheet could approximate this; a spreadsheet with correct Black-Scholes, Greeks aggregation, and percentile math, maintained error-free, effectively never exists.

2. 🏢 The boutique PMS firm’s client risk reports. A SEBI-registered portfolio management firm (9 employees, ~₹400 crore AUM) sends clients a monthly factsheet. Sophisticated clients and the occasional family-office due-diligence questionnaire now ask for VaR, concentration, and stress numbers — table stakes the firm currently produces via an Excel workbook one analyst maintains in fear (a broken cell reference once overstated a client’s VaR threefold; it was caught by luck). They replace the workbook with riskbook in batch mode: positions exported from their custodian, riskbook compute per client portfolio, historical + parametric VaR and concentration in the report appendix, EWMA-based vol so the numbers respond to regimes. The PyO3 binding matters: their reporting pipeline is Python, so from riskbook import Portfolio slots in without rewriting anything. Deterministic, tested, version-controlled risk numbers — at a firm that could never justify a Bloomberg PORT seat per analyst.

3. 🏢 The trading-app startup’s pre-trade risk checks. A 70-person brokerage startup wants a differentiating feature: when a user is about to buy options, show what the trade does to their portfolio’s risk — “this position takes your 1-day 99% VaR from ₹8,200 to ₹19,400 and your delta from +0.3 lakh to +1.1 lakh” — at order-preview time, which means a latency budget of ~50ms at thousands of requests per minute. Python pricing at that latency/throughput is a non-starter; a vendor risk system prices per-seat for institutions, not per-API-call for consumer apps. An embedded Rust library computing Black-Scholes, Greeks, and incremental VaR in microseconds is the architecture (this is exactly the “update P&L in <1μs” performance target in the spec). The startup’s quant validates the math in Python via the PyO3 binding; the same crate runs in the serving path. One codebase, both worlds — the program’s whole thesis in one deployment.

4. 🏛️ The prop desk’s intraday risk monitor. A proprietary trading desk (40 traders, multiple books of equities and options) has end-of-day risk from their vendor system, but intraday they fly on per-trader spreadsheets. The desk’s risk manager wants one screen: live portfolio Greeks and VaR per book, updating as prices tick — and the vendor’s quote for an intraday module is annual-budget-conversation money. riskbook in streaming mode (--price-feed stdin evolved into a feed adapter) revalues a few thousand positions per tick: full revaluation in <100ms means the risk screen is at most one tick behind the market. Marginal-VaR attribution answers the question that matters at 2:15pm — which trader’s book is driving today’s risk — while it can still be hedged, not in tomorrow’s report. Caveat honestly stated: a real desk needs vol surfaces and rates curves beyond the spec’s scope; but the architecture (streaming revaluation, portfolio aggregation, attribution) is the real thing, and extending it is engineering, not research.

5. 🏛️ The model-validation team’s independent check. Banking regulation (SR 11-7 and its global cousins) requires that risk models be validated by an independent implementation — you cannot certify a model by re-running the same code. A model-risk analyst at a mid-size bank needs to verify the vendor system’s option valuations and VaR on a sample portfolio. Today this means a hand-built Python notebook per validation cycle, reconstructed annually by whoever inherited it. riskbook — open-source, from-the-formulas, property-tested (put-call parity, Greek identities) — is close to the platonic independent checker: different codebase, different language, different author, transparent math. Where vendor and riskbook disagree beyond tolerance, that’s the finding — usually a vol-input or day-count convention discrepancy worth catching. The from-scratch constraint you followed for pedagogy is, in this scenario, precisely the regulatory feature.

8. dataprof — Fast Data Profiler for CSV and Parquet

One-pass profiling with from-scratch sketches (HyperLogLog, Misra–Gries, reservoir sampling), rayon parallelism, Arrow/Parquet input, CLI + PyO3 + HTML report.

1. 🏠 The Kaggler’s (and your own) first-look ritual. Same competitor as csvq scenario 2, one phase later: the 4GB dataset deserves a full profile, not just triage. ydata-profiling on this file means 25 minutes and an OOM warning on a 16GB laptop — the community’s standard advice is “sample it first,” which defeats the purpose of profiling. dataprof profile train.parquet --output report.html finishes in seconds: per-column types, missingness, cardinality (HyperLogLog handles the 30M-row ID column without breaking a sweat), distributions, correlations, top-k categories. The HTML report becomes the reference tab they keep open for the whole competition. This user is also you, professionally, weekly — the first tool from this program you’ll reach for at work without thinking of it as “the Rust project.”

2. 🏢 The data agency’s audit deliverable. A consulting shop wins a “rescue our data warehouse” engagement at a mid-size retailer. Step one is always the same: inventory what actually exists — 200+ tables exported to Parquet, of unknown quality. Their previous method: a junior consultant runs pandas profiling table-by-table for a week, babysitting kernel crashes on the big ones. With dataprof in a shell loop, all 200 exports profile overnight on one machine; the JSON output aggregates into a findings spreadsheet (every column >40% null, every “unique ID” with duplicates — the Misra–Gries top-k surfaces the placeholder values like 'UNKNOWN' instantly), and per-table HTML reports go in the appendix. The engagement’s discovery phase compresses from two weeks to three days, which at consulting day rates pays for the tool’s development time roughly 100x over. This is also the artifact that makes clients feel the audit was thorough — reports they can click through.

3. 🏢 The startup’s PR-time data checks. A 25-person fintech-data startup ships datasets as a product (think: merchant categorization feeds). Every release used to involve a “did anything break?” eyeball pass. Now their release CI runs dataprof compare previous_release.parquet candidate.parquet: the PSI/KS drift mode (the same math as your schemaguard drift, here over Parquet) flags any column whose distribution moved — which catches the real failure modes of a data product: an upstream change quietly nulling 8% of a column, a categorical value exploding in frequency, a numeric field’s scale shifting. The drift report posts to the release PR as a comment. Their customers never see the bad release that the diff caught on a Thursday — which, for a company whose product is data, is the whole ballgame.

4. 🏛️ The lakehouse landing-zone gate. A large enterprise’s data platform ingests ~1,400 Parquet partition drops daily from internal producers and external vendors into the lakehouse bronze layer. Today, quality checking is sampled and reactive; the team wants every partition profiled at landing, but the Spark-based profiler they prototyped costs cluster-money per file and adds minutes of latency. dataprof as a lightweight step in the ingestion worker (single binary in the container, profiles a partition in seconds on the worker’s existing CPU) writes a profile JSON next to every partition. Downstream, those profiles power freshness/quality dashboards and anomaly alerts (row count cliffs, cardinality spikes, null surges) without ever spinning up a cluster. At enterprise data volumes, the economics are the feature: profiling everything becomes cheaper than deciding what to profile.

5. 🏛️ The data catalog enrichment job. The same enterprise’s governance team runs a data catalog (DataHub/Collibra-class) that is, like most catalogs, well-structured and half-empty — table descriptions exist, but the statistics that make a catalog useful for discovery (cardinalities, distributions, null rates, top values) are stale or missing because computing them across 30,000 tables was never anyone’s priority. A quarterly batch job exports table samples to Parquet and runs dataprof across all of them on a handful of VMs over a weekend — the rayon parallelism and sketch memory-bounds are what make “all of them” feasible — and pushes the JSON profiles into the catalog’s stats API. Analysts searching the catalog now see what the data looks like before requesting access, which measurably cuts the “request access, wait two days, discover the table is useless” cycle that everyone in large-company analytics knows too well.

9. formulaengine — Spreadsheet Formula Computation Engine (Capstone Option B)

Tokenizer → AST → evaluator, dependency graph with topological sort and incremental recalc, 40+ Excel functions, embeddable with PyO3. The “SQLite of formula evaluation.”

1. 🏢 The SaaS startup that needs “formula columns” yesterday. A 30-person startup builds project-management software. Their #2 most-requested feature for two years: computed fields — customers want =IF(due_date < TODAY(), "OVERDUE", status) and budget roll-ups, because every team secretly wants their PM tool to be a spreadsheet. The engineering estimate for building a formula engine in-house (parser, dependency tracking, recalc, fifty functions, correct Excel semantics) was two quarters — repeatedly deprioritized. With formulaengine embedded, the feature becomes UI work plus integration: parse the user’s formula, build the dependency graph across rows, incrementally recalc on edits (their tables hit 50k rows — full recalc per keystroke would be disqualifying; your dirty-set tracking is the load-bearing feature). They ship in five weeks. This exact build-vs-embed decision is happening at hundreds of SaaS companies, and the embed option doesn’t currently exist — that’s the gap, experienced from the buyer’s side.

2. 🏛️ The bank’s template-recalculation server. A bank’s finance operations run on hundreds of Excel templates: month-end close packs, regulatory submissions, branch P&L roll-ups. The current server-side automation opens each workbook in LibreOffice headless to refresh computed values — slow (the 700-second batch from your own LSEG experience), memory-leaky at scale, and occasionally wrong in silent ways (formula cells rendering as zeroes is a documented LibreOffice failure mode — in a regulatory submission, that’s an incident). The replacement: calamine reads the template, formulaengine recomputes the dependency graph, rust_xlsxwriter writes the output — no office suite anywhere in the pipeline. Hundreds of workbooks recompute in seconds, in parallel, deterministically, with circular references reported as errors instead of stale values. The validation suite compares outputs against Excel’s cached values for a corpus of real templates — exactly the Excel-compatibility test suite in your spec, doing exactly its job.

3. 🏢 The pricing team’s no-deploy quote configurator. A 100-person B2B industrial supplier prices custom quotes via rules that change monthly: volume breaks, customer-tier discounts, logistics surcharges, GST treatment. The pricing logic lives in application code, so every change is a sprint ticket, and Sales has learned to quote around the system — margin leaks invisibly. Rebuilt with formulaengine: pricing analysts (Excel natives, the point) maintain the model as formulas — =base_price * (1 - VLOOKUP(tier, discounts, 2)) + IF(weight > 500, freight_surcharge, 0) — in cells the app loads and evaluates per quote. Pricing changes deploy by editing formulas, with a staging sheet and golden-quote tests, not by waiting for engineering. The CFO gets auditability (the formula is the documentation); engineering gets out of the pricing-change business; the formula language being Excel’s means zero training. This is ruleforge’s territory approached from the spreadsheet side — for numeric models, formulas beat rule DSLs because the domain experts already speak them.

4. 🏛️ The great spreadsheet migration’s verification harness. An insurer is migrating 3,000 actuarial and finance spreadsheets into a governed platform (a database + application layer), because ungoverned Excel is their #1 audit finding. The terrifying question for each migrated model: does the new implementation produce the same numbers? Manual spot-checking samples a few cells; meanwhile, the file’s cached values only tell you what Excel last computed, not whether the migrated logic matches the formula logic. The migration team builds a verification harness on formulaengine: parse every formula in the original workbook, evaluate the full dependency graph from the source inputs, and diff — cell by cell, all 3,000 workbooks — against both Excel’s cached values (validating the engine) and the new platform’s outputs (validating the migration). Discrepancies surface as a worklist with cell addresses and dependency traces. Migration sign-off goes from sampled-and-prayed to exhaustively verified — the kind of evidence an audit committee actually accepts.

5. 🏠 The in-browser calculator builder (WASM). A personal-finance blogger wants interactive calculators — SIP growth, loan amortization, tax comparison under old/new regimes — embedded in posts. The standard path is hand-writing each calculator’s logic in JavaScript, where a bug in the EMI formula sits unnoticed in a post read by thousands. formulaengine compiled to WASM changes the unit of authorship: the blogger builds each calculator as a tiny spreadsheet (inputs in named cells, model in formulas — the medium they think in), ships the same engine to every post, and the browser evaluates it locally — no server, reader data never leaves the page. New calculator = new formula set, zero new logic code. It’s the smallest scenario here, but it demonstrates the deepest property: once formula evaluation is an embeddable library, “spreadsheet” stops meaning a document and starts meaning a computational medium you can put anywhere — which is exactly the SQLite analogy made real.

10. ruleforge — Embeddable Business Rules Engine (Capstone Option C)

A rules DSL (when customer.tier == "gold" AND order.total > 5000 then set discount = 0.15), evaluation engine with conflict resolution, chaining with loop detection, and a compliance-grade audit trail.

1. 🏢 The e-commerce promotions engine that marketing runs. A 50-person e-commerce company changes promotions weekly: festival discounts, tier benefits, cart thresholds, payment-method offers. Each change is currently a code deploy, so campaigns launch late and die late (one Diwali offer ran three extra days because the removal PR sat in review — five lakh in unplanned discounts). With ruleforge, promotion logic lives in rule files marketing can read and a marketing-ops person can edit: staged in git, validated by ruleforge validate in CI, golden-cart tests run on every change, deployed by config push at midnight. The explain mode settles the recurring support question — “why did/didn’t this order get the discount?” — in one command showing exactly which rules matched and which superseded which. Engineering’s involvement in promotions drops to reviewing rule-file PRs, which is where everyone wanted it all along.

2. 🏢 The lending startup’s decisioning with an audit trail. The same NBFC-style startup from schemaguard scenario 4, one layer up: their loan pre-qualification logic (income thresholds by employment type, bureau-score bands, geography rules, exposure caps) is scattered across services, and when a partner bank’s audit asks “show us your decisioning criteria as of last March,” the honest answer involves git archaeology across three repos. Rebuilt on ruleforge: the policy is one versioned ruleset; every evaluation emits the audit record — facts in, rules fired, order, outcome — archived per application. Auditor’s question becomes: check out ruleset 2026-03, show the audit logs, done. Rule chaining handles the real shape of credit policy (a “flag for manual review” rule firing changes which subsequent rules apply), and loop detection catches the policy author who makes rule A and rule B trigger each other — at validate time, not in production at 2am. In regulated lending, the audit trail isn’t a feature next to the engine; it’s the reason the engine exists.

3. 🏛️ The insurer’s claims triage at scale. A large general insurer processes ~20,000 motor claims daily. Triage — instant-settle, fast-track, standard, investigate — is governed by rules that change with fraud patterns, regulation, and product launches, currently embedded in a legacy Java service whose two remaining maintainers are a risk register entry by themselves. The fraud team wants rule changes live in days, not quarters. ruleforge as the decision core: claims facts (amount, vehicle age, claim history, garage network status, region risk-scores) evaluate against the ruleset in microseconds; priority-based conflict resolution encodes policy precedence (“investigation triggers always beat fast-track qualifications”); the audit trail satisfies both the regulator and internal QA sampling. The fraud analytics team — data scientists, naturally — ships new red-flag rules weekly through a governed pipeline: propose in a notebook against historical claims (via the PyO3 binding — replaying 12 months of claims through a candidate ruleset takes minutes), backtest the false-positive rate, then promote the rule file. The DS-to-production loop, with no Java in the middle.

4. 🏛️ The data platform’s routing and quarantine policy. The same enterprise data platform from dataprof scenario 4 needs actions attached to its quality signals: when a partition’s profile shows >20% nulls in a critical column, quarantine it; when a vendor feed arrives late twice in a week, downgrade its freshness tier and notify the owner; when PII columns appear in a non-PII zone, block and page. This policy logic is currently if-else sediment across a dozen Airflow DAGs, inconsistent and undocumented. Centralized as ruleforge rulesets evaluated by the ingestion workers (embedded — it’s a Rust service, so the engine links in directly with no sidecar latency), the platform’s operating policy becomes a document: readable by the governance committee, versioned in git, testable against synthetic facts in CI, auditable after every incident (“which rule quarantined this?” has a logged answer). Pipeline policy joins application policy as something you can read rather than reverse-engineer.

5. 🏠 The homelab’s automation brain. A homelab enthusiast runs Home Assistant plus a pile of custom sensors, and their automation logic has reached the YAML-spaghetti stage: motion, presence, time-of-day, AQI (from their airpost-style setup), and electricity-tariff windows interact in ways no one can predict. They embed ruleforge (or run its CLI on a cron loop) as the decision layer: sensor states in as facts, rules like when aqi.pm25 > 90 AND windows.open == true then emit "close_windows_alert" and when tariff.window == "peak" AND geyser.on == true AND presence.home == false then set geyser.target = off — with explain mode finally answering “why did the AC turn off at 9pm?” Priorities resolve conflicts between comfort rules and cost rules explicitly, instead of by YAML file ordering. It’s the smallest deployment imaginable of the same architecture the insurer runs — which is the definition of a good embeddable engine.

11. inferd — ML Model Inference Server (Capstone Option D)

Single-binary CPU inference server: dynamic batching from channels, three backends (your own MLP, ort, candle) behind one trait, hand-rolled metrics, embedding endpoint. Train in Python, serve in Rust.

1. 🏢 The ML startup that halved its serving bill. A 20-person SaaS startup serves a churn-prediction model (gradient-boosted, exported to ONNX) inside their product — every customer-list page view triggers scoring calls. Their FastAPI + onnxruntime service needs four pods to hold p99 under 100ms at peak, and serving is their second-largest infra line item. Swapping the wrapper for inferd — same ONNX file, same predictions (the conformance tests prove it) — the dynamic batcher turns 40 concurrent single requests into a handful of batched inference calls, CPU utilization becomes useful instead of GIL-throttled, and two small pods hold p99 under 15ms. The bill drops by more than half; the latency improvement turns a sluggish page snappy. No retraining, no model change, no data science involvement — which is exactly why the pure-serving-layer swap is such an easy yes for a small team.

2. 🏛️ The internal RAG platform’s embedding service. A large enterprise’s platform team runs internal RAG: every document across wikis, tickets, and policies gets embedded for semantic search, and every user query embeds at ask-time. Scale: tens of millions of documents to (re)embed on every model upgrade, plus thousands of query embeddings per minute at peak — and query embedding sits on the interactive path, where every 50ms is felt. Their Python embedding service is the known bottleneck: backfills take a week, and query p99 spikes whenever a backfill runs. inferd’s embedding endpoint (MiniLM-class model via ort, your own pooling/normalization, dynamic batching that shines on embedding workloads because single-text requests batch beautifully) serves both: batched backfill throughput on one beefy CPU node instead of a GPU queue, and single-digit-millisecond query embeddings that hold steady under backfill load thanks to bounded channels and backpressure. Vectors flow into Qdrant — your OSS-track target consuming your capstone’s output — and the platform team retires a recurring incident category.

3. 🏢 The checkout fraud-scorer with an SLO. A payments startup must score every transaction for fraud inside the authorization window — their contract with the processor allows 150ms total, of which the model gets 20. The model itself (a compact tabular network) takes 2ms; the question is whether the serving layer can guarantee the other 18 under Black Friday load, where Python’s tail latencies (GC pauses, GIL contention, event-loop jitter) are exactly the failure mode. inferd gives them the architecture the SLO demands: bounded max_wait_ms batching tuned to the latency budget (the measured <1ms batching overhead from your spec is the relevant number), per-request latency histograms from the hand-rolled /metrics endpoint feeding their SLO dashboards, and graceful drain on deploy so releases don’t drop in-flight authorizations. The from-scratch feature pipeline matters here too: train/serve skew in a fraud model means approving fraudsters — the golden tests against sklearn’s transform are, in this deployment, revenue protection.

4. 🏠 The private semantic search over a life’s notes. An engineer with eight years of notes — Obsidian vault, exported tweets, bookmarked articles — wants semantic search over all of it without sending a decade of private thought to an embeddings API. (This user is recognizably you: the PKM project with Qdrant in your history is this scenario’s first half.) inferd runs on their laptop or home server as a single binary: local MiniLM via ONNX, POST /v1/embed for each note chunk into a local Qdrant, query-time embedding for search. No Python environment to maintain on the home server, ~tens of MB of RAM idle, fast enough that re-embedding the entire vault after a model upgrade is a coffee break. The same binary later serves a friend’s book-club archive and a partner’s recipe collection — local-first AI infrastructure that ordinary people can actually run is mostly bottlenecked on exactly this kind of tool existing.

5. 🏛️ The factory-floor edge deployment. A manufacturing company runs a defect-detection model (compact CNN, ONNX) at 14 plants. Constraint set: shop-floor industrial PCs (8GB RAM, no GPU), no reliable internet (inference cannot leave the LAN), an OT security regime that audits every byte of installed software, and one visit per quarter from anyone who can fix things. Their pilot — a Docker container with Python, PyTorch, and 4GB of dependencies — failed the OT security review outright. inferd is the shape the constraints demand: one static binary plus one ONNX file, auditable dependency list, runs as a systemd service, exposes /metrics that plant SCADA systems scrape, and hot-swaps a new model file during the maintenance window without touching the binary. The conformance suite across backends earns its keep at the worst possible moment gracefully: when ONNX Runtime misbehaves on plant 7’s ancient CPU (missing AVX2), the candle pure-Rust backend serves the same model from the same config — slower, but running. Edge ML deployment is overwhelmingly a packaging-and-operations problem, and this capstone is, at its core, a packaging-and-operations masterpiece.

How to Use This Document

When a project’s week 3 gets grim — the borrow checker is hostile, the test suite is red, the weekend evaporated — open this file to the project’s section and pick the scenario that feels most like someone you’ve met. Every spec in this program describes what to build; this document is the standing answer to why anyone would care. And note the recurring pattern across all eleven projects: the enthusiast scenario is usually you, the SMB scenario is usually a team that can’t afford the enterprise tool, and the enterprise scenario is usually about where the tool is allowed to run (locked-down hosts, regulated pipelines, edge devices) — which is, not coincidentally, exactly the deployment story Rust’s single-binary, no-runtime model was built for.