What you should be able to do
- Read a recipe as a controlled specification.
- Separate base recipe from customer modifiers.
- Use version control for production recipes.
- Build a recipe card that survives shift changes.
Recipe architecture
Every recipe should identify its base, size, coffee component, liquid components, sweeteners or modifiers, ice, garnish and assembly order. Espresso parameters should reference the current dial-in specification rather than duplicating stale grinder settings everywhere.
Base vs modifier
The base recipe is the approved default. Customer choices—less sweet, alternative milk, extra shot, iced, larger size—should map to controlled modifier rules. This prevents every custom order from becoming an improvised recipe.
Version control
Include recipe ID, version, effective date, owner and approval status. When a recipe changes, archive the old version so operational incidents can be reconstructed.
Scaling and yield
When moving between cup sizes, validate flavor balance instead of merely multiplying every ingredient. Document expected finished beverage mass or fill line where this improves consistency.
RasoKarsa prototype families
Use the library to organize espresso/black, milk coffee, flavored signatures, Indonesian origin brews and seasonal drinks. Production values should be finalized through tasting and operational trials.
Training vs production
Training recipes can intentionally simplify variables. Production recipes must account for actual equipment, bean lot, roast profile, milk formulation, ice, cup geometry and food-safety requirements.
Apply the lesson
Take one current café drink and rewrite it as a version-controlled recipe card with base recipe, allowed modifiers, assembly order, QC check and escalation rule for unavailable ingredients.
Open Coffee Lab ↗Test your understanding
Pass at 70% or higher, then mark the module complete. You can retry as many times as needed.
Progress is stored locally in this browser. Completing a module does not issue a formal certification.