The capstone brief, the rubric you are marked against, and the run sheet for presentation day
The timings below assume a worked example of a ten-team cohort — five teams present today, five in Lecture 20. The lecturer adjusts slot length to the actual cohort size; the arithmetic, not the format, is what changes.
| Time | Segment | Activity |
|---|---|---|
| 0–4 min | Opening & Ground Rules | Timing protocol, Q&A etiquette, peer-evaluation forms distributed |
| 4–21 min | Team 1 | 12 min presentation + 5 min Q&A (hard stop at 12:00) |
| 21–38 min | Team 2 | 12 min presentation + 5 min Q&A |
| 38–55 min | Team 3 | 12 min presentation + 5 min Q&A |
| 55–72 min | Team 4 | 12 min presentation + 5 min Q&A |
| 72–89 min | Team 5 | 12 min presentation + 5 min Q&A |
| 89–90 min | Close | Peer forms collected; running order for Lecture 20 confirmed |
Why the opening is only four minutes: five seventeen-minute slots consume eighty-five of the ninety available. Everything administrative that can be read in advance — this page — is not repeated in the room. Arrive having read it.
This page does two jobs. In the weeks before the session it is the brief you build against. On the day itself it is the run sheet. Both halves are below; read the brief now and the run sheet again the night before.
Take a real dataset, model it in a non-relational database, build a dashboard on top of it, and present a business recommendation that the data actually supports.
Four nouns in that sentence carry weight, and each is a place teams lose marks.
| Word | What It Demands | How Teams Get It Wrong |
|---|---|---|
| Real | Data someone generated by doing something — transactions, logs, filings, sensor readings | A synthetic toy file with 200 perfectly clean rows and no missing values |
| Model | A deliberate decision about shape: what is embedded, what is referenced, how keys are named | Dumping a CSV into one flat collection and calling it a document model |
| Dashboard | A view a named decision-maker would open on a Monday morning | Charts built because the tool offered them |
| Recommendation | An action, an owner, and a number attached to the expected effect | "The business should look into this further" |
Teams of three to four. Smaller teams are permitted but are marked against the same rubric — there is no scaling for headcount, so a pair should scope accordingly. Larger teams are not permitted; five people on a project of this size reliably produces two passengers.
Divide the work by stage, not by chart. A workable split for a team of four:
Data owner — sourcing, cleaning, loading, and documenting what was thrown away and why. This is the least glamorous role and the one the Q&A punishes hardest if nobody did it.
Model owner — the embed-versus-reference decision, or the Redis key schema. Must be able to answer "why not the other way?" in one sentence.
Query owner — the aggregation pipelines, the index work, the explain() evidence. Owns the performance story.
Narrative owner — the dashboard layout, the slide arc, and the recommendation. Decides what gets cut, which is the hardest call on the team.
Every team member must speak during the twelve minutes. A team that fields one presenter and three spectators loses marks under Presentation & Q&A, and the silent members are exposed in questioning.
You may use the course dataset — bdma.rides, the 15,000 Delhi NCR ride bookings you have worked with since Lecture 12 — or bring your own. Bringing your own is strongly encouraged, and here is the honest reason: the Uber dataset has been mined in front of you for six lectures. You already know that 62.29% of bookings complete, that drivers cancel 17.99% of them, that the estimated revenue leak is ₹13,33,539, that 18:00 is the busiest hour at 1,373 bookings, and that the worst failure rate among the hours that actually carry volume is 17:00 at 39.92% — higher than the 18:00 peak's 37.14%, even though 18:00 takes 1,373 bookings to 17:00's 1,062. Finding those numbers again demonstrates that you can follow instructions. Finding something new in an unfamiliar dataset demonstrates that you can do the job.
If you do use the Uber dataset, you must take it somewhere Lectures 15–18 did not. Segment by vehicle type and pricing tier, build a driver-reliability score, model the cancellation funnel as a sequence rather than a count, or join it against weather or a public holiday calendar. Re-presenting the course dashboard is marked as an adequate pass at best.
| Source | What You Will Find | Watch For |
|---|---|---|
| Kaggle | Tens of thousands of datasets with documented columns; retail, logistics, healthcare, churn, reviews | Over-used headline datasets (Titanic, Iris, Netflix titles) — pick something with fewer than a hundred public notebooks |
| data.gov.in | Indian open government data: crop prices, rail punctuality, consumption, census extracts, pollution monitoring | Inconsistent encodings and column names that change between annual files — this is realistic, and the cleaning story earns marks |
| RBI Database on the Indian Economy | Banking, payments, credit, state-level macro series | Mostly time series; strong for Redis counters and trend dashboards, weak for document modelling unless enriched |
| NSE / BSE public data | Daily bhavcopy, index constituents, corporate actions, delivery percentages | High volume and high temptation to build a trading signal — stay on the analytics side of that line |
| Your workplace or internship | The highest-value option: a dataset with a real decision-maker attached | Clear it first. Anonymise identifiers, scale or mask revenue figures, and never commit the raw file to a public repository |
| Public APIs | Weather, transit, GitHub events, Wikipedia pageviews — genuinely streaming, which suits Redis | Rate limits; collect over several days rather than in one burst the night before |
Aim for roughly 5,000 to 500,000 records. Below five thousand, no modelling or indexing decision has observable consequences and your explain() comparison will show nothing. Above half a million, the free Atlas M0 tier and your loading script become the project. The course dataset sits at 15,000 for exactly this reason.
A good test before committing: write down the three questions your dashboard will answer, then check the dataset actually contains the columns to answer them. Teams that skip this discover in week three that the field they need was never collected, and spend the remaining time apologising for it on a slide.
Five requirements. All five must be present and visible in the presentation or the repository. Treat this as a checklist and walk it before you submit.
Data loaded into MongoDB Atlas or Redis — or both. If you use both, you must justify the split: which data lives where, and what access pattern drove that boundary. "We used both because the course taught both" is not a justification; "the ride records live in Atlas because analysts query arbitrary fields, and the live counters live in Redis because the dashboard polls every five seconds" is.
At least one non-trivial aggregation pipeline or Redis structure that answers a business question. Non-trivial means more than a $match and a $group — a multi-stage pipeline with $unwind, $lookup, bucketing, or a computed field, or a Redis design using sorted sets, hashes, bitmaps, or HyperLogLog rather than plain string counters. The question must be stated in business language above the code.
At least one index with an explain() before-and-after comparison, or a documented Redis key schema. For MongoDB: show the collection scan, add the index, show the index scan, and quote both totalDocsExamined and executionTimeMillis. For Redis: show the key naming convention, the structure chosen per key, the TTL policy, and the estimated memory footprint.
A working dashboard. Atlas Charts (Lectures 15–16) or the Redis + Node pattern from Lecture 18. Both are acceptable and neither scores higher by default — a well-composed Charts dashboard beats a badly laid-out custom one every time.
The data model decision written down and justified. One paragraph: what you embedded, what you referenced, and why — or for Redis, how keys are named and what the cardinality of each pattern is. This must appear in the repository and on a slide.
| # | Requirement | Evidence the Examiner Looks For |
|---|---|---|
| 1 | Data loaded | Document or key count, load script in the repo, and a note on records rejected during cleaning |
| 2 | Non-trivial query | The pipeline or command sequence on a slide, with its business question stated directly above it |
| 3 | Index or key schema | Two explain() outputs side by side, or a key-pattern table with TTLs |
| 4 | Dashboard | A live demo, or a recorded walkthrough if the venue network fails |
| 5 | Model justification | A slide that names the alternative you rejected and the access pattern that decided it |
On the ESR rule from Lecture 14: if your index serves a query that filters, sorts, and ranges, say so explicitly — Equality fields first, Sort fields second, Range fields last. Naming the rule and showing the compound index that obeys it is one of the cheapest marks available under Technical execution.
12 minutes presenting, 5 minutes Q&A, strictly timed. A timer runs visibly. At 11:00 you get a one-minute warning. At 12:00 you stop, mid-sentence if necessary, and questions begin. This is not pedantry — it is the single most transferable discipline in the room. Every board paper, every investment committee, and every client readout you will ever give has a hard stop, and the people who overrun are the people who did not decide what mattered.
Twelve slides for twelve minutes is the wrong instinct; roughly one minute per slide only works if some slides take ten seconds. The arc below allocates minutes, not slides.
| Stage | Slides | Minutes | What It Must Land |
|---|---|---|---|
| Problem | 1 | ~1 | Whose problem, what it costs today, and who would act on an answer |
| Data & why non-relational | 2 | ~2 | Source, volume, shape — and the specific property that made a relational table a poor fit |
| Model & architecture | 2 | ~2 | Embed vs reference, or key schema; the alternative you rejected; where each store sits |
| Dashboard live demo | 3 | ~3.5 | Three questions answered in front of the room, not a tour of every chart you built |
| Findings | 2 | ~2 | Two or three numbers you are prepared to defend, with their denominators |
| Recommendation | 1 | ~1 | One action, one owner, one expected impact with a number attached |
| Limitations | 1 | ~0.5 | What the data cannot tell you — stated before the panel finds it |
That is twelve slides and roughly twelve minutes. The limitations slide is not optional and is not an apology: naming your own weakest assumption before a questioner does is the strongest move available to you, and it reliably converts a hostile question into a collaborative one.
On the live demo: three and a half minutes is enough for three questions, asked aloud and answered on screen. "Which hour has the worst failure rate?" — click, filter, point at the bar, state the number, move on. It is not enough to narrate a dashboard chart by chart, and attempting that is the most common cause of overrun.
The grade is not for the technology. It is for the decision the data supports.
A simple dashboard with three clear charts and one sharp, quantified recommendation will beat an elaborate one that ends at "here are some charts". Every time. Without exception.
Sharding, change streams, a custom React front end, and a vector index earn you nothing on their own. They earn marks only when they are the reason you could answer a question you otherwise could not. If you cannot finish the sentence "we built this so that the business could decide ___", cut it and spend the time on the recommendation instead.
What a sharp recommendation sounds like: "Among the hours that carry real volume, driver-side failure is worst at 17:00 — 39.92% on 1,062 bookings, against the 18:00 peak's 37.14% on 1,373 — and the leak is worth an estimated ₹13.3 lakh a year. We recommend a ₹40 surge incentive on 16:00–18:00 airport pickups, capped at 300 rides a day. If it converts a third of those cancellations, it recovers about ₹4.4 lakh against ₹1.3 lakh of incentive spend. We would run it for four weeks in one zone first." That is an action, a cost, an expected return, and a test design — in four sentences.
One hundred marks for the project component. The weights are published because you should optimise against them openly — note that sixty-five of the hundred marks go to framing, modelling, and insight, and only twenty-five to technical execution.
| Criterion | Marks | Adequate | Excellent |
|---|---|---|---|
| Business problem framing & relevance | 15 | A plausible problem is stated in general terms; the dataset is loosely related to it | A named decision-maker, a stated cost of the status quo, and a problem narrow enough that the data can settle it. The reader knows what changes if the answer is yes |
| Data modelling decisions & justification | 20 | A model exists and works; the embed/reference or key choice is described | The rejected alternative is named, the access pattern that decided it is stated, and the team can say what would have to change for the other choice to win. Document growth, cardinality, and update frequency are considered |
| Technical execution (queries, indexes, pipelines, key design) | 25 | Requirements met: a working pipeline, an index created, a dashboard connected | Pipelines are efficient and staged deliberately; the index follows ESR and the explain() comparison is quantified; Redis structures are chosen for their properties, not their familiarity. Nothing is in the stack without a reason |
| Dashboard design & clarity | 20 | Charts render, are labelled, and relate to the problem | Layout follows the eye: headline metric first, then the driver, then the detail. Axes carry units, denominators are visible, chart types suit the data, and a stranger could read it with no narration |
| Insight quality & recommendation | 15 | Findings are reported accurately; a reasonable suggestion follows | The recommendation is specific, owned, costed, and quantified, with a stated expected impact and a way to test it. Limitations are named without being asked |
| Presentation & Q&A handling | 5 | Finishes near time; questions are answered; all members present something | Finishes inside twelve minutes with the demo intact; answers are direct; "we don't know, and here is how we would find out" is used where it is the honest answer |
| Total | 100 | Marked by the examiner; peer scores inform the Presentation & Q&A and Insight rows as corroborating evidence | |
Read the rubric as a budget. If your team has four spare evenings, two of them belong to the recommendation and the dashboard layout, not to a fourth aggregation pipeline. The marks say so.
These seven account for most of the marks lost in previous cohorts. None of them are technical failures — every one is a failure of judgement about what the numbers mean.
| Failure Mode | What It Looks Like in the Room | The Fix |
|---|---|---|
| A dashboard with no recommendation | Twelve minutes of charts, then "so that's our analysis, thank you". The panel's first question is "and therefore?" | Write the recommendation slide first, before building anything. If you cannot draft it, you do not yet have a project |
| Vanity metrics | Total records, total revenue, a counter ticking up. Impressive, and nobody can act on any of it | For every metric ask: if this number doubled tomorrow, who does what differently? If the answer is nobody, cut the chart |
| Unlabelled axes and units | A bar chart where the y-axis runs to 4,000 and nobody knows whether that is rides, rupees, or minutes | Label every axis with a unit. Show the denominator next to every percentage — "17.99% (2,699 of 15,000)" |
| Ranking by rate with no volume floor | "The worst hour in our data is 03:00 — a 43.48% failure rate." It has 46 bookings. The team has built a recommendation on twenty failed rides | Put a volume floor in the pipeline before you rank, and show the denominator beside every rate |
| Causation from correlation | "Cancellations are high at 17:00, so drivers avoid the evening peak." The data shows when, never why | Say "associated with", state the alternative explanations you cannot rule out, and propose the test that would separate them |
| A model copied from the course | A new dataset forced into the rides document shape, with embedded sub-documents that never get queried |
Re-derive the model from your access pattern. The Uber model was right for Uber's questions, not for yours |
| A live demo with no fallback | Venue wi-fi drops, Atlas will not load, four minutes of the slot are spent watching a spinner | Screenshots of every demo view in the deck, plus a screen recording. Switch to them within fifteen seconds of trouble and keep talking |
The third and fourth rows above are worth one concrete example, because this is the most common way a technically correct pipeline produces a misleading chart. Rank the course dataset's hours by failure rate alone and the table reads:
| Hour | Failure Rate | Bookings | What It Actually Is |
|---|---|---|---|
| 03:00 | 43.48% | 46 | Noise. Twenty bookings failing instead of eighteen moves this by four points |
| 07:00 | 41.60% | 637 | Suggestive, but still thin for a costed intervention |
| 16:00 | 40.45% | 764 | The shoulder of the real problem |
| 17:00 | 39.92% | 1,062 | The finding. The worst rate among hours carrying real volume |
| 18:00 | 37.14% | 1,373 | The busiest hour of the day — a lower rate on more rides |
Ranked by rate alone, 03:00 wins and sends you chasing forty-six bookings. The statement that survives scrutiny is narrower and more useful: the worst failure rate among the hours that actually carry volume is 17:00 at 39.92% — higher than the 18:00 peak's 37.14%, even though 18:00 takes 1,373 bookings to 17:00's 1,062. That is the sentence a recommendation can be built on, because the hours it names are the hours an intervention would reach.
The fix is one stage in the pipeline — a volume floor applied after the grouping and before the sort:
db.rides.aggregate([
{ $group: {
_id: { $hour: "$booking_datetime" },
bookings: { $sum: 1 },
failed: { $sum: { $cond: [{ $ne: ["$status", "Completed"] }, 1, 0] } }
}},
{ $match: { bookings: { $gte: 1000 } } }, // <-- the volume floor
{ $addFields: { failure_rate: { $divide: ["$failed", "$bookings"] } } },
{ $sort: { failure_rate: -1 } }
])Choose the floor deliberately and state it on the slide. On this dataset $gte: 1000 keeps five hours — 08:00, 09:00, 17:00, 18:00 and 19:00 — and a reviewer can see exactly what you excluded and argue with the threshold. A floor you cannot defend is as bad as no floor; a floor you can is a sign of a team that understands its own numbers.
The room is a review panel, not a classroom. The chair keeps time, the examiner marks, and every other student is an evaluator with a form in front of them. Ground rules:
Every student scores every other team on three dimensions, each on a 1–5 scale:
| Dimension | The Question You Are Answering | 1 | 5 |
|---|---|---|---|
| Clarity of the problem | Did you understand, within the first ninety seconds, whose problem this was and why it mattered? | Still unclear at the end | Obvious immediately and never lost |
| Credibility of the analysis | Do you believe the numbers, and would they survive a sceptical question? | Unsupported or inconsistent | Sourced, denominated, and defended under questioning |
| Strength of the recommendation | Could a manager act on this on Monday? | Vague or absent | Specific, costed, owned, and testable |
Peer scores inform the final mark; they do not determine it. The examiner marks against the rubric. Peer data is used as corroborating evidence — a team the whole room scored 2 on recommendation strength will not be awarded top marks in that row, and a team that visibly carried the room gets the benefit of the doubt on presentation. Scoring your friends uniformly high helps nobody and is visible in the distribution.
Four rules, each learned the hard way by a previous cohort.
Pre-load the data and warm the cluster. Atlas free-tier clusters idle down. Run your dashboard once, ten minutes before your slot, so the first query of your demo is not the one that pays the cold-start cost.
Carry screenshots and a recording. Every view you intend to demo, captured as an image in the deck, plus a two-minute screen recording of the full walkthrough. Rehearse the switch — it should take fifteen seconds and a single sentence: "the network is against us, here is the recorded version".
Do not rely on venue wi-fi. Assume it is congested with forty other devices. Bring a phone hotspot as a tested backup — tested meaning you have actually loaded your dashboard over it, not merely that you own a phone.
Know your own numbers cold. Every figure on every slide: where it came from, what its denominator is, and what it excludes. "I'd have to check" about your own headline metric is the single most damaging answer in the Q&A.
And one security rule that still applies: no connection strings, passwords, or API keys on a slide, in a screenshot, or in a public repository. Blur the host in any Atlas screenshot. Credentials shown to a room of forty people are credentials to be rotated that evening.
explain() evidence or a documented key schema, a working dashboard, and a written model justification.The remaining teams present in shorter thirteen-minute slots, and the last twenty-five minutes pull the whole module together: which database family answers which business question, the five-question decision framework as the course's most portable asset, and the compute-on-read versus compute-on-write trade that ran from Lecture 14 to Lecture 18. If you are presenting in Lecture 20, note the shorter slot and cut a slide now rather than on the day.