模型库存管理：模型清单、使用场景、依赖度、验证状态

模型库存管理：模型清单、使用场景、依赖度、验证状态本文档提供：模型定义与入库准入判定表1张；清单核心字段表1张；使用场景与依赖度分级表1张；验证状态字段与更新触发表1张；更新频率与盘点节奏表1张；清单使用规则表1张；清单完整性自检表1张；决策规则6条与矛盾四段1处；完整示例1个（含四次试错与变量表）；三套场景操作序列表1张；来源说明表1张。2026-11-03这一节的标题读完你能拿到什么这一节在全文中的功能一、什么算“一个模型”、什么该进清单，先定准入再填字段模型定义与入库准入判定表（表1），逐行填对象、判定、去向确定清单的边界，防止只登记统计模型、漏掉供应商模型和嵌入组件二、清单核心字段：缺哪一列，审计时就答不上哪一类问题清单核心字段表（表2），含字段、取值规则与缺失后果给出模型清单的硬性字段清单，不停在“有清单就行”三、使用场景与依赖度：清单里必须能回答“如果这个模型错了，什么会跟着错”使用场景与依赖度分级表（表3），含场景类别、依赖标记与上下游关联字段把使用场景和依赖关系落成可填的列，防止清单只记录模型名称四、验证状态：不是只写“已验证”，要写清上次结论、下次日期和未关闭发现验证状态字段与更新触发表（表4），含状态档位、触发条件与回写规则把验证状态变成动态字段，解决清单与验证记录脱节的问题五、更新频率：例行更新按月、按季，非周期更新由可观测事件触发更新频率与盘点节奏表（表5），含更新类型、触发事件、责任岗位与时限给出更新的时间规则和事件规则，防止清单变成“年初填一次”的静态表六、清单怎么用：谁在读、读哪几列、用来做什么判断清单使用规则表（表6），含使用角色、读取字段与禁止用法把清单从“登记表”变成可用于排期、审计、退役决策的工具七、清单完整性自检：四条检查点，从模型清单反查遗漏清单完整性自检表（表7），含检查点、打开哪个文件、什么算漏给出定期自检的操作路径，防止清单与生产实际脱节八、什么情况补录、什么情况降级、什么情况退役，六条规则决策规则6条与矛盾四段式给超出标准维护流程时的判断依据九、一次完整的库存清理：从127个模型到补录9个、退役6个完整示例，含四次试错、终点与变量表（表8）展示字段核对、更新触发和完整性自检在真实清理顺序中的落地十、三套场景操作序列：完整维护、精简维护、极简盘点三套版本检查项与产出增减对照表（表9）按机构规模和清单成熟度选择执行深度按第一列在正文找对应那节，按第二列判断这节有没有所需内容，按第三列判断这节是否对应当前卡住的位置。审计组进场前一周，模型清单有127行，每行只有模型名称、开发部门和上线年份三列。审计组提出的第一个问题就卡住了：“这127个里面，哪些是供应商提供的、哪些是嵌在采购系统里的、哪些最近12个月没有任何调用记录？”清单答不上来。第二个问题是：“上次验证结论是‘有条件使用’的那几个模型，条件是什么、到期了没有？”清单里没有验证结论字段。第三个问题是：“如果评分卡模型的输出是错的，下游哪些定价和拨备计算会受影响？”清单里没有依赖关系列。一、什么算“一个模型”、什么该进清单，先定准入再填字段模型库存管理的第一件事不是设计字段，是确定哪些对象该被登记。SR26-2将模型定义为应用统计、经济、金融或数学理论、技术和假设，将输入数据处理为定量估计的定量方法或系统。这个定义的外延比“统计模型”宽：供应商提供的模型、嵌入在采购软件中的模型、以及机器学习系统都在范围内，“我们买来的”不构成豁免。SR26-2同时明确，电子表格算术和确定性规则流程不再纳入模型定义，这类工具如果仍被跟踪，应当明确标注为“自愿跟踪而非模型”。表1模型定义与入库准入判定对象判定问题进清单不进清单但需要跟踪判定依据内部开发的信用评分卡是否将输入数据处理为定量估计，用于授信决策进—符合模型定义，直接影响审批供应商提供的反洗钱监测模型是否由供应商构建、本机构使用其输出做决策进—供应商模型在范围内，验证和监控责任不转移采购核心系统中嵌入的定价引擎是否作为系统组件运行、输出用于定价或估值进—嵌入组件属于模型依赖，须在清单中单独建行或作为关联项仅做加减乘除的预算汇总表是否仅含算术运算和确定性规则—是，标注“自愿跟踪”SR26-2将电子表格算术排除出模型定义已停用但未满处置期的模型是否在最近12个月内产生过决策输出进（状态标“退役”）—SR26-2要求清单覆盖“使用中、开发中或最近退役”的模型影子模型（业务部门自行搭建的未登记模型）是否实际用于决策但未走正式登记流程进（补录）—清单不完整是审计中最常见的问题；影子模型必须纳入单一真相源表1第3行的嵌入式组件有一个操作选择：可以为每个嵌入组件单独建行，也可以在主模型行下挂“依赖组件”子表。选择标准是看该组件是否会被独立修改：供应商整体升级系统时组件随之变化，可以不单独建行，但必须在依赖字段中写明组件名称和版本；如果组件可以单独配置参数或单独更新，则单独建行。二、清单核心字段：缺哪一列，审计时就答不上哪一类问题PwC的2024年模型风险调查把模型清单应覆盖的信息分为六类：模型描述与分类、模型发现、模型文档、角色与职责、风险分层、生命周期信息。调查中收集比例最高的是“模型描述与分类”（97%），其次是“风险分层”（85%）、“角色与职责”和“生命周期信息”（各79%）。字段设计不需要追求“最多列”，需要保证每一列对应一个会被问到的问题。表2清单核心字段字段组字段取值规则缺失时答不上来的问题示例值标识模型ID唯一、不复用；退役模型的ID不分配给新模型这个模型和那个模型是不是同一个M-0142标识模型名称与版本名称在业务上可识别；版本号与生产环境一致清单里的版本和线上跑的是不是同一版零售评分卡v3.2描述用途与预期使用场景一到两句话，写清用于什么决策、在哪个环节使用这个模型到底在做什么决策零售信贷审批辅助判断分类模型类型统计/计量、机器学习、规则混合、供应商产品；选一个主类型这是不是一个黑箱模型统计（逻辑回归）分类风险层级按重要性、复杂度、错误后果分高/中/低；层级驱动验证频率和文档深度为什么这个模型一年验一次、那个三年一次高角色模型所有者（岗位）写岗位名称，不写人名；岗位变动时更新这个模型出问题找谁零售信贷模型管理岗角色开发方与验证方（岗位）开发方与验证方不得为同一岗位谁开发的、谁验的，是否独立开发：数据建模岗；验证：模型验证岗使用使用部门与决策环节写清输出被谁消费、在哪个决策点被引用如果模型停了，哪个业务会停零售信贷部，审批环节依赖上游数据/模型列出该模型依赖的数据源或前置模型上游数据变了，这个模型要不要重验征信数据、反欺诈分依赖下游模型/用途列出消费该模型输出的模型或决策这个模型错了，还会把什么带错定价模型、拨备计算验证上次验证日期与结论日期写到日；结论取“适合/有条件/不适合”三档之一上次验完到底能不能用2026-08-14，有条件使用验证下次验证到期日按风险层级和验证政策推算什么时候该重验2027-02-14验证未关闭高严重程度发现只列未关闭的，写发现编号和关闭期限上次发现的问题改了没有F-2026-003，期限2026-12-31生命周期状态开发中/使用中/暂停使用/退役；四档互斥这个模型还在用吗使用中生命周期上线日期与退役日期退役行必须填退役原因和停止生成决策的日期为什么停的、什么时候停的—文档文档链接或存放位置指向开发文档、验证报告、审批记录文档在哪、能不能打开文档库路径表2第6行的风险层级不是一个装饰性分类。它直接决定验证频率、文档深度和独立性要求：高风险模型可能需要每半年一次全流程独立验证，中风险模型每年一次，低风险模型按更长的周期或简化流程处理。层级判定标准必须事先写在模型风险管理政策中，不能由业务部门在填清单时自行选择。表2第13行的“未关闭高严重程度发现”是清单与验证记录之间的关键接口。清单里只写“已验证”不够，必须携带未关闭发现的编号和期限，否则验证结论中的条件无法在清单层面被追踪。三、使用场景与依赖度：清单里必须能回答“如果这个模型错了，什么会跟着错”使用场景和依赖度不是两个独立的字段，它们在清单中共同回答一个审计和业务连续性问题：这个模型的输出被哪些下游决策或模型消费。依赖字段是清单中最容易被省略、也最能区分“名称列表”和“可用库存”的一列。E-23指南把“捕捉上游数据、前置模型和下游使用的依赖关系”列为集中式模型清单的核心要求之一。表3使用场景与依赖度分级使用场景类别判定问题依赖度标记清单中必须填的关联字段不填的后果直接决策（输出直接生成审批、定价或限额）人工是否逐笔复核模型输出高依赖；该模型状态变化必须通知所有下游下游模型/决策、使用部门、决策环节模型暂停时下游无人知道辅助判断（输出作为人工判断的输入之一）人工推翻比例是否可查中依赖；变更时通知直接使用部门使用部门、决策环节变更影响范围被低估监控预警（输出触发名单或告警）告警后是否有跟进流程中依赖；阈值或规则变更时通知运营岗位使用部门、下游流程告警失效未被发现报告展示（输出进入报表或披露）是否用于对外报送或管理层决策材料低依赖但披露相关；口径变化须通知报告编制岗使用部门、报告名称口径变更导致报告数据断裂嵌入组件/供应商模型是否作为其他模型的输入或系统组件依赖度随宿主模型；须标注供应商和组件版本上游/下游、供应商、版本供应商静默更新未被察觉表3第1行的高依赖场景对应一个具体的清单操作：该模型行必须在“下游模型/用途”列中列出所有消费其输出的对象，且当模型状态从“使用中”变为“暂停使用”或“退役”时，这些下游对象必须在变更通知记录中逐个确认。第5行的供应商模型依赖有一个特有的风险：供应商可能在机构不知情的情况下更新模型，而清单仍然显示旧版本。应对方式是在清单中增加“供应商变更通知条款”字段，或把供应商版本核对列为更新频率中的例行动作。四、验证状态：不是只写“已验证”，要写清上次结论、下次日期和未关闭发现验证状态字段的作用是让清单在任何时点都能回答“这个模型当前处于什么使用许可状态”。SR26-2不再把验证框定为固定年度周期，而是把验证时点和频率与模型的目的、方法、变化率和数据限制挂钩。这意味着清单中的验证字段必须是动态的，不能只在年初填一次。表4验证状态字段与更新触发验证状态档位含义清单中必须同时出现的字段触发回写的事件适合使用验证通过，模型可按预期用途全量使用上次验证日期、结论、下次到期日定期复审完成；无高严重程度未关闭发现有条件使用在限定条件下使用；条件写入模型使用政策条件文本、条件到期日、未关闭发现编号条件到期；条件满足后重新验证；条件失效不适合使用暂停用于决策；已产生的输出须评估回溯影响暂停日期、暂停原因、责任岗位修正完成并重新验证通过未验证/验证过期尚未验证，或超过下次验证到期日未完成复审到期日、超期天数、临时控制措施完成验证并回写结论表4第2行的“有条件使用”是最常用的状态，也是清单最容易写空的一档。条件必须写成可检查的约束，例如“仅用于辅助判断，不得直接生成审批结论”“输出用于定价时须叠加人工复核”，而不是“注意使用”。条件到期日必须写到日；到期未满足条件的，清单状态自动从“有条件使用”改为“不适合使用”，这个自动降级规则写入清单维护规程，不依赖人工记得。更新触发的可观测条件。验证状态的更新不是“想起来就改”，由以下事件之一触发：定期复审完成并出具结论；条件到期；模型发生重大变更并完成重新验证；监控发现性能突破预设阈值。重大变更的典型触发包括模型重训、输入数据来源显著变化、检测到性能漂移超过定义阈值、计算环境变化。这些触发条件写入清单的“最近重大变更”字段，变更日期和变更类型一并记录。五、更新频率：例行更新按月、按季，非周期更新由可观测事件触发模型清单的更新分两类：例行更新和非周期更新。例行更新按固定节奏执行，非周期更新由事件触发。两者的责任岗位和时限不同，混在一起会导致“月月填表但关键变化没人报”。表5更新频率与盘点节奏更新类型频率或触发事件更新内容责任岗位时限不做的后果例行状态核对每月状态列（使用中/暂停/退役）、未关闭发现编号模型管理岗次月第5个工作日前状态滞后，退役模型仍被当作在用例行验证字段更新每季度下次验证到期日、超期标记、条件到期日模型验证岗季度结束后10个工作日内验证到期无人发现例行依赖关系复核每半年上游数据/模型、下游模型/用途、供应商版本模型管理岗联合使用部门半年度结束后15个工作日内依赖变化未被捕捉，影响面判断错误非周期更新：新模型上线投产前新增行，填写全部必填字段开发方提交，模型管理岗录入上线前完成影子模型在审计时才被发现非周期更新：重大变更变更发生时版本、上次验证日期、结论、重大变更字段模型所有者变更完成后5个工作日内清单版本与生产版本不一致非周期更新：验证完成验证结论签发时验证状态、上次结论、下次到期日、未关闭发现验证岗结论签发后3个工作日内验证报告与清单脱节非周期更新：退役退役决定作出时状态改为退役、退役原因、停止决策日期模型所有者退役生效前已退役模型仍占验证名额全面盘点每年至少一次全量字段与生产实际、验证记录、依赖关系交叉核对模型管理岗牵头，内部审计抽样复核年度结束后30个工作日内清单与生产实际系统性脱节表5第5行的“重大变更完成后5个工作日内”是清单与变更控制流程的接口。变更控制流程本身应该产生一个“变更完成”事件，清单更新动作挂在这个事件上，而不是依赖模型所有者主动记得改清单。第8行的年度全面盘点不是把例行核对重复一遍，是拿清单与生产系统清单、验证记录、供应商合同三个来源做交叉核对，找出“在生产但不在清单”“在清单但已不在生产”“验证记录存在但清单未回写”三类差异。更新频率的风险层级差异：高风险模型的验证字段按季度更新，中低风险模型可以按半年更新；高风险模型的依赖关系每半年复核，低风险模型可以每年复核。频率差异写入维护规程，不在清单中逐行判断。六、清单怎么用：谁在读、读哪几列、用来做什么判断模型清单不是只给模型管理岗看的登记表。不同角色从清单中读取不同的列，用于不同的判断。清单字段的设计要服务于这些读取行为，而不是为了“完整”而堆列。表6清单使用规则使用角色读取的列用来做什么判断禁止用法模型验证岗风险层级、下次验证到期日、上次结论、未关闭发现排下一季度验证计划；识别超期模型不凭清单的风险层级直接替代验证中的独立判断内部审计状态、依赖关系、最近重大变更、验证结论抽样选择审计对象；检查清单与验证记录是否一致不以清单字段完整替代实质性测试业务使用部门用途、使用场景、状态、条件约束确认模型是否可用于当前决策；条件是否满足不把“清单里有这个模型”当作“模型适用于本部门场景”模型所有者全部字段维护本模型记录；发起变更和退役不自行修改风险层级或验证状态高级管理层/风险委员会按风险层级汇总的模型数量、验证状态分布、超期数量判断模型风险整体轮廓和资源分配不用清单行数作为“模型风险大小”的替代指标表6第3行是使用部门最常见的误用：清单中的“使用场景”字段写的是模型被批准的使用方式，不是对任何部门、任何决策场景的通行许可。使用部门在引用模型输出前，需要核对自己的使用方式是否落在清单记载的批准场景内。第4行禁止模型所有者自行修改风险层级和验证状态：这两个字段分别由模型风险管理政策和验证职能控制，所有者的权限限于描述性字段和生命周期状态中的“退役”申请。七、清单完整性自检：四条检查点，从模型清单反查遗漏清单的完整性不能靠“填表的人觉得填全了”。审计中最常见的发现是清单不完整、过时或分散在多个互相矛盾的表格中。自检从可打开的来源文件出发，反向核对清单。表7清单完整性自检检查点打开哪个文件看什么算什么比什么什么算漏换哪条路生产系统清单反查生产系统或应用清单中的“算法/规则/评分”列数在生产环境中运行但模型清单中无对应行的对象数大于0算漏逐项判定是否属于模型定义（表1）；属于则补录，不属于则标注“自愿跟踪”供应商合同反查采购合同台账中“含模型/评分/定价引擎”标记的合同数合同中有模型组件但清单无对应行的合同数大于0算漏为每个模型组件建行或挂依赖子表；标注供应商和版本验证记录反查验证报告台账中的“模型ID”列数有验证报告但清单中无对应行或验证字段未回写的条数大于0算脱节补录模型行或回写验证字段；查验证报告是否对应已退役模型退役模型反查变更或退役审批记录数已批准退役但清单状态仍为“使用中”的模型数大于0算漏更新状态、退役日期、退役原因；通知下游依赖方表7第1行是发现影子模型的主要路径。业务部门自行搭建的电子表格或规则工具如果在生产决策中被使用，即使没有走正式开发流程，也属于应当纳入清单的对象（除非按SR26-2明确排除为算术或确定性规则）。第2行针对供应商模型：采购合同中包含的评分、定价、反洗钱监测等组件，不能因为“是买来的”就不登记。第3行检查清单与验证记录的脱节：验证完成了但清单没更新，和验证没做一样会导致排期错误。八、什么情况补录、什么情况降级、什么情况退役，六条规则规则1（发现未登记的生产模型）。如果生产系统清单或使用部门反馈中存在实际用于决策但模型清单无记录的对象，则该对象按表1判定是否属于模型定义；属于的，在5个工作日内补录，状态标“使用中”，验证字段标“未验证”并排入下一验证周期。退路：补录后确认该对象属于SR26-2排除的算术或确定性规则时，改为“自愿跟踪”记录，不占模型验证名额。规则2（供应商静默更新）。如果供应商通知或版本核对发现供应商模型的版本已变更而清单仍显示旧版本，则该模型行在“最近重大变更”字段记录变更日期和变更类型，验证状态按变更影响评估是否降为“未验证”。退路：供应商未提供变更细节、无法评估影响时，验证状态暂标“有条件使用”，条件为“完成供应商变更影响评估前不扩展使用范围”。规则3（验证结论到期未续）。如果有条件使用的条件到期日已过且未完成重新验证，则清单状态自动从“有条件使用”改为“不适合使用”，暂停日期填条件到期日次日。退路：条件到期前已启动重新验证但尚未完成的，状态标“验证中—暂停扩展使用”，不直接降为不适合，但不得新增使用场景。规则4（模型退役）。如果模型所有者提出退役，则清单状态改为“退役”，必须填写退役原因、停止生成决策的日期、下游依赖方的通知记录。退路：退役后下游仍有未切换的依赖方时，该模型行保留在清单中并标“退役—下游待切换”，不删除，直到所有下游确认切换完成。规则5（风险层级调整）。如果模型的使用场景从辅助判断升级为直接决策，或错误后果的严重程度发生实质变化，则风险层级由中/低调为高，验证频率和文档深度随之调整。退路：层级调整的依据写入清单备注，不由模型所有者单方面决定，须经模型风险管理岗确认。规则6（清单行重复或碎片化）。如果同一模型在清单中出现多行（例如开发方和使用方各登记一次），则按模型ID去重，保留一行主记录，其他行的差异信息并入主记录的备注或依赖字段。退路：确实存在同一逻辑的多个部署实例时，每个实例单独建行，但在“模型组”字段中标注同一组，避免验证排期重复计算。矛盾四段。矛盾陈述：清单字段越全，审计和排期越有据可查；但字段越多，维护成本越高，业务部门和模型所有者越倾向于延迟更新或填“待补充”，清单反而变得不可信。实质分析：冲突不在“字段数量”，在“谁为每个字段的准确性负责”。描述性字段（用途、依赖）的准确性依赖使用部门和所有者，验证字段依赖验证岗，层级字段依赖风险管理岗；如果不区分责任岗位而要求“填表的人全填”，准确性最弱的字段会拖累整行记录的可信度。权衡规则：必填字段按责任岗位拆分，描述性和依赖字段由所有者在变更时更新，验证字段由验证岗在结论签发时回写，层级字段由风险管理岗维护；任何字段的更新不等待其他字段。退路：某类字段连续两个盘点周期缺失率超过30%时，暂停新增模型录入，先修该字段的数据来源或责任流程，不在字段缺失的情况下继续扩大清单。九、一次完整的库存清理：从127个模型到补录9个、退役6个以下示例案例为合理设定，细节用于展示字段核对、更新触发和完整性自检在真实清理顺序中的落地。起点。某机构模型清单127行，只有模型名称、开发部门、上线年份三列。审计组一周后进场，要求提供完整的模型库存。清单需要在一周内补齐核心字段并完成一次完整性自检。分步操作与不顺利环节。第一轮。信号：先按表2补字段，发现“下游模型/用途”列几乎全部为空。当时以为依赖关系可以由模型所有者口头补充。试了让127个模型的所有者在两天内书面回复下游依赖，回收率不到40%，回复中多数写“无下游”或“仅本部门使用”。试完发现依赖字段不能靠事后问卷补齐，推翻了“集中收集一次就能填全”的假设。换路：不从问卷出发，从定价模型和拨备计算模型这两个已知的下游模型反查——打开这两个模型的输入清单，找出它们引用了哪些上游模型的输出，反向填充上游模型的“下游模型/用途”列。第二轮。信号：反向填充后，发现有9个模型在生产环境中运行但不在清单中，其中4个是供应商嵌入组件。当时以为“供应商的东西不在我们清单里是正常的”。试了打开采购合同台账，发现这4个组件的合同中都包含“模型”或“评分引擎”字样。试完发现供应商模型不是豁免项，推翻了“买来的不用登记”的假设。换路：按规则1补录9行，供应商组件标注供应商名称和版本，状态“使用中”，验证字段“未验证”。第三轮。信号：补录后核对验证记录，发现清单中有6个模型已批准退役但状态仍为“使用中”。当时以为退役审批完成就等于清单自动更新。试了查退役审批记录和清单的最后修改日期，6个模型的退役批准日期都在6个月以前，清单从未回写。试完发现退役不是清单的自动触发器，推翻了“审批完了清单会跟着变”的假设。换路：按规则4更新6行状态为“退役”，填写退役原因和停止决策日期；其中2个模型有下游未切换，标“退役—下游待切换”，不删除。第四轮。信号：年度全面盘点时，用生产系统清单反查，又发现3个业务部门自行搭建的评分表在实际使用中，但从未进入清单。当时以为“业务部门自己用的表格不算模型”。试了检查这3个表格的用途，其中一个直接生成客户分层名单并影响营销资源分配。试完发现“谁开发的”不是判定标准，“是否将输入数据处理为定量估计并用于决策”才是，推翻了“只有正式开发的才算模型”的假设。换路：按表1判定，2个属于模型（补录），1个仅含算术汇总（标“自愿跟踪”）。终点。清单从127行变为补录9行、退役6行（其中2行保留“退役—下游待切换”）、新增“自愿跟踪”1行，总行数139行（含退役保留行）。核心字段补齐：状态、风险层级、上次验证日期与结论、下次验证到期日、上游/下游依赖、供应商版本。完整性自检四条检查点各填一行结论：生产系统反查发现3个，供应商合同反查发现4个，验证记录反查发现6个退役未回写，退役审批反查确认6个已处理。未关闭高严重程度发现列填入2条，附发现编号和期限。表8示例中的关键变量与处置变化变量案例中情形如果变量不同处置变化清单原始字段数3列已有部分验证字段完整性自检可先做验证记录反查，减少补录工作量依赖字段回收率（问卷方式）低于40%回收率高于80%可以问卷为主、反查为辅；但仍需用下游模型反查核对供应商嵌入组件数4个供应商组件超过20个按供应商分组建行，在组内逐组件登记；增加供应商变更通知字段的核对频率退役未回写模型数6个退役未回写超过15个暂停新增模型录入，先完成退役状态批量清理和下游通知影子模型数3个（2个补录、1个自愿跟踪）影子模型超过10个在全面盘点中增加使用部门访谈环节，不只依赖系统清单反查变量表中权重较高的变量是“依赖字段回收率”：它决定依赖关系是以集中收集为主还是以下游反查为主，其余变量影响的是补录批次和退役清理范围，不改变“从可打开的来源文件反查清单”的完整性自检路径。十、三套场景操作序列：完整维护、精简维护、极简盘点选择依据：模型数量超过50个或面临监管检查走完整维护；模型数量在20至50个之间走精简维护；模型少于20个或岗位交接走极简盘点。表9三套场景的检查项与产出增减版本执行哪些步骤（对应表1至表7）保留产出去掉检查项不能妥协的底线完整维护表1至表7全量，含月度状态核对、季度验证字段更新、半年度依赖复核、年度全面盘点全字段清单、更新记录、完整性自检四行结论、退役保留行不删依赖字段必须有；验证状态含未关闭发现；退役行不删除；年度盘点做三类反查精简维护表1、表2核心字段、表5（例行状态与验证字段）、表7前两行核心字段清单、月度状态与季度验证更新、生产系统和供应商合同反查半年度依赖复核、年度全面盘点、退役下游待切换的逐项确认被跳过项标“本期未做”；补录行状态和验证字段必须填；退役行状态必须改极简盘点表1准入判定、表2的标识/状态/验证结论三组字段、表5的退役更新模型ID、状态、上次验证结论、退役记录依赖关系、风险层级、供应商版本、完整性自检全量极简盘点不用于监管检查或验证排期；退役模型必须标出，不能以“清单里没有”代替“已退役”极简盘点的一条具体排查规则：如果清单中某模型的状态为“使用中”但上次验证结论为空或“未验证”，该行不进入极简盘点的“已盘点”计数，标“验证状态缺失”，由接手人在当班内确认该模型是否实际在用、是否已排入验证计划，不能默认其为正常使用中。这条规则不写成“按实际情况处理”。完整维护的序列是：确定模型定义与准入边界、补齐核心字段、建立依赖关系、按表5节奏执行例行与非周期更新、年度全面盘点做生产系统/供应商合同/验证记录/退役审批四类反查。精简维护的序列是：核心字段补齐、月度状态与季度验证字段更新、生产系统和供应商合同两类反查。极简盘点只产出“