MAcode/0-req-IPTV.md

TCS-IPTV 内容可信锁定系统 — 需求规格说明书

版本：V1.0 编制日期：2026年6月 基于文档：《MA+哈希码 IPTV内容可信锁定系统（TCS-IPTV）完整方案》 文档编号：0-req-IPTV

---

引言

本需求文档定义 TCS-IPTV（Trusted Content System for IPTV）内容可信锁定系统的功能性与非功能性需求。系统通过"MA码（监管身份）+ 哈希码（技术指纹）"双锚定机制，在 CP（内容供应商）、IPTV 集成播控平台、运营商（分发网络）三方现有系统之上建立一层"可信身份映射层"，实现 IPTV 内容"审过即锁定，锁定即通行，通行可追溯"。

本系统的核心约束是：不替代三方现有系统，仅在关键节点（送审、入库、分发、播放）以最小侵入方式嵌入校验能力，并通过映射层统一对接。

---

术语表

术语	全称	说明
TCS-IPTV	Trusted Content System for IPTV	IPTV 内容可信锁定系统
CP	Content Provider	内容供应商
播控平台	—	IPTV 集成播控平台
运营商	—	IPTV 分发网络运营方（如中国电信、中国移动）
MA码	—	监管身份主键，由广电总局/省局签发（如网络剧片发行许可证号/备案号）
CTID	Content Twin ID	内容孪生标识，由 MA码+哈希+版本+Merkle根 构成的唯一标识
文件哈希	File Hash	SHA-256 算法，比特级敏感，精确锁定某版本文件
感知哈希	Perceptual Hash	aHash/dHash/pHash，容忍转码压缩，跨格式识别同一内容
Merkle Tree	—	分段聚合哈希树，用于多集/长内容的分段定位
可信数据空间	—	基于联盟链/分布式账本的可信身份映射层
EPG	Electronic Program Guide	电子节目指南
CSPS	Content Safety/Review Platform System	审核和监管部门已有的内容审核系统
媒体资源库	Media Asset Library	审核和监管部门已有的媒资库，审核合格内容入库存储，并作为向运营商发布的统一出口
转码版哈希	—	内容经授权转码中心转码后重新计算的版本哈希
重审	Reaudit	内容版本变更后触发的重新审核流程

---

角色定义

系统围绕三个核心角色设计：内容提供商、审核和监管部门、运营商。

角色	描述	核心职责
内容提供商（CP）	内容供应商	生产内容、计算哈希、送审申报、注册本方映射、自查验真
审核和监管部门	广电总局/省级广电局 + IPTV 集成播控平台（承担内容审核与监管把关职能），已有 CSPS 审核系统与媒体资源库	内容合规审核（CSPS）、送审验真、转码授权、签发 MA码、注册哈希、合格内容入媒体资源库、从媒体资源库向运营商发布、全生命周期监管、应急下架指令下发
运营商	IPTV 分发网络方	CDN注入校验、EPG发布、终端播放、数据上报、注册本方映射、执行下架指令

说明：审核和监管部门内部含两类职能主体——监管主体（广电总局/省局，行使 MA码签发与应急下架等行政权力）与审核主体（IPTV 集成播控平台，行使内容合规审核、送审验真、转码授权等把关职责）。两者共同构成"审核+监管"的把关闭环。系统运维（可信数据空间、智能合约、API网关、监控告警的维护）作为支撑职能，不单列为业务角色。

---

需求列表

需求 1：母版哈希生成（CP端）

User Story: 作为 CP，我希望在内容制作完成后能够在本地对母版文件计算多维哈希值，以便在不上传原始文件的前提下为内容生成可验证的技术指纹。

验收标准

1. WHEN CP 在母版文件（ProRes/DPX 等格式）上发起哈希计算，THE 哈希计算SDK SHALL 计算该文件的全文件 SHA-256 哈希值。
2. WHEN 内容为多集/长内容，THE 哈希计算SDK SHALL 按场景或集数分段计算分段哈希，并生成 Merkle Tree 及其根哈希。
3. WHEN CP 发起哈希计算，THE 哈希计算SDK SHALL 计算该内容的感知哈希（aHash/dHash/pHash 之一或组合）。
4. THE 哈希计算SDK SHALL 在本地存证哈希值，且 SHALL NOT 上传原始内容文件。
5. WHEN 哈希计算完成，THE 哈希计算SDK SHALL 返回包含文件哈希、Merkle根、分段哈希列表、感知哈希的哈希值包。
6. IF 母版文件读取失败或格式不受支持，THEN THE 哈希计算SDK SHALL 返回错误信息并标识失败原因。

---

需求 2：送审申报与哈希上链（CP端）

User Story: 作为 CP，我希望登录备案系统提交节目信息与哈希值包，以便启动监管审核流程并将哈希存证。

验收标准

1. WHEN CP 提交送审申报，THE 系统 SHALL 接收节目信息（标题、集数、时长、分辨率）、片花、海报、剧本及哈希值包。
2. WHEN 哈希值包提交成功，THE 系统 SHALL 将哈希存证至可信数据空间并返回唯一送审流水号。
3. WHEN CP 提交的内容哈希在可信数据空间中已存在，THE 系统 SHALL 拒绝重复申报，并将该申报关联至已存在哈希对应的原 MA码。
4. THE 系统 SHALL 仅接收哈希值包，且 SHALL NOT 要求 CP 上传原始内容文件。
5. IF 哈希值包格式不完整（缺少文件哈希或 Merkle根），THEN THE 系统 SHALL 拒绝申报并提示缺失字段。

---

需求 3：MA码生成、签发与强绑定（监管端）

User Story: 作为监管方，我希望与 MA 发码机构合作获取码段与备案规则后，由系统自行生成结构化、全局唯一的 MA码，并在审核通过后与送审哈希包强绑定，以便建立内容的合法监管身份。

发码模式：模式B（自行发码） — TCS 与 MA 发码机构对接，获取分配的码段（号段）与备案规则，在本地按规则原子生成 MA码（不依赖外部逐条签发）。

验收标准

1. THE 系统 SHALL 支持登记 MA 发码机构分配的码段（行业节点、机构节点、序列号段范围、序列宽度）与适用内容类目。
2. WHEN 监管方对送审内容审核通过，THE MA码生成引擎 SHALL 按内容类目从对应码段中原子分配序列，并按备案规则生成结构化六段式 MA码（MA.156.{行业节点}.{机构节点}/{类目}/{年份}{序列}）。
3. THE 系统 SHALL 保证生成的 MA码全局唯一；IF 码段耗尽，THEN THE 系统 SHALL 返回错误并告警。
4. WHEN 并发签发，THE 系统 SHALL 保证序列分配原子、不重号。
5. WHEN MA码生成，THE 系统 SHALL 将 MA码与送审哈希包以 1:1 关系写入可信数据空间，且该绑定 SHALL NOT 可被解绑。
6. THE 系统 SHALL 仅允许监管节点调用 MA码签发功能（issueMA）；IF 非监管节点调用，THEN THE 系统 SHALL 拒绝并返回权限错误。
7. WHEN MA码签发完成，THE 系统 SHALL 向 CP 发放"MA码+哈希证书"。
8. WHILE 内容未取得 MA码及哈希证书，THE 系统 SHALL NOT 允许该内容进入后续审核/分发流程。
9. WHEN MA码绑定写入，THE 系统 SHALL 记录签发方、签发日期、MA类型（类目）、内容标题、集数等内容主表信息。
10. THE 系统 SHALL 提供 MA码格式校验与解析能力（解析出行业节点/机构节点/类目/年份/序列）。

粒度设计（一剧一码 + 集级哈希）：MA码作为监管身份按"剧/备案"颁发（对齐网络剧片发行许可证制度），一部多集剧使用单一 MA码；各集（episode）拥有独立哈希绑定，挂在同一 MA码下；各切片（segment）为 Merkle 叶子哈希。集级可通过集级子标识 {MA码}#E{NN}（如 MA.156.8531.6101/WD/20260000001#E07）独立寻址、验真、追更与按集处置。

11. WHEN 内容为分集剧，THE 系统 SHALL 支持按集提交各集哈希（file_sha256/merkle_root/感知哈希），并将每集哈希作为独立绑定挂在同一 MA码下。
12. THE 系统 SHALL 支持按 MA码+集号（或集级子标识 {MA码}#E{NN}）独立验真单集哈希。
13. THE 系统 SHALL 支持查询某 MA码下的全部集级哈希绑定。

---

需求 4：送审文件验真（审核和监管部门）

User Story: 作为审核和监管部门，我希望对 CP 送审的文件计算哈希并与可信数据空间比对，以便确认其为正版过审内容、拦截版本替换。

验收标准

1. WHEN CP 向审核和监管部门送审（提交 MA码、送审文件、授权链文件），THE 验真模块 SHALL 计算送审文件哈希。
2. WHEN 送审文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 确认为正版过审内容并允许进入 CSPS 内容审核流程。
3. IF 送审文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 直接退回该送审，并标记为"疑似版本替换"。
4. WHEN 验真执行，THE 系统 SHALL 通过哈希验真接口查询可信数据空间，返回 valid、bound_hash、submitted_hash、match、version 等字段。

---

需求 5：内容审核与转码哈希绑定（CSPS 审核）

User Story: 作为审核和监管部门，我希望通过已有的 CSPS 审核系统对内容进行合规审核，并在转码后为各版本重新生成并绑定哈希，以便多版本分发时保持可信锁定。

验收标准

1. WHEN 送审文件验真通过，THE CSPS 审核系统 SHALL 对内容执行合规审核（政治、色情、暴力等维度）。
2. THE 系统 SHALL 在 CSPS 与可信数据空间之间建立对接，使 CSPS 的审核结论可关联至对应 MA码与哈希记录，且 SHALL NOT 要求改造 CSPS 的现有审核流程。
3. WHEN 内容审核通过且需要转码，THE 系统 SHALL 由授权转码中心执行转码，并在转码后重新计算各版本（如 H.264/H.265/4K/HD/SD）文件哈希。
4. WHEN 转码版哈希生成，THE 系统 SHALL 将转码版哈希与 MA码绑定并写入可信数据空间，且 SHALL 与原母版哈希建立父子关系。
5. THE 系统 SHALL 允许同一 MA码绑定多个转码版哈希记录，各转码版 SHALL 共享同一 MA码但拥有独立哈希记录。

---

需求 6：媒体资源库入库、发布与编码映射

User Story: 作为审核和监管部门，我希望审核合格的内容进入已有媒体资源库并作为向运营商发布的统一出口，同时建立媒资编码与 MA码、哈希的映射关系，以便对接监管而不改造现有系统。

验收标准

1. WHEN 内容通过 CSPS 审核（含必要转码），THE 系统 SHALL 将该内容纳入媒体资源库，并保留媒体资源库自有的媒资编码/审核流水号。
2. WHEN 内容入媒体资源库，THE 系统 SHALL 在可信数据空间建立"媒资编码 ↔ MA码 ↔ 文件哈希 ↔ 转码版哈希"的映射关系。
3. WHILE 内容未通过审核或未取得 MA码绑定，THE 系统 SHALL NOT 允许其进入媒体资源库的可发布状态。
4. WHEN 从媒体资源库向运营商发布内容，THE 系统 SHALL 要求发布数据携带 MA码及哈希证书；IF 未携带，THEN THE 系统 SHALL 拒绝发布。
5. THE 系统 SHALL 仅允许审核和监管部门管理其本方（审核/媒资）的映射记录。

---

需求 7：CDN注入校验（运营商端）

User Story: 作为运营商，我希望在内容注入 CDN 前校验其哈希，以便拒绝被篡改或非授权的内容。

验收标准

1. WHEN 运营商接收审核和监管部门从媒体资源库发布的内容并准备注入 CDN，THE 注入校验模块 SHALL 计算注入文件哈希。
2. WHEN 注入文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 允许注入 CDN 并生成分发编码。
3. IF 注入文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 拒绝注入，触发告警并退回审核和监管部门，同时暂停该内容分发。
4. WHEN 注入成功，THE 系统 SHALL 在可信数据空间注册运营商（operator）映射记录（分发编码、CDN端点）。

---

需求 8：终端播放哈希抽检（运营商端）

User Story: 作为运营商，我希望播放器在终端可选地对下载片段进行哈希抽检，以便防止 CDN 劫持或传输篡改。

验收标准

1. WHERE 终端哈希抽检功能开启，WHEN 播放器 SDK（或机顶盒固件）下载内容片段，THE 系统 SHALL 计算该片段哈希并与可信数据空间链上哈希比对。
2. IF 终端抽检哈希与链上哈希不匹配，THEN THE 系统 SHALL 断流并切换至备用源，同时上报异常日志。
3. THE 终端哈希抽检功能 SHALL 支持按网络负载策略性开启或关闭。
4. WHERE 内容为多集，THE 系统 SHALL 支持按集进行增量哈希校验以降低终端计算负载。

---

需求 9：统一维度数据上报与聚合

User Story: 作为监管方，我希望三方播放与业务数据以 MA码为统一维度聚合，以便获得口径一致的可信数据。

验收标准

1. WHEN 运营商上报播出数据，THE 系统 SHALL 以 MA码为统一维度组织数据。
2. THE 可信数据空间 SHALL 按 MA码聚合 CP 播放量、审核和监管部门审核量、运营商分发量，并保证各方数据口径一致。
3. WHEN 数据聚合完成，THE 系统 SHALL 提供按 MA码查询的统一数据视图。

---

需求 10：全生命周期监管查询（监管端）

User Story: 作为监管方，我希望通过监管大屏按 MA码查询内容全链路状态，以便实现精准溯源。

验收标准

1. WHEN 监管方按 MA码查询，THE 监管大屏 SHALL 返回内容当前所在播控平台、当前所在运营商 CDN、当前哈希版本是否最新。
2. WHEN 监管方查询内容历史，THE 系统 SHALL 返回该 MA码的历史版本变更记录。
3. THE 监管大屏 SHALL 支持监管方按 MA码穿透查询三方系统的对应编码。

---

需求 11：违规应急下架（监管端）

User Story: 作为监管方，我希望下发单一 MA码下架指令即可触发全网下架，以便实现秒级应急响应而无需逐层人工翻译。

验收标准

1. WHEN 监管方下发"下架 MA码 第XXX号"指令，THE 系统 SHALL 解析该 MA码并查询其绑定的所有三方编码及 CDN端点。
2. WHEN 下架指令解析完成，THE 系统 SHALL 自动将指令翻译为审核和监管部门侧下架（媒资编码/审核流水号、从媒体资源库撤除发布）与运营商侧下架（分发编码、CDN资源）的执行动作。
3. THE 系统 SHALL 在接收下架指令后秒级同步至全网相关系统，且 SHALL NOT 要求人工逐层翻译。
4. THE 系统 SHALL 仅允许审核和监管部门的监管主体下发应急下架指令；审核主体（媒资发布）与运营商 SHALL 仅执行指令而无下架发起权限。

---

需求 12：版本变更与重审触发

User Story: 作为系统，我希望在内容发生帧级变动时自动断开绑定并触发重审，以便保证审播一致。

验收标准

1. WHEN 内容发生任意帧级变动导致哈希变化，THE 系统 SHALL 判定原 MA码与哈希的绑定断裂。
2. WHEN 绑定断裂，THE 系统 SHALL 在版本变更表中记录变更原因、原哈希、新哈希，并将 reaudit_required 置为 true。
3. WHEN 单集内容被替换，THE 系统 SHALL 通过 Merkle Tree 重新计算该集哈希并定位被篡改的具体集数，且 SHALL NOT 要求全量重审。
4. WHILE 重审未通过，THE 系统 SHALL NOT 允许变更后的内容进入分发流程。

---

需求 13：跨省复用快速准入

User Story: 作为 CP，我希望在一省过审后凭 MA码+哈希证书在其他省份快速准入，以便降低跨省复用的边际成本。

验收标准

1. WHEN CP 持 A省签发的 MA码+哈希证书向 B省播控平台送审，THE 系统 SHALL 仅要求提交 MA码与哈希证书，且 SHALL NOT 要求重新提交内容文件。
2. WHEN B省播控平台发起准入查询，THE 系统 SHALL 验证 MA码真实有效、哈希与原过审版一致、且内容不在黑名单中。
3. WHEN 三重校验通过，THE 系统 SHALL 允许 B省播控平台快速准入，并将内容审核简化为合规性抽检。
4. WHEN B省准入完成，THE 系统 SHALL 生成 B省审核流水号并注册对应映射关系。

---

需求 14：角色权限控制

User Story: 作为系统，我希望按三类角色（内容提供商、审核和监管部门、运营商）的职能矩阵严格控制操作权限，以便保证监管主键的权威性与不可越权。

验收标准

1. THE 系统 SHALL 允许审核和监管部门执行内容合规审核、送审验真、转码授权、签发 MA码、注册哈希、映射管理、全生命周期查询、应急下架全部操作。
2. WHILE 审核和监管部门内部行使权限，THE 系统 SHALL 仅允许其监管主体（广电总局/省局）调用 MA码签发（issueMA）与应急下架发起功能；IF 由审核主体（播控平台）或其他主体调用上述功能，THEN THE 系统 SHALL 拒绝并返回权限错误。
3. THE 系统 SHALL 允许内容提供商在送审时注册哈希、执行自查验真、管理本方映射；且 SHALL NOT 允许其签发 MA码或发起下架。
4. THE 系统 SHALL 允许运营商执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 MA码、注册哈希、发起下架。
5. WHEN 任意角色尝试越权操作，THE 系统 SHALL 拒绝该操作并返回权限错误。

---

需求 15：异常处理

User Story: 作为系统，我希望对各类哈希校验异常采取明确的处理规则，以便保证流程的可控与可追溯。

验收标准

1. IF 送审阶段哈希不匹配，THEN THE 系统 SHALL 退回 CP，要求说明版本差异，必要时要求重新送审。
2. IF CDN注入阶段哈希不匹配，THEN THE 系统 SHALL 拒绝注入、告警审核和监管部门并暂停该内容分发。
3. IF 终端抽检阶段哈希不匹配，THEN THE 系统 SHALL 断流、切换备用源并上报异常日志。
4. WHEN 内容发生剪辑/修改，THE 系统 SHALL 要求重新计算哈希、提交变更申请并触发重新审核。
5. WHEN CP 以同一哈希换壳重发，THE 系统 SHALL 识别哈希已存在并拒绝重复申报，同时关联原 MA码。

---

需求 16：可信数据空间存证与智能合约

User Story: 作为系统，我希望通过联盟链与智能合约管理 MA码、哈希与映射的存证，以便保证数据不可篡改与可信。

验收标准

1. THE 可信数据空间 SHALL 维护内容主表、哈希绑定表、三方编码映射表、版本变更表四类核心数据结构。
2. THE 智能合约 SHALL 提供 issueMA（签发）、registerMapping（注册映射）、verifyHash（哈希校验）核心方法。
3. WHEN registerMapping 被调用，IF 对应 MA码尚未签发，THEN THE 系统 SHALL 拒绝注册映射。
4. THE 系统 SHALL 通过 Merkle Tree 存储多集内容的分段哈希，并支持按集定位篡改。
5. THE 可信数据空间 SHALL 保证已写入的 MA码与哈希绑定记录不可篡改。

---

需求 17：接口规范

User Story: 作为三方系统集成方，我希望通过标准化 API 与可信数据空间交互，以便低成本对接。

验收标准

1. THE 系统 SHALL 提供哈希上链接口（POST /api/v1/content/register），供 CP 提交标题、集数、各集文件哈希、Merkle根、感知哈希、时长、分辨率、CP媒资ID，并返回送审流水号与状态。
2. THE 系统 SHALL 提供哈希验真接口（GET /api/v1/content/verify），供播控/运营商按 MA码与文件哈希查询并返回 valid、bound_hash、submitted_hash、match、version、转码版列表。
3. THE 系统 SHALL 提供映射查询接口（GET /api/v1/content/mappings），供应急下架按 MA码查询三方编码映射与 CDN端点。
4. THE 系统 SHALL 对接口调用进行身份鉴权（如 Bearer Token）。

---

非功能性需求

需求 18：性能与时效

验收标准

1. THE 系统 SHALL 将违规内容下架响应时间从现状的 2-24 小时缩短至分钟级。
2. THE 系统 SHALL 将跨省复用审核周期从现状的 15-30 天缩短至 3-5 天。
3. THE 系统 SHALL 将三方数据对账差异从现状的 15-30% 降低至 5% 以内。
4. THE 系统 SHALL 实现内容版本替换的 100% 自动识别。

需求 19：兼容性与最小侵入

验收标准

1. THE 系统 SHALL NOT 要求三方放弃其自有编码体系，且 SHALL 与审核和监管部门已有的 CSPS 审核系统、媒体资源库通过映射层对接而不改造其内部流程。
2. THE 系统 SHALL 仅在送审、CSPS审核、媒体资源库入库/发布、CDN注入、终端播放等关键节点嵌入校验，并通过映射层对接现有系统。
3. THE 系统 SHALL 完全符合广电总局网络剧片发行许可及备案制度。
4. THE 系统 SHALL 支持网络剧、微短剧、网络电影、网络动画等多形态内容，并 SHALL 可扩展至 OTT、手机 APP 等大小屏形态。

需求 20：安全与可信

验收标准

1. THE 系统 SHALL 保证 MA码与哈希的绑定记录一经写入不可篡改、不可解绑。
2. THE 系统 SHALL 保证哈希计算在 CP 本地完成，原始内容文件 SHALL NOT 上传至可信数据空间（区块链）；原片仍通过审核方（CSPS/媒资库）既有送审渠道提交以供内容审核，TCS 不改造该渠道。
3. THE 系统 SHALL 对所有关键操作（签发、注册、验真、下架）进行链上存证以支持审计。

澄清（原片与哈希的边界）：CSPS 的内容审核基于真实原片（经既有送审渠道提交），TCS 不替代内容审核；TCS 仅将原片哈希上链，作用是"锁定审核对象"——保证审核版=入库版=发布版=播出版（审播一致），并在任一环节被偷换时通过哈希比对识别。"不上传原片"特指不上链，而非不提交给审核方。

---

价值场景需求（权利 · 效率 · 利益）

需求 21：可信播放数据聚合与分账结算依据（利益）

User Story: 作为内容提供商与运营商，我希望以 MA码为唯一维度获得不可篡改的可信播放数据，以便作为分账结算的统一依据，消除对账争议。

验收标准

1. WHEN 各运营商上报播放数据，THE 系统 SHALL 以 MA码为唯一维度在可信数据空间链上聚合，形成不可篡改的可信播放量记录。
2. THE 系统 SHALL 向 CP 与运营商提供同一份以 MA码聚合的播放数据视图，且各方所见数据 SHALL 口径一致。
3. WHEN 进行分账结算，THE 系统 SHALL 以链上可信播放数据作为统一结算依据。
4. WHEN CP 与运营商对账，THE 系统 SHALL 将数据差异控制在 5% 以内。
5. THE 系统 SHALL 提供可信播放数据的查询与导出能力，供结算与审计使用。

---

需求 22：全链路责任界定与追责取证（权利）

User Story: 作为审核和监管部门，我希望在出现违规内容时按 MA码调取全链路哈希存证，以便精准界定问题出在哪个环节、是哪一方改动。

验收标准

1. WHEN 监管按 MA码发起追责查询，THE 系统 SHALL 返回该内容全链路各节点的哈希存证记录（CP送审、CSPS审核结论、转码版、媒资库发布、运营商注入、终端抽检）。
2. WHEN 各节点哈希比对，THE 系统 SHALL 标识首次发生哈希变化的节点，并定位对应责任方与责任环节。
3. THE 系统 SHALL 保证各节点存证记录带时间戳、操作方标识且不可篡改。
4. THE 系统 SHALL 提供责任界定取证报告的导出能力，供问责与审计使用。

---

需求 23：版权确权与维权举证（权利）

User Story: 作为内容提供商，我希望凭 MA码、哈希与上链时间戳形成不可抵赖的确权证据，以便在被盗版时进行维权举证。

验收标准

1. WHEN 内容完成哈希上链，THE 系统 SHALL 记录 MA码、内容哈希、上链时间戳，形成"谁先锁定谁有权"的确权证据。
2. WHEN CP 申请确权证据，THE 系统 SHALL 导出可用于侵权投诉与司法诉讼的不可抵赖证据链（含链上存证哈希与时间戳）。
3. WHEN 系统检测到某内容的感知哈希与已确权内容高度相似（超过设定阈值），THE 系统 SHALL 标记疑似侵权并关联原 MA码。
4. THE 系统 SHALL 保证确权证据记录不可篡改、不可抵赖。

---

需求 24：追更与增量哈希更新（效率）

User Story: 作为内容提供商，我希望在剧集追更或局部修正时仅对变化部分重新计算哈希，以便快速完成赋码与发布而无需重走全流程。

验收标准

1. WHEN 内容发生追更或局部修正，THE 系统 SHALL 仅对变化的集或片段重新计算哈希。
2. WHEN 增量哈希更新，THE 系统 SHALL 基于 Merkle Tree 仅更新变化叶子节点并重算根哈希，未变化部分 SHALL 复用原哈希与原审核结论。
3. WHEN 增量更新提交，THE 系统 SHALL 在版本变更表中记录变化范围与新旧哈希。
4. IF 仅新增内容（如追更新集）且不改动已审通过部分，THEN THE 系统 SHALL 支持对新增部分快速赋码而不触发存量部分重审。

---

需求 25：授权链上链与发布前授权核验（权利+利益）

User Story: 作为审核和监管部门与运营商，我希望在发布/注入前实时核验内容的授权范围，以便拦截越权、过期或非授权平台的分发。

验收标准

1. WHEN CP 提交授权信息，THE 系统 SHALL 将信息网络传播权的授权范围（地域、期限、平台）上链存证。
2. WHEN 从媒体资源库发布或运营商注入 CDN 前，THE 系统 SHALL 核验该分发是否在授权范围内。
3. IF 分发超出授权地域、超过授权期限或面向非授权平台，THEN THE 系统 SHALL 拦截该分发并告警。
4. WHEN 授权范围发生变更，THE 系统 SHALL 记录授权变更历史并可追溯。

---

关键约束与假设

类别	内容
约束	不替代三方现有系统，仅建立"可信身份映射层"；审核和监管部门已有 CSPS 审核系统与媒体资源库，通过映射层对接
约束	MA码签发权与应急下架发起权仅归审核和监管部门的监管主体
约束	MA码与哈希 1:1 强绑定，不可解绑
约束	审核合格内容进入媒体资源库，并由媒体资源库作为向运营商发布的统一出口
假设	三方系统具备在关键节点集成哈希计算SDK与API调用的能力
假设	CSPS 审核系统与媒体资源库可开放对接接口，关联 MA码与哈希记录
假设	广电总局备案系统可对接 MA码签发与哈希绑定
依赖	联盟链/分布式账本基础设施可用
依赖	授权转码中心具备转码后哈希重算与上链能力

---

本需求文档作为 TCS-IPTV 系统设计与实现的依据，后续设计文档与任务分解将基于本文档展开。