面向高端海鲜加工商的剩余货架期认证 OS，把宰杀节点和冷链数据变成更高毛利、更低损耗的批次。

1. 人道宰杀正从手艺活变成可重复的机器流程，加工商终于能在鲜度开始分化的那一刻，把数据标准化下来。
2. 瞬时宰杀既能拉长货架期，又能减少浪费，所以只要软件能证明多出来的剩余天数，就能直接把毛利抢回来，而不是只讲一个模糊的可持续故事。
3. 码头端具备鱼种识别能力后，就能按鱼种去建鲜度窗口模型，而不是继续拿一条保守规则套所有批次。
4. 风投开始押注码头端海鲜自动化，说明运营端和资本端都愿意为这一步投技术，旁边的数据层也就出现了分发窗口。

催化因素。 自动化、计算机视觉引导的 ike jime 设备已经出现，人道宰杀因此开始标准化、机器可读化，按批次给出鲜度保证这件事才第一次真正可落地。

Dockside Freshness Certification OS 会接入人道宰杀设备或标准化收货流程产生的机器数据，为每个鱼货批次分配数字 ID，再把鱼种、宰杀时间、温度和处理数据合成一段可预测的可售窗口。QA 团队在装箱前就能看到面向餐饮、商超或批发买家的推荐分级、分流建议，以及承诺的剩余货架期天数。买家拿到的是一张可审计的证书，能看清这个批次怎么处理、为什么配得上高溢价渠道，从而减少扯皮和一刀切压价。时间一长，平台还会学会哪些处理模式真的能换来更高成交价和更低损耗，最终沉淀成跨加工商、跨鱼种的专有基准数据。

差异化。 这不是另一台宰鱼机器人，也不是一个通用海鲜追溯系统。产品从“品质被创造出来”的那一刻——也就是宰杀节点——切入，把分鱼种的处理数据转成货架期确定性、分流建议和买方可验证的证据。每多一个完成认证的批次，这套数据就更厚一层；而鲜度基准和价格兑现模型，单个加工商、ERP 厂商或传感器厂商都看不到全市场，因此很难复制。

待完成任务

flowchart LR
  Buyer[QA leader at premium seafood processor] --> Pain[Unprovable freshness and lot downgrades]
  Pain --> Product[Dockside Freshness Certification OS]
  Product --> Outcome[Higher realized price and lower seafood waste]

高管要点

• 自动化 ike jime 把人道宰杀从手艺活变成可重复的数据事件；多份来源都把低应激、充分放血和快速冷却，与更好风味和更长货架期直接连在一起。[1][39][41]
• 缺口不只在流转链条：加工商本来就得应付 HACCP、FSMA 204、SIMP、出口文件和分销商追溯要求，但这些系统依然做不到按批次给剩余鲜度背书。[4][5][11][13][19][20]
• 竞争压力很分散，横跨标准化追溯、海鲜工厂软件和冷链传感器。Wholechain、Trace Register、ThisFish、iFoodDS 和 Tive 各自解决了工作流的一部分，但没有谁把宰杀节点采集、分鱼种鲜度建模和面向买家的证书真正合在一起。[23][24][26][28][30][32]
• 这是一块很窄但站得住的滩头市场：高端零售和寿司渠道本来就在卖追溯与负责任处理的故事，而冷链研究也说明，只要腐败和降级率下降一点点，经济收益就可能非常可观。[21][22][33][34][37][38]

市场定义

这个市场本质上是面向高端鲜海鲜的码头端鲜度认证软件：它从首次陆上接收开始，采集鱼种、处理和温度事件，给高端零售、寿司和出口渠道出具面向买家的证明，而不只是满足内部召回合规。[5][11][19][20][23][24]

用户与买方

实际用户是美国西海岸或阿拉斯加处理来源混杂高价值鱼货的加工商里的 QA 或运营负责人；真正拍板的是 VP Operations 或 Chief Quality Officer，因为批次放行、出口文件、分销商审计和降级造成的毛利流失，最终都落在他们身上。[6][13][20][21][22]

购买触发点

• FSMA 204、进口商管控或分销商追溯升级，逼着加工商把首次陆上接收、批次编码和记录共享流程理顺。 [5][11][19]
• 高端买家、出口商或寿司分销商，要求的处理质量证明比通用流转链条记录更强。 [13][20][21][22]
• 加工商开始采用人道宰杀或 ikejime 做法，想把品质提升变现，而不是只把它当成内部运营改进。 [1][39][41]

支付意愿

公开的软件定价数据很少，但高端零售追溯项目、可追溯水产品能拿到的消费者溢价，以及腐败损耗本身的高成本，都说明只要产品能抢回一小部分降级价值，或帮客户保住一个高端账户，就有预算空间。 [21][33][34][37][38]

品类动态

增长信号 更广义食品追溯市场在 2025–2034 预测区间内的 CAGR 为 13%。

验证信号

• Shinkei 已经在为机器处理的鱼向渔民支付溢价，这本身就在重塑采购关系，也说明市场愿意为了处理质量改写上游经济账。
• Erewhon 已经在陈列可追溯、经过认证的高端海鲜，而不是把来源信息藏在后台。
• Tokai Denpun USA 公开把自己定位成冷冻海鲜批发商和寿司供应商，说明专门化的高端分销渠道确实存在。
• Beaver Street Fisheries 已经在测试 iFoodDS、Wholechain 和 ThisFish 支撑的 FSMA-204 级互操作，说明大型海鲜运营商正在积极把追溯交换数字化。

监管与技术约束

• 任何鲜度证书都必须服从 HACCP 和食品安全控制，不能推翻时间-温度安全边界。
• FSMA 204 要求精确记录关键追踪事件，包括追溯批次编码，以及针对渔船来源食品的首次陆上接收逻辑。
• 高端出口主张往往仍依赖被认可的主管机构和证书格式，所以这家公司更可能是补充 NOAA 文件流程，而不是替代它。
• 模型质量取决于鱼种识别、温度遥测和防篡改事件采集是否可靠。

替代集合不是一家公司通吃，而是高度分散。Wholechain 和 Trace Register 主打合规与互操作，ThisFish 主打工厂现场数字化和 QC，iFoodDS 连接企业级追溯交换，Tive 监控运输条件。正因为这么碎，才给了新层一个机会：它不用替换所有上游记录系统，只要把宰杀节点和温度数据转成一张买家信得过的剩余寿命证书。[23][24][25][26][27][28][30][32]

为什么现有厂商不会默认胜出

• 通用追溯平台. Wholechain 和 Trace Register 在批次可视化、标准和伙伴数据交换上很强，但鲜度认证不是天然就属于他们，因为这件事需要在合规记录之上再叠一层分鱼种的生物学模型。
• 海鲜工厂软件. ThisFish 很贴合工厂现场的追溯和 QC，但它更像内部过程控制系统，而不是一套跨加工商、面向买家的货架期证书。
• 企业级追溯网络. iFoodDS 在 FSMA 204 互操作上很有可信度，但它公开的定位仍是追溯交换和供应商合规，而不是宰杀品质溯源或鲜度预测。
• 冷链传感器厂商. Tive 能告诉买家一票货在运输中有没有超温，但它说不清这条鱼出发时是不是品质就更高，也无法解释不同鱼种的处理方式怎样改写可售窗口。

这家公司应该先做成一层码头端剩余货架期认证层，服务美国西海岸和阿拉斯加那些把整鱼项目卖给寿司分销商、出口商和高端商超的高端海鲜加工商。第一个用户是 QA 或运营负责人：他们得在混合来源的批次之间快速放行，还要拿得出比纸质 HACCP 记录和分级员经验更硬的证据来证明剩余货架期。最直接的触发点，要么是人道宰杀设备刚装上，要么是买家、出口商或追溯升级把“首次陆上接收”和“处理证明”逼成了可审计流程。切口必须故意收窄：一个码头、一到两种高端鱼，再配一张面向买家的证书，把宰杀节点数据、温度遥测和分鱼种置信区间合成分流建议。这个切入点比再做一个通用追溯平台更好，因为 Wholechain、Trace Register、iFoodDS、ThisFish 和 Tive 已经覆盖了合规、工厂数据或传感器可视化，但没有谁真正占住“买家信得过的剩余寿命认证”这个位置。研究给出的滩头市场，到第 3 年的 SOM 也只有约 $1.5M，所以风险投资逻辑必须建立在扩更多站点、更多鱼种，最终切进更广的蛋白品质工作流上。最强的反证风险是：下游买家可能只把加工商出具的证书当成可有可无的 QA 文档，而不会拿它来做采购决策，那产品就会滑进一个更慢的合规软件赛道。现有输入也没有直接证明试点定价、分鱼种精度阈值，或第三方背书是否是硬门槛，所以前 12 个月必须先把买家信任、可量化的毛利回收和快速部署跑通，之后再扩团队。

问题

• 高端海鲜加工商现在放行和分流批次，靠的仍是分级员经验、纸质 HACCP 记录、静态货架期表，以及无法按批量化剩余鲜度的通用追溯系统。
• 来源混杂的鱼货一旦拿不出买家信得过的鲜度证据，运营团队就会保守降级，丢掉高端客户，还得吞下本可避免的浪费、纠纷和出口摩擦。

解决方案

• 做一套码头端认证 OS：给每个批次分配数字 ID，吃进宰杀节点或收货数据和温度遥测，再按鱼种估算剩余可售天数，同时给出置信区间和 QA 护栏。
• 给寿司、出口或高端商超渠道生成面向买家的证书和分流建议，让加工商能说清这个批次为什么配得上高溢价路径，而不是靠口头经验。

为什么我们会赢

• 产品卡在品质被创造出来的那一刻，以及批次放行决策上；而现有追溯、工厂现场和传感器厂商，默认都不提供一套让买家信得过的剩余寿命工作流。
• 只要能跨加工商把宰杀方式、处理模式、温度历史、买家接受度和成交价格连起来，这套数据就会沉淀成鲜度基准护城河——单个工厂和横向软件厂商都很难自己拼出来。

里程碑

flowchart LR
  Wedge[Dockside certification wedge] --> MVP[One-dock MVP]
  MVP --> Proof[Accepted certificates and lower downgrades]
  Proof --> Expansion[Multi-site and multi-species expansion]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少一半合格目标加工商必须确认：鲜度证明或追溯升级的痛点，足以让他们在 6 个月内为付费试点掏钱。
• 首发鱼种模型必须在真实商业环境里把剩余可售窗口预测得足够准，才能减少降级或守住被买家接受的高溢价天数。
• 至少有一类下游买家会把这张证书当作有用的放行证据，而不是要求每个批次都做完整的第三方检验。
• 一套单码头部署必须能靠现有收货、机器或传感器数据，在 2–4 周内上线，而不是变成定制 IT 项目。
• 至少 40% 的付费试点必须转成年部署，并扩到更多鱼种或站点，公司才有机会跑赢最初 $1.5M 的 SOM。

待尽调问题

• 哪些下游买家真的会因为加工商出具的鲜度证据，改变分流、定价或验收决策？
• 首批目标加工商按鱼种和产线看，多少降级或浪费下降才真的有经济意义？
• 滩头工厂里有多少已经具备数字化批次 ID 和温度数据？又有多少需要新增硬件或人工服务？
• 这个产品到底多依赖 Shinkei 式自动化？手工或非 OEM 采集路径能不能撑起来？
• 一旦切口被证明成立，ThisFish、Wholechain、iFoodDS 或 Trace Register 多快能补出一个“够用”的鲜度模块？

模型合理性

• 营收引擎. 基础情景的营收引擎，本质上就是 Y3 Q4 做到 25 个在线付费站点、每站点年综合价值约 $66K；增长主要来自更多码头、更多鱼种和复购买家，而不是大规模销售团队。
• 必须跑对的事. 买家接受度和 30 天内上线必须守住，因为模型默认只靠 1 名 AE 加伙伴转介绍，就能在 Y2 Q4 把切口扩到 12 个在线站点。
• 模型最怕. 一旦销售周期被拉向 12 个月，模型恶化得最快，因为在所有敏感因子里，它对 Y3 营收和现金的合并打击最大。
• 下一轮证明点. 能支撑种子轮的证明点，是做到 12 个在线站点、50%+ 的多鱼种或多站点扩张，以及拿下一家让证书变成采购决策输入的验证伙伴。

情景

敏感性

flowchart LR
  Leads[Buyer and partner leads] --> Pilots[Paid dock pilots]
  Pilots --> Sites[Live sites]
  Sites --> Revenue[Recurring site revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Ending cash after team burn]

警示项: 到 Y3 公司仍未实现 EBITDA 转正，因为研究得到的滩头市场只有 25 个在线站点，而产品仍需要 QA 与集成劳动去换取买家信任。 · 营收集中度依然很高，因为一个区域走廊里 25 个在线站点，意味着第 3 年的大部分收入仍由少数锚点加工商驱动。 · 基础情景依赖 Q4Y2 到 Q4Y3 期间团队人数固定在 8 名 FTE；如果部署支持或渠道管理需要更多人，模型就会往下行情景漂。 · 综合 $66K 的 ARPU 只是假设在 $60K 的 SOM 基线之上再叠一点扩张；如果买家只买最低站点套餐，营收会明显下滑，而固定成本几乎不动。

• 数据信任缺口. 如果输入数据无法防篡改、也缺独立审计，买家未必会信加工商自己出具的剩余货架期证书。 缓解措施: 直接接入码头设备和传感器硬件，保留不可篡改的事件日志，并在早期验证里拉上第三方审计方或分销伙伴。
• 收货流程摩擦. 收货码头节奏很快，只要多一步扫描或打标，装箱和出货就可能被拖慢，团队自然会抵触。 缓解措施: 嵌进现有收货和 HACCP 流程，先从一条高端产线切入，能从设备自动抓取的数据尽量不让人手填。
• 现有追溯厂商捆绑. 现有海鲜 ERP、追溯或传感器厂商，可能补一层基础鲜度看板，把差异压薄。 缓解措施: 守住更难的那一层——分鱼种鲜度建模、批次分流建议和成交价基准，而不是泛泛的流转链条报表。