At a Glance
Persona: System Administrator + Auditor · Module: recipe · Workflow stages: off-path — configure (categories / cuisines / equipment / RBAC / publish-gate / integrations) and audit (versioning, pricing history) · Key permissions: config write (Sysadmin), read-history (Auditor), soft-delete archived (Sysadmin)
What this persona does: Sysadmin owns master data, RBAC, and integration wiring; Auditor reviews the version and pricing-history trail for compliance.
The Audit / Config persona covers two roles that govern the recipe module's correctness, completeness, and configuration: the System Administrator (owns the recipe-module configuration — tb_recipe_category master data including hierarchy and default_cost_settings, tb_recipe_cuisines master data, tb_recipe_equipment_category and tb_recipe_equipment masters, the recipe RBAC mapping recipe:create / edit / publish / archive / edit-published / edit-cost / approve-menu-link / read / read-history, the publish-gate tenant policy that decides whether off-target margin publishes require Cost Controller co-approval, and the integration wiring with [product](/en/inventory/product) / [inventory](/en/inventory/inventory) / [store-requisition](/en/inventory/store-requisition) for theoretical-consumption fan-out and SR auto-create) and the Auditor (read-only review of recipe history — tb_recipe_version snapshots, tb_recipe_pricing_history timeline, the per-row audit columns created_by_id / updated_by_id / created_at / updated_at, the publication / archive timestamps published_at / archived_at, the comment thread on each tb_recipe_version.change_summary — to confirm controls are operating, off-target publishes are co-approved, and the chain of revisions reconciles to the authority model). Neither role acts on the recipe happy path; they act on the periphery — before any recipe exists (config), during the lifecycle (RBAC enforcement, integration health), and after publish (audit trace). The Sysadmin holds full read / write on configuration tables and the RBAC mapping; the Auditor is read-only on the recipe library (recipe:read + recipe:read-history) and on configuration history. There is no "void" or "admin-cancel" path on the recipe — recipes are not transactional documents; data hygiene on archived recipes is the only delete authority, and it sits with the Sysadmin per REC_AUTH_014.
Entry points (one per sub-role):
REC_XMOD_005 / REC_XMOD_006), recipe → SR auto-create wiring (REC_XMOD_007), recipe → inventory theoretical-consumption fan-out (REC_XMOD_003).tb_recipe_version browser for any recipe; timeline view; per-version diff (header / ingredients / steps / variants JSON snapshots).tb_recipe_pricing_history timeline; filter by date, change reason, recipe category.Primary flow (oversight / configuration, 10 steps — runs continuously across periods, not per-recipe):
tb_recipe_category hierarchy (Appetiser / Main / Dessert / Beverage / ...; sub-categories below); set default_cost_settings per category (target food-cost %, labor / overhead percentages) which new recipes will inherit at create time. Cost Control Department signs off on the category-level targets.tb_recipe_cuisines with the cuisines the operation serves (Thai / Italian / French / Japanese / fusion), each tagged by enum_cuisine_region; populate popular_dishes and key_ingredients for menu engineering context.tb_recipe_equipment_category and tb_recipe_equipment with the kitchen equipment catalogue (ovens, sous-vide rigs, mixers, etc.) so chefs can reference equipment in prep-step JSON.recipe:create / edit / publish / archive / edit-published / edit-cost / approve-menu-link / read / read-history.actual_food_cost_percentage > target + tolerance) require Cost Controller co-approval per REC_AUTH_007; decide whether edits to PUBLISHED recipes apply in-place with versioning (REC_POST_004) or require un-publish round-trip (REC_POST_005); decide the tenant tolerance band for off-target detection (commonly 2 percentage points).REC_XMOD_007), recipe → inventory theoretical-consumption (REC_XMOD_003), recipe → menu-item linkage (REC_XMOD_008) — are operational. Failures in any chain show as integration alerts.Restrict FK from tb_recipe blocks hard delete; soft delete is the operational pattern); merge duplicate categories; reorder hierarchy. Sysadmin coordinates with Cost Control Department on category-level changes that affect target food-cost %.PUBLISHED recipes across the period; for each, verify: (a) the publish event has a corresponding tb_recipe_version row with published = true and change_summary populated; (b) when actual margin was off-target at publish, a Cost Controller co-approval is recorded in the change_summary or signoff log per REC_AUTH_007; (c) all edits to PUBLISHED recipes wrote a new tb_recipe_version row per REC_POST_004; (d) all cost / price changes wrote a tb_recipe_pricing_history row per REC_POST_010 with a populated change_reason; (e) audit columns reconcile (created_by_id is a known user; updated_by_id chain is consistent).tb_recipe_pricing_history.change_reason indicates a sub-recipe cascade (REC_POST_006) or a cost-drift update from costing (REC_XMOD_006); verify the cascade chain is internally consistent (the parent recipe's cost change reconciles to the sub-recipe's cost change and the leaf ingredient's cost change); verify the cascade triggered review actions where the resulting margin moved outside tolerance (Cost Controller signoff or Chef revision).PUBLISHED edits: Sysadmin chooses between (a) edit_published_with_versioning = true (edits apply immediately to the PUBLISHED recipe; tb_recipe_version row written; theoretical consumption uses the new formula from edit timestamp onward) and (b) edit_published_with_versioning = false (edits require PUBLISHED → DRAFT round-trip; recipe doesn't drive theoretical consumption while in DRAFT; safer audit but more operational friction).REC_AUTH_007. Tighter tolerance = more co-approvals (more control friction); looser tolerance = fewer co-approvals (more autonomy for chefs).ARCHIVED recipes before soft-deleting for data hygiene (commonly multi-year for compliance / audit, then soft-deleted). Soft-deleted rows remain in the database (auditable) but disappear from default queries.The Audit / Config persona's involvement does not "end" per recipe — it is ongoing oversight. Individual oversight actions have well-defined handoffs:
The Audit / Config persona is the safety net of the recipe module — they do not author recipes, but they configure the rails the other personas run on (categories, cuisines, RBAC, policies), verify that the rails were followed at audit time (versioning, co-approval signatures, cost-drift trace), and ensure the integration with upstream cost data and downstream consumption is healthy.
../carmen/docs/recipe-module/RECIPE-Overview.md § General Users (and the wiki index System Administrator row) — carmen/docs source for Sysadmin scope; auditor role is implicit in the audit / compliance context.../carmen/docs/recipe-module/RECIPE-Business-Requirements.md § Maintenance and Governance — Ownership, Review Process, Change Management; informs the Sysadmin / Auditor responsibilities.../carmen/docs/recipe-module/RECIPE-PRD.md § Non-Functional Requirements (§ Security, § Scalability) — RBAC, audit logging, multi-location support.../carmen/docs/recipe/setup-pages-spec.md — page-spec source for the setup / config screens the Sysadmin operates.../carmen/docs/recipe/recipe-management.md § Recipe Categories Management — layout-level reference for category-master administration.tb_recipe_version history.default_cost_settings affect the Cost Controller's per-recipe targets; Auditor verifies cost-only edits trigger pricing-history rows.recipe:approve-menu-link permission F&B Ops uses; Sysadmin wires the substitution-request channel.tb_recipe_version (full snapshot audit trail), tb_recipe_pricing_history (cost / price timeline), audit columns (created_by_id, updated_by_id, published_at, archived_at); master-data tables (tb_recipe_category, tb_recipe_cuisines, tb_recipe_equipment_category, tb_recipe_equipment).REC_AUTH_007 (Cost Controller co-approval gate), REC_AUTH_011–REC_AUTH_014 (F&B Ops / Sysadmin / Auditor authority), REC_POST_009 (soft-delete), REC_XMOD_009–REC_XMOD_010 (audit / versioning, RBAC).is_used_in_recipe flag on products that gates whether a product is eligible as a recipe ingredient.