#NSIO Next · 商业模型与 Entitlement

状态：商业基线。本文定义商品边界、Entitlement 数据模型和首版强制范围。价格与配额数字放在本文，架构文档只保留能力轴与执行原则。

#0. 本文要解决的问题

首版不建设完整计费平台，但商品边界必须一次设计对：

• 产品能力完整——L3、L4 Service、Grant 和服务发布不做付费阉割；
• 商品结构可扩展——以后增加 Business、Exit Pack、Ephemeral Pack 不改运行时协议；
• 首版计费简单——只对少数几项做可靠强制，其余先计量观察。

判断标准只有一条：调整市场套餐时，NSD、NSGW 和 NS App 的协议与代码不需要跟着改。

本文件定义“卖什么”和运行时怎样获得能力。客户怎样报价、付款、开票、催缴与退款以采购、计费与发票为权威；SLA 的测量、抵扣和事故通报以服务运营规格为权威；认证、数据权利和 Legal Hold 以信任与合规为权威。

#1. 三层分离

商业信息不进入运行时。三层各自独立演进：

Subscription            商业订单：plan、SKU、数量、价格、折扣、发票、合同
   ↓ 解析（Entitlement Resolver）
Effective Entitlement   运行时能力：features / quotas / limits / service_levels
   ↓ 签发
Capability Lease        NSD 给 NSGW 的短期、具体、可撤销能力授权

**NSD 不认识 resource_pack_10，NSGW 不认识套餐名和订单。**改套餐名、加组合包、调折扣，都只动 Subscription 层。

#1.1 溯源字段

三层分离的代价是排查"这个组织为什么有 35 个受管资源"需要跨系统查询。Effective Entitlement 携带一个非权威的溯源引用来消除这个代价：

"derived_from": { "subscription_id": "sub_01J...", "revision": 14 }

运行时组件不得对它做任何判断，它只用于支持工单和审计关联。

#2. Effective Entitlement 数据模型

#2.1 四个桶

新增键落哪个桶，按上表两列判定，不靠直觉。典型误判：审计保留期看起来像配额，但它不阻断任何操作、也不按量计费，属于 service_levels。

#2.2 结构

{
  "schema_version": 1,
  "entitlement_id": "ent_01J...",
  "entitlement_revision": 42,
  "subject": { "type": "organization", "org_id": "org_01J..." },
  "deployment_id": "dep_01J...",

  "features": ["l3_mesh", "l4_services", "sso", "scim"],

  "quotas": {
    "human_seats":        { "limit": 10,   "enforcement": "block" },
    "networks":           { "limit": 5,    "enforcement": "block" },
    "managed_resources":  { "limit": 35,   "enforcement": "block" },
    "edge_regions":       { "limit": 0,    "enforcement": "block" },
    "ephemeral_minutes":  { "limit": 5000, "enforcement": "meter" },
    "edge_traffic_bytes": { "limit": null, "enforcement": "meter" }
  },

  "limits": {
    "user_devices_per_seat": 20,
    "services_per_network": 500
  },

  "service_levels": {
    "audit_retention_days": 30,
    "community_relay_mbps": 10
  },

  "derived_from": { "subscription_id": "sub_01J...", "revision": 14 },

  "issued_at": "2026-08-08T00:00:00Z",
  "expires_at": "2026-09-08T00:00:00Z",
  "grace_until": "2026-09-15T00:00:00Z",
  "key_id": "ent-2026-08",
  "signature": "..."
}

quotas 中的数字是已解析的有效总量（Team 25 + Resource Pack 10 = 35）。NSD 只读总量，不做加法，不知道加法的来源。

entitlement_revision 是 (subject, deployment_id) 作用域内由签发方分配的单调递增版本，是防回滚的权威字段。derived_from.revision 仍然只是订单溯源信息，不得用于版本判断。

#2.3 Enforcement 三态

首版即完整实现三态，然后通过签发不同的 Effective Entitlement 来切换。临时节点从观察切到告警再切到强制，是换一份声明，不是发一个版本；也可以先在单个组织上试 warn。

#3. 缺失与未知的处理

这一节决定"签发疏漏会不会锁死客户"，是整个模型最容易出事的地方。

#3.1 缺失 quota

每个 schema_version 必须声明其 required quota 集合。启用某个 feature 时还必须校验它依赖的 quota 存在——例如 managed_edge 必须同时存在 edge_regions，否则 bundle 无效。

不采用"缺失一律取 0"：那样一次签发疏漏就能锁死整个组织，风险不对称。

#3.2 未知字段

未知 enforcement 不降级为 block，因为那会让尚未实现该语义的 Next NSD 突然锁住客户——这与"读不懂 ≠ 拒绝服务"的全局原则冲突。正确路径是拒绝该 bundle、退回最后有效版本、进入 grace 并明确报 unsupported_entitlement_enforcement。

required quota 集合只由 schema major 定义，签发方不能在 bundle 内把新键标成 required。需要新的强制语义时必须提升 schema major；同 major 新增字段只能是 optional。

#3.3 最后有效声明必须可持久化

"使用最后有效版本"只有在它能跨进程重启存活时才成立。要求：

• 最后一次验签通过的 Effective Entitlement 连同其签名一起持久化；
• 同时持久化每个 (subject, deployment_id) 已接受的最高 entitlement_revision 和声明摘要；
• NSD 重启后从持久化副本恢复，而不是回到"无声明"状态；
• 恢复的副本仍受 grace_until 约束，且在管理端显示为"陈旧，最后验证于 T"；
• 若持久化副本本身验签失败（被篡改），按无声明处理并告警，但仍不得拒绝启动。

否则在签发服务故障期间重启一次 NSD，就会掉进本节想避免的那个坑。

#3.4 防回滚与恢复

Entitlement 沿用控制面配置已有的版本回滚拒绝纪律：

• 新声明的 entitlement_revision 低于本地最高已接受版本时，即使签名和有效期都合法也必须拒绝，并报 entitlement_revision_rollback；
• revision 相同但签名覆盖的规范化载荷摘要不同，视为签发冲突或重放攻击，拒绝并报 entitlement_revision_conflict；摘要不得基于会受 JSON 字段顺序或空白影响的原始传输字节；
• 验签成功但因回滚被拒绝的声明不能覆盖最后有效声明、最高版本或 grace 计时依据；
• Capability Lease 必须绑定 entitlement_id 与 entitlement_revision，避免旧 Entitlement 派生的新租约继续扩散；
• 备份恢复、灾难恢复或签发系统重建需要降低 revision 时，必须使用由签发权威签名的独立 recovery/reset 声明，指定组织、部署、目标 revision、原因、批准人和一次性 nonce，并写入审计；不能通过删除本地高水位绕过。

本地高水位能防止单独替换 entitlement 文件，不能独自证明整个 NSD 数据库没有一起回滚。托管云必须把最新接受 revision 的检查点写入独立的 Entitlement Service/审计存储，NSD 恢复后在签发新 Capability Lease 前完成比对。完全离线的企业自建若没有 TPM、外部时间戳或远端签名回执，就无法从密码学上检测整库快照回滚；产品必须把它列为部署边界，不能宣称绝对防回滚。

#3.5 每个组织都有 Effective Entitlement

社区自建不需要联网验签，这既是产品承诺也是可用性要求。

#4. 首发商品

首版不做 Business 档——Team 与 Enterprise 之间的细分等真实客户分布出来再切，切的时候只改 Subscription 层。

#4.1 配额

* 受 limits.user_devices_per_seat 反滥用上限约束，超出触发提示而非账单。

Personal 的 managed_resources: 10 是转化线所在：足够任何家庭实验室，明显不够一家公司。对照 Tailscale 免费层的 50 个 tagged resource——但在 Tailscale 上发布 Service 需要 tag 身份、会消耗该额度，而 NSIO 的用户设备可以免费发布任意数量 Service。个人用户在真正重要的地方拿到的更多。

#4.2 计费单位

Human Seat Slot 的释放条件必须确定：User 从 Organization 删除、停用或由 IdP/SCIM deprovision 时释放；仅删除最后一台设备、退出登录或短期离线不释放。因此账单表示组织当前需要的可复用席位容量，不是本周期曾出现过的不同用户总数。

Quota 准入看事务提交时的当前占用数；订阅按购买的槽位容量计费，启用自动扩容时以事件精确计算本周期最高同时占用槽位数。已释放槽位可由另一个 User 或 Membership 在同一周期复用，不能把周期内出现过的不同身份简单累加，也不能用小时采样近似峰值。

Managed Resource Slot 的分类变化必须走同一个资源分类变化事务。下列动作都可能占用或释放槽位，任何 API、同步器或后台任务都不得绕开：

• 创建 owner_type ∈ {service, tagged, organization, workload} 的 Membership；
• 修改现有 Membership 的 owner type；
• 审批、撤销 subnet_router / app_connector / exit_provider / relay_candidate 等基础设施能力；
• 临时 Membership 超过策略阈值转为长期资源；
• 删除 Membership、撤销长期身份或将其重新分类为不计费用户设备。

事务必须在同一数据库提交中完成：锁定当前分类与槽位占用 → 计算变化后总量 → 执行 quota enforcement → 写入权威资源状态 → 写入 outbox 计量事件。审批事件只是其中一种触发，不是唯一入口。用户设备免费仅限未被分类为受管资源的 endpoint + service_host。

CapabilityPolicy 只决定节点是否有资格申请能力，不能直接改变 Managed Resource Slot。每个具体能力必须经过统一 CapabilityActivation 事务；策略自动批准也只是该事务的 auto 分支，仍执行 quota allocation、metering、audit 和短租约签发。

CapabilityActivation 的商业语义与健康状态分离：

暂停必须记录结构化 reason（operator_paused、maintenance、commercial_grace、security_hold）并在管理端明确显示“仍占用额度”。系统不按固定 N 天自动撤销；管理员或策略可在暂停时显式设置 auto_revoke_at，执行前通知、计算影响并审计。策略失去资格不能伪装成 suspended，应走影响预览后的 revoke/管理员确认流程。

#4.3 永不计费

• P2P 直连流量
• 用户个人设备数量
• ACL / Grant 规则数量
• DNS 查询次数
• Service 数量、调用次数、并发连接数
• Node ↔ Service 端到端流量
• 安全撤销、数据导出、资源删除

可设反滥用上限，但上限触发限速和提示，不触发账单。

#5. 首版强制范围

#5.1 强制点

每项限制只在一个地方强制：

UI 永远不是强制点。NSGW 不相信客户端自报的任何商业状态，只接受 NSD 基于有效 Entitlement 签发的短期 lease。

#5.2 只计量项的管理端展示

本月临时节点：8,420 分钟
本月托管边缘流量：186 GB

超内部阈值先提示、联系客户或人工调整。**不自动扣款，不突然断网。**真实数据足够后再决定是否推出分钟包和流量包——届时只需签发 enforcement: warn 或 block 的新声明。

#6. 商业状态与数据生命周期

#6.1 三类事件不可压成一个布尔

三条不可动摇：

• **社区自建 Community L3/L4 不受平台商业状态影响。**托管云则在 grace 后收敛到当前有效免费 entitlement 和配额，不承诺无限期提供未付费托管控制面。
• 托管云降级前必须给出影响预览和资源选择；已有收费 Capability Lease 自然到期，不把欠费伪装成安全撤销，也不立即拆除基础连接。
• **超配额冻结由客户选择，系统不自动挑。**系统自动挑一定会挑掉生产节点。

#6.2 审计保留期降档

保留期不是"永不删除"——否则购买一个月 Team 就永久获得 30 天历史，不可执行。正确闭环：

1. 降档前显示将受影响的日期范围；
2. 提供明确导出窗口（建议 30 天）；
3. 导出窗口内保留原有数据；
4. 窗口结束后按新的保留期清理；
5. Legal Hold、调查冻结或法规要求优先于套餐策略；
6. 不因降档立即静默删除。

配套两条机制要求：

• 清理动作本身写审计记录（谁降的档、清理了哪个日期范围、何时执行），且该记录的保留期独立于被清理数据，否则会出现"审计日志少了五个月且无人知道原因"；
• Legal Hold 是一个可置位标志，由 Security Admin 设置，阻断保留期驱动的删除，其置位与解除本身也进审计。

#7. 私有部署禁止 Kill Switch

Entitlement 异常在私有部署中的行为是硬性禁令：

• 不得拒绝私有 NSD 启动；
• 不得切断已建立的数据面；
• 使用最后有效声明并持续告警；
• grace 之后只阻止新增收费托管能力；
• Community L3/L4、自建 Relay 和已有 Grant 不受商业授权影响。

理由不是道德而是运营：网络产品里的 license kill switch，第一次误触发就是客户整组织断网加事故报告；而且对客户掌控的二进制根本不可执行。私有部署收入来自合法授权、升级、支持、合规包和 SLA，不来自远程断网能力。

#8. 客户端边界

**NS App 不读取套餐名。**它只读取两件事：

1. 某项功能当前是否可用；
2. 某次操作的返回结果。

不允许出现 if (plan == "team")。App 的发版周期最长，套餐逻辑一旦写进去，改套餐就要等全部用户升级客户端。

Billing 与管理后台可以显示套餐名和订单——它们属于 Subscription 层。

#9. 全新商业边界

NSIO Next 不承接旧 NSIO 的订阅、资源用量、价格、账单、License 或 Entitlement：

1. 新 Organization 在 Next 中选择 Personal、试用或付费商品后，签发第一份原生 Effective Entitlement；
2. 不根据旧 NSC/NSN 数量自动创建 Human Seat、Managed Resource 或历史用量；
3. 不提供 Legacy entitlement、旧价格保护或跨产品自动续费；如商务上需要优惠，应创建 Next 自己的折扣、合同和到期规则；
4. Next 的账单只引用 Next 原生资源 ID、槽位事件、Capability Lease 和边缘计量证据；
5. 旧 NSIO 与 Next 是两条独立产品线，客户可以分别订阅和运行，但不能把一边的商业声明作为另一边的运行授权。

#10. 实施顺序

首版交付的不是计费平台，而是一个边界正确的 Entitlement Resolver。

#10.1 计量流水要求

usage_outbox(event_id, aggregate_type, aggregate_id, aggregate_revision, event_type, payload, committed_at, published_at)
seat_slot_events(event_id, ledger_sequence, org_id, user_id, action, reason, occurred_at)
resource_slot_events(event_id, ledger_sequence, org_id, membership_id, from_class, to_class, occurred_at)
ephemeral_lease_intervals(org_id, membership_id, lease_id, valid_from, valid_until)
edge_counter_checkpoints(org_id, edge_unit_id, direction, counter, observed_at)
entitlement_snapshots(org_id, deployment_id, entitlement_id, entitlement_revision, digest, verified_at, stale)
usage_reconciliation_findings(finding_id, org_id, kind, expected_set, observed_set, detected_at, status)

• 事务 outbox：席位或资源权威状态变化与对应 outbox 事件必须在同一数据库事务提交，不能先改状态后“尽力发事件”；
• 幂等可重放：每条事件带稳定唯一键，消费者重复处理不得重复占用、释放或计费；
• 确定性顺序：账本使用按 Organization 单调递增的 ledger_sequence 处理同一时刻的释放与占用，不能依赖不同主机的墙上时钟决定周期峰值；
• 周期对账：按事件推导出的活跃槽位集合必须与权威 User/Membership 状态定期比对。差异写入 usage_reconciliation_findings 并告警，不能静默改写已出账单；
• 释放口径固定：席位只在删除、停用或 deprovision 时释放；受管资源只在分类事务确认不再受管或资源删除时释放；
• 临时节点按租约计时：以签发的有效租约区间为证据，不能依赖可能缺失的进程启动/删除时间戳；
• 保留期：原始流水 90 天，汇总 3 年；
• 账单可解释：任一周期的槽位数量必须能列出对应 User/Membership 和 occupy/release 证据；Edge 流量取单调计数器差值并处理重置。

#10.2 契约测试纪律

Entitlement 跨 NSD、NSGW、管理后台三方，是典型的 schema 漂移高风险面。要求：

• schema 与 fixture 提交到 ns-shared-next，三方共用同一份定义，不各写一份再对齐；
• 契约测试必须把真实序列化的结构对 schema 校验，不能只校验 fixture 之间自洽；
• 每个套餐一份 fixture，外加"Subscription → Effective Entitlement"的 golden test；
• 覆盖必需 quota 缺失、未知 enforcement、schema 版本过高、签名失效、持久化副本恢复、合法签名旧 revision 重放、同 revision 不同摘要七种异常路径；
• 覆盖席位释放、受管资源每一种分类变化、outbox 重放、遗漏事件后的对账发现，以及临时租约跨边界计时。

#11. 核心原则

1. L3、L4、ACL、Service 发布是产品基础能力，不做付费阉割；
2. 收费重点是团队协作、受管资源、托管边缘、企业治理和 SLA；
3. Entitlement 与 Grant 分开：购买能力不等于获得访问权限；
4. 商品组合由服务端配置，套餐逻辑不进入 NS App 与网络协议；
5. 商业状态异常不得压成"没有权限"，也不得切断已建立的安全连接；
6. 首版计费简单，但数据模型足以支撑后续增加 Business、Exit Pack、Ephemeral Pack 等商品而不改运行时协议。