The project
Build a travel brief assistant that extracts a typed itinerary and asks for confirmation before saving it.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What the Gemini API provides
Understand models and API capabilities before writing the client. Apply the module decision to this project. Your checkpoint: You can explain where model credentials live and how a user request is authorized.
2. Building the first request
Make generation reproducible and observable. Apply the module decision to this project. Your checkpoint: Every response shape maps to a domain result rather than a null crash.
3. Conversation and streaming
Maintain coherent sessions under cancellation and changing screens. Apply the module decision to this project. Your checkpoint: Late chunks cannot update the wrong conversation.
4. Structured output and validation
Turn model text into data without confusing a schema with truth. Apply the module decision to this project. Your checkpoint: Typed output is never persisted before domain validation succeeds.
5. Function calling and safe execution
Keep model planning separate from application actions. Apply the module decision to this project. Your checkpoint: A model-generated tool request cannot bypass your normal application permissions.
6. Evaluating and operating Gemini features
Make prompt changes reviewable and production behavior bounded. Apply the module decision to this project. Your checkpoint: You can defend the selected configuration with task-level evidence.
Acceptance criteria
- Keep privileged provider credentials out of the APK
- Reject unsupported or malformed itinerary data
- Demonstrate cancellation, tool rejection and a model timeout
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.