兜底靠的不是人数，是结构
Mindix 用“能力内核 + 协作网络 + 组织化兜底”三件事支撑交付：能力内核掌握架构定义与质量裁决，实施资源通过稳定的协作网络组织， 兜底依靠架构控制权、验收标准和合同责任，而不是依赖某个人出现在每个现场。这一页也写明我们的风险与不承接的范围。
一、能力内核
能力内核不是一个“明星顾问”，而是一组不可外包的判断职能：架构怎么定、质量谁裁决、关键决策谁拍板。
创始人与核心架构团队直接参与项目，不把架构定义交给销售、售前或临时招募的项目经理。所有项目的系统架构、数据模型、集成接口，必须经过能力内核评审。
能力内核的职责不是“多干活”，而是守住三件事：架构一致性、验收标准的解释权、关键变更的决策权。这三件事一旦外包，总包就退化为资源转包。
- A
架构定义
应用、数据、集成三层结构由能力内核定义，不允许分包方按自身产品能力修改。
- B
质量裁决
验收标准由 Mindix 解释并执行，分包方不能自证合格。
- C
关键决策
范围变更、技术路线、上线时机等关键决策，由能力内核拍板并留痕。
二、协作网络
实施资源不靠临时招聘凑齐，而靠长期协作网络组织。稳定性的判断标准不是“认识”，是“一起交付过”。
配合历史可验证
核心协作成员与 Mindix 有多个项目的实际配合记录，不是第一次合作就被推上前台。
角色分工固定
架构、开发、数据、业务顾问角色清晰，谁对什么交付物负责在项目启动时确定。
不临时凑数
项目范围超出协作网络当前能力时，我们选择缩小范围或不做，不用陌生资源填坑。
三、组织化兜底三件套
兜底不是一句承诺，是三个可以被检查的机制。缺任何一件，“兜底”都会退化成口头保证。
架构控制权
系统架构、数据模型、集成接口的定义权在 Mindix。分包方可以提建议，但不能改架构。控制权是兜底的前提——改不了架构，就担不了结果。
验收标准
每个里程碑都有可检验的验收标准，由 Mindix 解释与裁决。标准在项目启动时写定，不在验收时临时解释。
合同责任
客户与 Mindix 签约，分包是内部机制。交付未达约定目标时，由 Mindix 承担补救责任，客户不需要向分包方追责。
三件套必须同时成立。有控制权没有验收标准，质量无法裁决；有验收标准没有合同责任，标准只是建议；有合同责任没有控制权，承诺无法兑现。
四、内部验收机制
客户验收之前，先过一遍 Mindix 自己的验收。内部不通过，不提交客户验收。
设计评审
架构、数据模型、集成方案由能力内核评审，确认与业务目标和既有系统一致，才进入实施。
阶段自检
每个里程碑交付前，项目组按验收标准逐条自检，形成可追溯的检查记录。
独立验收
由不参与实施的内部角色复核关键交付物，避免“自己做的自己判”。
质保复盘
质保期内跟踪实际使用情况，把偏差回流到方法论与模型，而不是项目结束即失联。
五、风险与边界
这一页的可信度来自“敢写风险”。以下是我们在合作前会主动说明的限制。
轻资产模式在超大范围项目上的边界
涉及多法人、多地域、数百人同时进场的超大型项目，需要以人力规模和组织厚度取胜，这不是我们的结构优势。这类项目我们会建议拆分范围，或与具备相应规模的伙伴联合交付，并明确责任划分。
reach-back 能力的边界
协作网络能提供的专家支持有响应半径。远离核心协作区域、要求长期驻场且高频决策的项目，交付质量会受影响，我们会在评估阶段直接说明。
对客户配合的依赖
总包不等于客户可以缺席。业务负责人不参与、数据接口人不确定、关键决策长期不拍板，都会导致里程碑延期。这类延期不计入 Mindix 的交付责任，但我们会提前预警并记录。
我们不承接的项目
只买软件、且期望软件本身带来转型结果的项目；要求先给固定总价、不接受诊断的项目；由 IT 单独发起、业务不参与的项目；期望三个月完成全集团转型的项目。