The project
Build an offline document classifier with a versioned model package, measured resource use and recovery from corrupted downloads.
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 on-device inference changes
Understand the deployment responsibilities that move into the app. Apply the module decision to this project. Your checkpoint: You can name the assets and runtime assumptions required for offline operation.
2. Model selection and quantization
Choose a model that fits the task and the device budget. Apply the module decision to this project. Your checkpoint: The selected artifact fits both the device budget and the task acceptance criteria.
3. Delivery, verification and storage
Treat model assets as versioned application dependencies. Apply the module decision to this project. Your checkpoint: Only a fully verified package becomes the active model.
4. Runtime integration and inference ownership
Keep expensive local work away from the UI thread. Apply the module decision to this project. Your checkpoint: Your UI remains responsive and ownership of native resources is unambiguous.
5. Hardware acceleration and context costs
Benchmark the actual deployment configuration. Apply the module decision to this project. Your checkpoint: Your performance claims include device, backend, model and workload.
6. Quality evaluation and model upgrades
Ship model changes with the discipline of software releases. Apply the module decision to this project. Your checkpoint: You can roll back a model independently from ordinary user documents.
Acceptance criteria
- Verify model integrity and compatibility before loading
- Benchmark cold start, warm inference and sustained use
- Keep input local and recover from insufficient storage
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.