A design for exactly what your model sees on every request. Five decisions, each named and defended: sources, chunking, retrieval, ranking, and assembly.
What this is
Decide what reaches the window, on purpose.
The first of five production artifacts. It does not need to be built, it needs to be decided and defensible: a reader could stand up your pipeline from it. Pairs with Lab 2 if you want to build it too.
💡 In plain English
"We use RAG with a vector database" is a logo, not a design. This is where you turn that into real choices: what corpus, how you cut it up, how you find the right bits, how many survive, and what you deliberately leave out.
Do this, in order
The five decisions.
1
Name the sources and the access ruleWhat is the corpus, how fresh must it be, and who is allowed to retrieve what? Security starts here.
2
Choose the chunk unit and metadataWhat is one retrievable piece, and what must travel with it (source, date, permissions)?
3
Pick retrieval and rankingHybrid or not, filters, first-pass size, re-rank method, how many survive, the score floor.
4
Set the window budget and orderTokens for context, assembly order (best chunk near the question), dedup, and what you cut when it overflows.
5
State how you'll know it works, and the failure pathsOne success metric, plus your answers for ungrounded, stale, and leaked context.
I'll know it helps when … · ungrounded/stale/leaked handled by …
How it's marked
What good looks like.
✓ Strong submission
Every decision names a specific choice and a reason a stranger could build.
Access and freshness are decided at the source, so security and staleness are handled by design.
Failure paths for ungrounded, stale, and leaked context are explicit.
✕ Common mistakes
"RAG with a vector database" and nothing else.
No chunk unit, no ranking, no budget.
Retrieval grabs everything and filters permissions later, or never.
Wrapping up
One page, decided and defensible.
The filled template plus your pipeline diagram is the whole deliverable. Skip code and tool brand-names. This design is the backbone your later artifacts extend, and it plugs straight into the Week 5 eval harness.
Deliverable
The five decisions + a diagram + your success signal. Due Sun Jul 26.
submit on Maven
Stuck?
Use the S3 cheat sheet params as sane defaults, then justify any change. A defensible default beats a blank.
rewatch S3 + S4
For the instructorHow to teach thisclick to open ▾
The whole grade is specificity. Push back on any logo-not-a-decision line: "which re-ranker, keeping how many, above what floor?" The blanks a student cannot fill are exactly the parts of their design that are not finished, and naming that is the value.
Insist on step one, the access rule before retrieval. It is the security lesson from Week 4 arriving early, and the difference between a design and a future incident. Demo the support-assistant example from S4 live so they see the target density.