The project
Harden an AI document assistant with authenticated access, bounded inference, evaluation gates, telemetry and a tested rollback.
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 production readiness means
Translate a working demo into explicit service and product requirements. Apply the module decision to this project. Your checkpoint: Every architecture choice can be traced to a product or operational requirement.
2. Security, identity and data isolation
Protect the application around the model. Apply the module decision to this project. Your checkpoint: An adversarial prompt cannot expand access beyond the authenticated user’s permissions.
3. Reliability, offline behavior and retries
Design useful outcomes when dependencies fail. Apply the module decision to this project. Your checkpoint: Every retry policy is bounded and accounts for possible prior completion.
4. Evaluation and regression gates
Make quality changes visible before rollout. Apply the module decision to this project. Your checkpoint: Your release gate can reject an attractive demo that fails important edge cases.
5. Observability, budgets and privacy
Collect enough evidence to operate the feature without over-collecting user data. Apply the module decision to this project. Your checkpoint: You can diagnose a failed task without routinely storing its full sensitive payload.
6. Rollout, rollback and incident response
Make the release reversible and the operating plan concrete. Apply the module decision to this project. Your checkpoint: Another engineer can disable or roll back the feature from your documented procedure.
Acceptance criteria
- Document trust and data-flow boundaries
- Demonstrate rate limits, timeout recovery and tenant isolation
- Run a held-out evaluation and exercise the feature kill switch
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.