The project
Build a private writing assistant that summarizes and rewrites locally, with a clear unsupported-device experience.
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 Gemini Nano and ML Kit do
Distinguish the model, the system runtime and task-specific APIs. Apply the module decision to this project. Your checkpoint: You can explain the relationship between Nano, AICore and ML Kit without treating them as interchangeable names.
2. Compatibility and model readiness
Design for devices where the feature cannot run. Apply the module decision to this project. Your checkpoint: Unsupported hardware and temporarily unavailable model data produce different user guidance.
3. Summarization with factual fidelity
Preserve the source meaning while shortening text. Apply the module decision to this project. Your checkpoint: Your quality check catches meaning changes, not only awkward wording.
4. Rewriting, proofreading and image description
Choose the task API and evaluate its specific failure mode. Apply the module decision to this project. Your checkpoint: You select an API based on the required transformation rather than treating every task as generic prompting.
5. Prompt API and bounded local generation
Use flexible generation without assuming cloud-level capabilities. Apply the module decision to this project. Your checkpoint: Flexible prompting remains bounded by input, output and capability checks.
6. Performance and local-only delivery
Measure resource use and preserve user expectations under load. Apply the module decision to this project. Your checkpoint: Your performance report states the tested hardware and the limits of its conclusions.
Acceptance criteria
- Show unavailable, downloading, ready and failed states
- Demonstrate that private text is not uploaded on fallback
- Compare summary fidelity and rewrite meaning on a fixed evaluation set
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.