The project
Build a receipt categorizer with App Check, validated output, remote configuration and a tested off switch.
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 Firebase AI Logic does
Place the SDK in the architecture and understand its protection boundary. Apply the module decision to this project. Your checkpoint: You do not use App Check as a replacement for user authorization.
2. Project configuration and first generation
Create a reproducible setup that separates development credentials from release behavior. Apply the module decision to this project. Your checkpoint: A clean checkout can reproduce the setup without an embedded privileged provider secret.
3. App Check and abuse protection
Test access controls before relying on them. Apply the module decision to this project. Your checkpoint: You can show a request rejected because it lacks valid app attestation.
4. Media and structured receipt data
Convert a photo into a validated domain object. Apply the module decision to this project. Your checkpoint: A schema-valid but numerically inconsistent receipt is flagged for correction.
5. Remote configuration and model changes
Control feature behavior without coupling every change to an app release. Apply the module decision to this project. Your checkpoint: The app has useful behavior when remote configuration and inference are both unavailable.
6. Monitoring and release evaluation
Connect quality signals with release decisions. Apply the module decision to this project. Your checkpoint: Your rollout decision includes measured quality and an exercised fallback.
Acceptance criteria
- Show protected production access rather than a debug-only setup
- Test invalid receipts and unsupported output
- Disable inference remotely while preserving manual categorization
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.