Lock 2 · Design
AI Architecture
Choosing models, designing pipelines and drawing the architecture diagram evaluators actually want to see — appropriate AI over impressive AI.
10 minute read · applies to Lock 2
Appropriate beats impressive
Lock 2 scores "appropriate use of AI", not "most advanced use of AI". A well-prompted hosted language model with retrieval, a fine-tuned small classifier, or a classical model on good features will beat a half-working ambitious system every time. Choose the least complex approach that genuinely solves your problem, and be ready to defend the choice.
The three honest questions
Answering these three questions in your architecture document demonstrates more engineering maturity than any framework name-dropping. Technical architecture carries 20 points in Lock 2 — these questions are what those points measure.
- What does the model need to be right about, and how right? (Accuracy target, and the cost of being wrong)
- What data will it see at inference time, realistically? (Blurry phone photos, Tamil voice notes, incomplete forms)
- What happens when it is unsure? (Thresholds, fallbacks, human escalation)
Draw the diagram evaluators want
One page: user, interface, backend, model(s), data stores, external services — with arrows showing what flows where, and labels showing what is built versus borrowed. Mark the trust boundaries: where does user data leave the device? Where do third-party APIs see it? A clear diagram with honest labels outperforms an elaborate one with vague boxes.
- Show every external service (model APIs, hosting, storage) by name
- Mark data flows containing personal information
- Distinguish build-time (training/indexing) from run-time paths
- Note latency-sensitive paths and your target response times
Retrieval grounding for language features
If your product answers questions — scheme eligibility, legal steps, medical guidance — raw model knowledge is not acceptable. Ground responses in a curated corpus you control (retrieval-augmented generation), cite the source in the answer, and design the "I don’t know" path. Hallucinated confident answers in a social-impact product are a responsible-AI failure, and both Lock 2 and Lock 3 rubrics will find them.
Plan for the demo you will actually give
Your Lock 3 demo runs on real infrastructure in real time. Architect for that day: seed data prepared, API quotas checked, a recorded fallback for live-demo risk, and costs inside a student budget. Free tiers of major cloud AI services are usually sufficient for a Foundry prototype — architectural cleverness is making them sufficient.
Before you submit — the checklist
- Model choice justified against simpler alternatives
- Accuracy target and cost-of-error stated
- One-page architecture diagram with trust boundaries
- Uncertainty and fallback behaviour designed
- Language features grounded in a controlled corpus with citations
- Inference costs and quotas fit the build window
Related guides
Solution Blueprint
Turning a validated problem into a complete solution design: user journey, feature scope, and the decisions th...
Lock 2 · DesignData Planning
Finding data you can actually use, handling it lawfully, and being honest about its gaps — the part of the blu...
Lock 3 · ProvePrototype Development
Building a working prototype in a student-realistic window: scope ruthlessly, ship the core loop, and make "wo...
Put this guide to work.
The rubric this guide addresses is waiting inside your team’s build journey.
Register Your Team