Your six — recipes, dishes, sub-recipes, ingredients, versions, approval status — are the objects below. Two layers first.你问的六项——食谱、菜品、子配方、原料、版本、审批状态——都在下面这些物件里。先讲两层。先两层，再十个物件。
Supplier, pack, unit, allergens printed on the packaging. The kitchen doesn't make these — it uses them.
Ingredient list + method + yield. Marked either sub-recipe (referenced by others) or dish (what leaves the pass). Same structure either way.
Why they must stay apart:为什么必须分开：把这两层分开不是为了整齐，是为了下面这件事：
The dish and base genep are from your menu; everything under them is generic. I've used placeholder names for the components rather than guess at how you actually build them.菜名和 base genep 取自你们的菜单；底下的层级是通用示意。各个元素我用的是泛称，没有去猜你们实际怎么做。 Only base genep is opened up here — every sub-recipe has its own ingredient lines; expanding them all would make the diagram unreadable. 这里只展开了 base genep——每一份子配方底下都有自己的原料行，全展开的话图会挤成一团。
The base genep sheet lists candlenut and shrimp paste — written down once, when that sheet was made. The Pork Belly sheet simply names base genep; nobody rewrites its contents on every dish that uses it, and there is no reason they should.base genep 那张纸上当然写了烛果和虾酱——写过一次，在它被建立的时候。Pork Belly 那张纸只写「base genep」；没有人会在每一道用到它的菜上再抄一遍，也没必要。
So the information exists — one document away. What it needs is joining up at the moment it matters: the station card reads crustacean at the top because the system walked down the recipe, collected what each ingredient record already says, and carried it back up. Traced through the recipe, rather than depending on someone remembering it at the pass.所以信息是有的——只是在另一张纸上。缺的是在真正需要的那一刻把它们接起来：出菜口那张卡最上面写着甲壳类，是因为系统顺着配方往下走，把每张原料卡上早已写好的东西收集起来，再一层层带回上面。顺着配方查出来的，而不是靠出菜的人记得住。
| Object | Fields in scope 本次字段 | Rule that matters |
|---|---|---|
| Ingredient | name · aliases (terasi / trassi / belacan) · category · base unit · unit conversions incl. density · supplier & pack · allergens · allergens_verified · verification source · trim/yield loss · status | Allergens are derived from here, never guessed from recipe text.过敏原从这里推导，绝不从食谱文字猜。未核实 → 所有用到它的食谱全部卡住。 Not verified → every recipe using it is blocked. |
| Recipe | code · name · role: dish | sub-recipe · section/station · created · archived | Permanent facts only.只放永远不变的东西。配料、做法、产出量都不在这里——否则改一次食谱就等于改掉它自己的全部历史。 No ingredients, no method, no yield here — otherwise editing a recipe would silently rewrite its own history and "approved is frozen" would be false. |
| Recipe version |
version no. · status · yield qty + unit · portions & portion size · method steps (ordered) · equipment · storage · shelf life · plating photo & notes (optional) · missing_fields state · change reason · created/reviewed/approved by · approved date · effective date · source (photo / audio / transcript / extraction run) | The only place content lives. Approved = frozen;内容的唯一归属地。批准即冻结，改动产生新版本，旧版保留。产出量必填——被引用时的换算基准。 changes create a new version and the old one is kept. Yield is mandatory — it's the conversion basis whenever this recipe is referenced by another. |
| Recipe line |
position · type: ingredient | recipe · target · binding: follow current approved | pinned · pinned version · quantity + unit · prep note · prep loss % · optional | One row per line of a version.版本底下的每一行。它指向的是那个子配方，不是它的某一版——由引用规则决定跟不跟随。这一行就是十二道菜那题的全部答案。 It points at the sub-recipe, not at one of its versions — the binding field decides whether it follows. This row is the whole twelve-dishes answer. |
| Dependency | ancestor recipe · descendant recipe · depth | Maintained automatically. Answers "what uses this" instantly, blocks circular references, and finds every downstream item when something changes.系统自动维护。秒答「什么用到了它」、阻止循环引用、变更时找出全部下游。 |
| Impact record |
source version · affected version · materiality: allergen | yield | method | cosmetic · allergen delta · yield delta · resolution · resolved at | Generated automatically the moment a sub-recipe is approved.子配方一批准就自动生成一批。这是审核队列的输入。 This is what feeds the review queue. |
| Review task |
target version · type: new import | edit | upstream change · triggering version · assigned role & person · state · opened / closed · decision | Where approval routing actually lives.approval routing 真正落地的地方。没有它，审核队列只是一个筛选视图——没法指派，也没法追踪。 Without it the review queue is only a filtered view — nothing to assign, nothing to chase. |
| ROOTS / SOP doc |
category · title · version · approval status · linked recipes · publish target | An output document generated from approved content由已批准内容生成的输出文件——不是第二个要另外维护的资料库。 — not a second, separate library to maintain. |
| Audit log | entity · actor · timestamp · action · before · after | Append only.只增不改。「哪一版、谁批的、哪天」最后的凭据。 The final evidence for "which version, approved by whom, on what date". |
The one field to confirm: binding, on the recipe line. Everything in section 02 depends on it.要确认的就是那一个字段：配料行上的「引用规则」。第 02 节讲的一切都靠它。
One rule, three parts. This is what I'd recommend, and confirming it is the main thing I need.一条规则，三个部分。这是我的建议，确认它是我最需要的东西。
Nothing is ever overwritten. Editing an approved recipe does not change it — it opens the next version. That is what makes “which version was the kitchen using on the 20th” a question with an answer.没有任何东西会被覆盖。改一份已批准的食谱不会改到它本身，而是开出下一个版本。正因为这样，「20 号那天厨房用的是哪一版」才是一个答得出来的问题。
| Rule 规则 | What it means 意思是 |
|---|---|
| Approved documents are pinned | A published recipe holds the exact sub-recipe versions it was approved with. Nothing inside a document the kitchen is working from changes on its own.已批准的文件固定住批准时用的那些子配方版本。厨房正在用的文件，内容绝不会自己变。 |
| An update creates drafts, not changes | When a sub-recipe is approved, the system finds every affected dish and opens a new draft for each, showing what changed. You approve them in one pass instead of hunting for them.子配方一批准，系统找出每一道受影响的菜，各自生成新草稿并标出改动。你一次性批准，不用自己去找。 |
| Allergen changes need confirmation | If an allergen appears or disappears, the affected published documents are flagged immediately and cannot be replaced until you have reviewed each one.过敏原一旦增减，受影响的已发布文件立刻挂标记，在你逐份过目前不能被替换。 |
The system does the finding and the drafting, but nothing reaches the kitchen that a person hasn't approved. A dish can also be held back deliberately to run out an existing batch.找下游、生成草稿都由系统做，但没有任何东西会在没人批准的情况下到达厨房。某道菜也可以刻意不跟进，把现有那批用完。
Your question, under Option B. Both cases are clickable.你的问题，在方案 B 下的结果。两个情境都可以点。你的问题，用方案 B 走一遍。下面两个情境都可以点。
Illustration only. Menu names are real; which dishes use the sub-recipe, and both scenarios, are assumed.仅为演示。菜名是真的；哪几道用到该子配方、以及两个情境，都是假设。
| What changed 改了什么 | What the system does 系统怎么做 |
|---|---|
| An allergen | Published documents are flagged and held. Each affected dish is reviewed individually before anything is replaced.已发布文件挂标记并暂停替换。每一道受影响的菜逐份过目。 |
| Method or yield | A new draft per affected dish, change shown. Approve in one pass.每道受影响的菜生成新草稿，标出改动，一次性批准。 |
| Ingredient quantity | Same — drafts, with quantities recalculated where the yield moved.同样生成草稿；产出量有变的，用量自动重算。 |
| Wording only | Drafts too, flagged as cosmetic so they can be accepted in bulk.也生成草稿，但标为纯文字，可批量接受。 |
You asked for allergens, shelf life and a description that is 100% right. That is only reachable if the system will refuse rather than guess.你要求过敏原、保质期和操作描述 100% 正确。唯一做得到的方式，是让系统宁可拒绝，也不猜。你要求过敏原、保质期和操作描述 100% 正确。做到这一点的唯一方式，是让系统宁可拒绝，也不猜——手写纸上通常没写这两样，让模型去补，它会给出一个自信、合理、偶尔是错的答案。
Worked example, not one of your sheets. I wrote this prep sheet to show what the system does and does not fill in. The base genep ingredients follow the standard Balinese preparation.这是我编的示例，不是你们的纸。写它是为了演示系统会补什么、不补什么。base genep 的配料用的是巴厘岛通行做法。
So it cannot publish. One unverified ingredient blocks every recipe that uses it.所以它发布不了。一样未核实的原料，会卡住所有用到它的食谱。所以这份食谱发布不了。它停在草稿，直到三件事补齐：产出多少、能放几天、谁核实虾酱那笔资料。一样未核实的原料会卡住所有用到它的食谱——这让每一条过敏原信息都是有人负责的。
This is the approval routing from your second milestone. Worth agreeing who does what before the queue is built.这是你第二个里程碑提到的 approval routing（审批路由）。谁能做什么，值得在建队列之前先谈定。
| Role 角色 | Can see 能看 | Can edit 能改 | Can approve 能批准 |
|---|---|---|---|
| Admin | All recipes and versions全部食谱与版本 | People, categories, settings人员、分类、系统设置 | Manages publishing rights管理发布权限 |
| Head chef | Drafts, review queue, history, impact lists草稿、审核队列、历史、影响清单 | Correct or reject anything修正或退回任何内容 | Yes — including the effective date可以，含生效日期 |
| Recipe editor | Their own scope and its history负责范围及其历史 | Create and edit drafts建立与修改草稿 | No |
| Manager | Versions in force, plus change notices现行版本与变更通知 | Not in this project本次不开放 | Acknowledge receipt only仅确认已收到 |
| Kitchen | The current approved version当前批准版 | No | No |
Indicative layout only. Sketched to show what each person deals with day to day — not a design proposal, and not what the finished screens would look like.仅为示意排版。画出来是为了说明每个人每天面对什么，不是设计方案，也不是成品的样子。
Your two-milestone structure is right and I'd keep it. Actual duration depends on the condition of the source material — how clear and consistent the recipes are — and may run to eight weeks.你分两个里程碑的结构是对的，我会保留。实际时长取决于原始素材的状况——食谱有多清楚、多一致——有可能到八周。
| Milestone 里程碑 | Indicative 大致 |
|---|---|
| Milestone 1 schema · import · 20 recipes |
Two to three weeks where the source material is legible and reasonably consistent. Where it isn't — mixed handwriting, missing quantities, inconsistent naming — this is the part that stretches, because every one of those has to be resolved by a person before the recipe means anything.两到三周，前提是原始素材清楚、格式还算一致。若不是——手写混杂、分量缺漏、命名不统一——拉长的就是这一段，因为每一处都要有人确认，食谱才有意义。 |
| Checkpoint | Unchanged from your proposal. Below 60%, we stop and improve extraction before any interface work is started.与你的提议一致。低于 60% 就停下来先改进抽取，不动任何界面。 |
| Milestone 2 queue · versioning · staff view · ROOTS |
Four to five weeks, on the basis of a read-only staff view, one-way publishing, and approval resting with you plus one named second. Anything beyond that we would scope separately.四到五周，前提是员工端只读、单向发布、批准权限在你和一位指定的人。超出这些的部分另行界定范围。 |
Locking the schema, building the import, and proving the extraction against twenty real recipes. 锁定 schema、把导入建起来，以及用二十份真实食谱验证抽取。
| In this milestone 这个里程碑内 | Deliberately not yet 刻意先不做 |
|---|---|
| Schema built · import running · twenty recipes converted · an accuracy report showing, per recipe, what the extraction produced and what a person had to change schema 建成 · 导入跑通 · 二十份食谱转换完成 · 一份逐份对照的准确率报表：抽取产出了什么、人工改了什么 | The review queue, the staff view, the Notion publishing — all of that belongs to Milestone 2. Keeping this milestone that narrow is what makes the checkpoint mean something: it tests the reading, not the product. 审核队列、员工端、Notion 发布，都属于 Milestone 2。把这个里程碑收得这么窄，检查点才有意义——它验的是「读得准不准」，不是「产品好不好」。 |
Why this decides the timeline: the build is the same either way — the reading is not. A typed document already has structure and can be taken almost directly. A photograph of handwriting has to be read first, and every quantity, abbreviation or unclear word the system is not certain about has to be confirmed by a person. That confirmation happens recipe by recipe and does not get faster with volume. 为什么这决定了时间：不管哪种格式，开发的部分是一样的——差别在「读」。 打字文件本身就有结构，几乎可以直接接收。手写照片得先认出来，而凡是系统没把握的分量、简写、看不清的字，都要有人逐一确认。这个确认一份一份做，不会因为量大而变快。
A few Milestone 2 details, while you're looking:以下是关于 Milestone 2 的细节，也顺便先让你过目：
I've taken the 60% to mean extraction accuracy: whether the system read the handwriting or the audio correctly. A recipe can sometimes be read very accurately but still not be ready to publish, because an ingredient's allergen data is still waiting on a supplier. Keeping extraction accuracy and data completeness separate would make it clearer — does that match how you were thinking about it? 我理解 60% 衡量的是「AI 抽取准确率」——系统有没有把手写纸或语音读对。有时候一份食谱读得很精准，但可能因为原料的过敏原还在等供应商确认而暂时无法正式发布。把「抽取准确率」与「资料完整度」分开来看会更清晰，不知道这是否符合你原本的想法？
Once I've seen a handful of your actual recipes I can narrow the range considerably.等我看过几份你们真实的食谱，这个区间可以收窄很多。
A proposal, not a position.这是建议，不是立场。
| What 什么 | Proposed 建议 |
|---|---|
| Your content | Your recipes, SOPs and source materials remain yours. They may be processed by authorised AI and cloud service providers solely to build, operate and support your system. They will not be reused for other clients, disclosed outside authorised service providers, or used to train any shared or general-purpose AI model. You may export your data at any time in standard formats, whether or not we continue working together.你们的食谱、SOP 与原始素材仍归你们所有。它们可能由经授权的 AI 与云端服务商处理，且仅用于建立、运行与维护你们的系统。不会挪用到其他客户、不会披露给授权服务商以外的任何一方、也不会用于训练任何共享或通用的 AI 模型。你们随时可以标准格式导出自己的资料，无论我们是否继续合作。 |
| The delivered version | Your restaurants may keep using the version delivered in this project, internally, long term.你们的餐厅可以长期在内部继续使用本次交付的版本。 |
| Not included | Source code, schema and the extraction pipeline are not part of the delivery.源码、schema 与抽取流程不在交付范围内。 |
| Future work | Anything built after this project — new functionality, later versions — is a separate commercial conversation.本项目之后新建的东西——新功能、后续版本——属于另一次商务讨论。 |