经验证的受限用途 Kosher（犹太教合规）手机项目部署

简报：将社群规则与设备配置假设分开

Kosher 手机项目由社群或审核机构允许的功能定义，而不是由某个笼统的手机类别定义。同一个说法，在一个社群可能指仅通话手机，在另一个社群可能指可通话和短信的设备，在第三个社群则可能指仅含获准应用的智能手机——因此，如果项目从设备名称而不是规则集出发，通常要到审核阶段才会发现不匹配，而此时修正成本最高。Vantora 会从一份脱敏简报开始每个项目，将社群规则集与设备配置假设分开：哪些功能允许使用、哪些附带条件、哪些必须从设备中彻底移除而不能只是由启动器隐藏；恢复出厂设置后设备应有何表现；需要哪些语言和键盘；适用哪些 SIM 与运营商假设；包装和支持路径如何安排；以及由谁签署样机验收。可行性阶段的简报可以继续脱敏——项目方和分销商无需披露成员名单、商务条款或审核机构身份，也能获得切合实际的配置评估。本阶段的产出是一份由各方在承诺采购任何硬件前共同审阅的功能矩阵草案。

• 适用哪种项目模式：仅通话、通话和短信，还是仅含获准应用的智能手机
• 哪些功能必须从设备中彻底移除，而不能只是由启动器隐藏
• 恢复出厂设置、更换 SIM 和更新 OS 后的预期行为
• 目标社群的语言、键盘和 RTL 要求
• 由谁审核样机，以及由谁为项目签署验收

通过责任矩阵与审核机构协作

Vantora 不决定某项配置是否为社群所接受，任何设备供应商也不应如此宣称。工作模式是在项目启动时商定一份责任矩阵：审核机构保留对可接受范围的决定权，并可检查其选择的任何行为；项目方负责规则集、社群关系与送审；Vantora 负责经验证的配置版本、技术证据和批次一致性。实际流程按一个方向推进：接收规则并将其转化为功能矩阵草案；项目方确认矩阵；制作样机并据此验证；技术验证记录随样机经项目方提交给审核机构；反馈以书面矩阵变更的形式返回，如此循环，直到样机获准。让这一流程以文件为依据并非官僚作风——对于设备究竟阻止哪些行为，仅靠口头理解，是受限用途项目审核失败和后期返工最常见的原因。

• 审核机构：检查样机，并决定其是否为所服务的社群接受
• 项目方：负责规则集、送审以及与成员沟通
• Vantora：负责经验证的配置版本、验收证据和批次预配记录
• 每项规则变更都要先写入功能矩阵，再进入配置版本

配置：按照获准的功能矩阵准备手机

配置层可以包括固定启动器行为、获准应用白名单、无浏览器选项、阻止侧载、希伯来语／意第绪语／英语语言设置、默认权限、包装、SIM／APN 假设和管理注册。每项控制由何种机制实现，需要按机型决定：部分限制可通过 Android Enterprise 和管理策略实施，部分需要 OEM 配置支持，而最深层的重置与恢复行为可能需要交付周期更长的固件路径。Vantora 会在配置规范中明确记录这种映射，因为策略控制台中显示的一项控制，不一定在每种机型上或每次更新后都有相同行为。下面每种项目模式的验证重点不同；在同一设备群中混用不同模式却不分别验证，是常见的失败原因。

验证：让审核有据可依的验收矩阵项目

验证会把功能矩阵转化为验收矩阵：每项允许、受限或附带条件的内容，都会成为一个可测试的条目，并在实际样机上记录预期结果和实测结果。Vantora 会检查重置行为、恢复模式、侧载、商店访问、强制门户、WebView 界面、浏览器入口、设置限制、应用更新路径、语言显示和 SIM 行为，并记录每项限制由何处执行——启动器、管理策略、OEM 配置还是固件——让审核人员了解其持久程度。产出是该设备配置版本的技术验证记录；宗教或社群层面的接受与否，完全由项目方及其审核机构决定。已知限制会如实记录，而不是淡化处理：若审核机构在验收后自行发现某项限制，给项目带来的风险远大于在审核材料中事先披露。

• 拨号器和联系人可打开；浏览器软件包不存在或被阻止；商店入口会返回启动器
• 从设置或恢复模式执行恢复出厂设置后，设备都会回到受限状态
• 强制门户登录无法扩展为开放式网页浏览
• 获准应用的更新只能通过受控路径安装
• 希伯来语和意第绪语的显示、键盘及 RTL 布局按规范工作
• 更换 SIM 和编辑 APN 不会暴露未经批准的数据路径

规划：从脱敏简报到首批社群设备的典型阶段

项目方通常需要先了解日程，才能安排审核或社群公告。以下区间适用于规则集已经明确的单机型项目；如果规则集仍在协商、需要固件路径，或审核机构在首轮审核后要求变更，周期会相应延长。这些是规划数字，并非承诺——具体项目的阶段计划会在简报答复中确认，并受机型、OEM 路径和数量影响。

预配：为项目渠道准备批次

批次预配可以包括自有品牌包装、所需语言的随附资料、SIM 或 APN 假设、资产标签、序列号或 IMEI 记录、应用预装、默认语言，以及在封箱前加载并验证获准的功能状态。对社群项目而言，渠道与设备同等重要：批次可能交付给分销商、社群办公室，或直接交给项目服务台；每条路径都需要自己的移交说明和支持边界，确保成员提出问题时被转接给项目方，而不是某个不具名的工厂。以已验收样机为基准进行预配，才能让项目可重复执行——如果改为交付后逐台手动配置，受限用途项目最容易在此偏离审核机构曾审阅的版本。

部署：让每个批次都与已验收配置版本保持关联

Kosher 手机项目对无声变更尤其敏感：OS 更新、替代机型修订版、应用更新路径变更或不同的重置行为，都可能在无人有意为之的情况下改变获准使用范围。Vantora 会记录已验收样机版本、功能矩阵、配置路径、应用版本、包装状态、已知限制和批次预配检查表，并在发货前按该基准核对后续订单。如果变更不可避免——例如零部件替代，或某个 OS 版本无法维持——则会以书面形式向项目方提供相对于验收矩阵的差异，让审核机构只重新审核变化部分，而无需重复整个流程。因此，批次一致性是一项证据实践，而不是口头承诺：每次复购都可以与已获准的配置版本逐项对照。