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.本项目之后新建的东西——新功能、后续版本——属于另一次商务讨论。 |
Recording these here so we're working from the same page. Correct anything I've read wrong.记在这里，免得我们各记各的。有读错的地方随时纠正我。
| Question 问题 | Your answer 你的回覆 | What I've taken from it 我的理解 |
|---|---|---|
| Format of the 20 recipes | Typed documents打字文件 | The best case for extraction — no handwriting to decipher. It lets me commit to the shorter end of the range rather than the longer one.抽取上最理想的情况——没有手写要辨认。这让我可以按区间的短端承诺，而不是长端。 |
| Ingredient records | Confirmed确认 | Taken as: your team completes them in the app. The progress tracking below is there to make that manageable.理解为：由你们团队在 app 里完成。下面的完成度追踪就是为了让这件事管得住。 |
| Standard layout | You'll share what you've set up in Claude你会分享你在 Claude 里已经设定好的东西 | I won't design a format until I've seen yours.在看到你那套之前，我不会自己设计版面。 |
| ROOTS | A new restaurant opening in December. All recipes ready by the beginning of October.十二月开的新餐厅。全部食谱十月初备齐。 | This is the most significant thing in your reply — it turns the timeline from an estimate into a date. See the two notes below.这是你回覆里最重要的一条——它把「估算」变成了「日期」。见下面两点。 |
| Notion | Currently Notion, open to Airtable or other — “as long as it's easy to use for the team”目前用 Notion，也可以是 Airtable 或其它——「只要团队好用」 | Then I'd suggest building the staff view directly rather than integrating with a third tool. Fewer moving parts, and it can be shaped around what the kitchen actually needs.那我建议直接做员工端，而不是去集成第三方工具。环节更少，而且可以完全按厨房实际需要来做。 |
| Filling in what's missing | Directly in the app — allergens, yield, pictures — complete in one session直接在 app 里补——过敏原、产出量、照片——一次补完 | Built as a single completion screen per recipe rather than scattered fields. Added to the second milestone.做成每份食谱一个「一次补完」的界面，而不是散落各处的字段。加进第二个里程碑。 |
| Keeping it moving | Show current % status, remind on opening显示当前完成百分比，打开时提醒 | Added, at no extra cost — it's the thing that makes the difference between a system people fill in and one they don't.已加入，不额外计费——这正是「大家会去填」和「没人填」的分界。 |
1 · The October date now governs everything. Working back from the beginning of October, there is room for the six weeks but not much more, and that assumes we start promptly. I'd rather say that now than discover it in week five.1 · 十月这个日期现在决定一切。从十月初往回推，六周放得下，但余地不多，而且前提是尽快开始。我宁可现在说，也不想第五周才发现。
2 · Your original scope said “first ROOTS documents”. All the recipes for a new restaurant is a larger piece of work, and the volume matters — I'd keep it separate from the fixed price rather than fold it in, so neither of us is guessing. Whether those recipes already exist, or get written over the next couple of months, changes the answer quite a bit.2 · 你原本写的是「first ROOTS documents」（头几份）。新餐厅的全部食谱是更大的一块，而且数量很关键——我建议把它跟固定价分开，而不是并进去，免得双方都在猜。那些食谱是已经写好了，还是接下来两个月才会陆续写出来，答案差别很大。