OpenMed 删除影响规划基于本地清单的非破坏性删除预演与显式执行边界【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed导读openmed.risk.deletion_plan是 OpenMed 提供的一个本地、非破坏性的删除影响规划模块在调用方真正移除某个 OpenMed 管理的缓存cache、映射map或证据evidence工件之前它先根据一份本地清单计算删除后会波及哪些工件并输出仅含计数与完整性摘要的安全报告。读完本文你将掌握删除影响清单manifest的编写规范、反向依赖追踪的工作原理、plan_deletion_impact与execute_deletion_plan的完整用法以及该模块在隐私保护上的边界设计——它只做规划从不替调用方执行删除。需要特别强调的是该模块是规划辅助工具不是合规认证也不保证数据的所有副本都能被发现删除策略、法律保留、备份与人工复核的责任始终在调用方。一、设计定位预演在先删除在后OpenMed 是一款本地优先local-first的医疗 AI 框架其 risk 子包 聚焦再识别风险、审计与隐私治理。deletion_plan模块解决的是一个非常具体的运维问题当应用需要清理自己维护的缓存、映射或证据工件时如何在不触碰真实数据的前提下先看清删除的连锁反应。模块文档字符串见 openmed/risk/deletion_plan.py明确给出三条设计原则确定性规划是确定性的相同输入永远产生相同计划与报告非破坏性规划永远是 dry-run实际删除被显式委托给注入的回调函数隐私安全公开序列化只包含计数与完整性摘要原始标识符、路径和清单字段永远不会被复制进报告。从源码结构看模块本身不执行任何网络或文件系统操作除非调用方显式传入一个本地 JSON 清单路径这一点由单元测试test_planning_works_when_outbound_sockets_are_blocked专门验证即使把socket.socket.connect替换为直接抛错规划过程依然能正常完成见 tests/unit/risk/test_deletion_plan.py。二、Manifest 形状三种输入方式与条目字段plan_deletion_impact的第一个参数manifest支持三种输入形式源码中定义为ManifestInput类型别名见 openmed/risk/deletion_plan.py一个包含artifacts列表的映射Mapping一个条目序列Sequence一个指向本地 JSON 文件的str或Path。每个条目包含工件哈希、安全的 kind、保留类别retention class、可选的依赖链接和所有权标记。下面是文档中的完整示例from openmed.risk.deletion_plan import plan_deletion_impact cache_hash sha256: 0 * 64 map_hash sha256: 1 * 64 manifest { artifacts: [ { artifact_hash: cache_hash, kind: cache, retention_class: short, dependencies: [], owned: True, }, { artifact_hash: map_hash, kind: map, retention_class: standard, dependencies: [cache_hash], owned: True, }, ] } plan plan_deletion_impact(manifest, cache_hash) print(plan.to_json())对应源码中的DeletionArtifact数据类见 openmed/risk/deletion_plan.py各字段语义如下字段类型默认值说明artifact_hashstr必填工件引用见下文引用规范化kindstrartifact安全标签如cache、map、evidence须匹配^[a-z0-9][a-z0-9_.-]{0,63}$retention_classstrunspecified保留类别如short、standard、audit同样须为短小写标签dependencies序列()指向该工件所需的其他工件哈希ownedboolTrue所有权标记必须是真正的布尔值引用规范化不透明引用在边界处被哈希化artifact_hash的规范化逻辑位于_canonical_hash见 openmed/risk/deletion_plan.py遵循以下规则已存在的SHA-256sha256:...与HMAC-SHA-256hmac-sha256:...摘要会被原样保留并转换为规范小写形式裸的 64 位十六进制字符串会自动补上sha256:前缀其他任何不透明本地引用例如应用内部的短标识符会被立即替换为hash_text计算出的 SHA-256 摘要——hash_text定义在 openmed/core/audit.py。这样既保证了链接之间可以确定性匹配又防止调用方不小心把路径或 PHI 放进计划对象如果引用带有sha256/hmac-sha256前缀但内容不是合法摘要则直接拒绝。字段别名为兼容不同来源的清单_parse_artifact见 openmed/risk/deletion_plan.py接受一组字段别名规范字段可接受别名artifact_hashhash、digest、artifact_digestkindartifact_type、type、categoryretention_classretentiondependenciesdependency_links、depends_on、linksownedis_owned注意若同一条目中同时出现多个同义字段如同时写artifact_hash和hash会被判定为歧义别名并拒绝防止解析结果不确定。三、反向依赖追踪影响闭包是如何计算的dependencies表示从一个条目指向它所需要的工件。规划器会反向且传递地追踪这些链接以上面的 manifest 为例map依赖cache因此删除cache时报告会同时把cache和依赖它的map都标记为受影响。核心计算逻辑位于_plan_deletion_impact见 openmed/risk/deletion_plan.py规范化 manifest 与目标集合并校验每个删除目标都必须存在于清单中构建反向索引dependents对每个条目把它的哈希加入其每个依赖的依赖者集合从目标集合出发做 BFS不断把依赖受影响工件的条目加入受影响集合直到闭包稳定计算各类安全计数器目标数、受影响数、拥有/未拥有计数、被阻塞目标数、未解析依赖数、依赖边数。确定性体现在多个层面条目按artifact_hash排序、依赖去重后排序、目标集合去重后排序因此即使清单中条目的书写顺序不同输出的计划与报告也完全一致。测试test_plan_follows_reverse_dependencies_and_is_deterministic验证了这一点——它把清单顺序反转后再次规划断言两份to_json()输出相同且affected_count 3见 tests/unit/risk/test_deletion_plan.py。# 简化的影响闭包示例对应上述测试 plan plan_deletion_impact(manifest, cache_hash) assert plan.target_count 1 # 显式请求删除的工件数 assert plan.affected_count 3 # 受影响闭包cache map evidence assert plan.counts_by_kind {cache: 1, map: 1, evidence: 1}四、安全的 Dry-run 输出只有计数与摘要规划永远是 dry-run。DeletionImpactPlan提供三个序列化方法to_dict()、to_json()、to_markdown()。它们包含按 kind 和 retention class 分组的计数完整性摘要manifest_digest、plan_digest安全计数器。它们绝不包含源路径、原始标识符、未知清单字段或单个资源的值。summary属性见 openmed/risk/deletion_plan.py的完整字段如下字段含义schema_version当前为1dry_run恒为Truemanifest_digest整个清单的规范 JSON 的 SHA-256stable_hash见 openmed/core/audit.pyplan_digest由 schema 版本 manifest 摘要 目标集合派生的摘要target_count显式请求删除的工件数affected_count受影响闭包中的工件总数owned_affected_count/unowned_affected_count受影响工件中由本方拥有 / 非本方拥有的数量blocked_target_count被阻塞的目标数目标本身非本方拥有unresolved_dependency_count指向清单外工件的未解析依赖链接数dependency_edge_count受影响闭包内的依赖边总数affected_by_kind/affected_by_retention_class分组计数confirmation_required恒为Trueraw_values_included恒为False机器可读的隐私保证to_markdown()会渲染成包含上述指标表格、按 kind 与保留类别分组列表、以及两个摘要的 Markdown 报告并明确声明This is a non-destructive dry-run; no artifact was deleted.见 openmed/risk/deletion_plan.py。计划对象可以向注入的本地执行器提供规范哈希引用target_hashes、affected_hashes属性但这些引用不会被报告序列化器输出——报告层面做到绝对只计数、不泄露。五、有界处理固定上限与失败关闭为了防止恶意或异常输入造成资源耗尽模块为所有输入路径设置了固定上限常量定义见 openmed/risk/deletion_plan.py维度上限本地清单文件大小16 MiBmanifest 条目数100,000单条目依赖数4,096总依赖链接数1,000,000删除目标数100,000单个引用字符数4,096单条目字段数32配套的严格校验包括JSON 文件通过object_pairs_hook拒绝重复对象字段通过parse_constant/parse_float拒绝NaN、Infinity等非有限数字见_json_object、_reject_json_constant、_parse_json_floatopenmed/risk/deletion_plan.py。测试覆盖了重复字段、NaN、1e999溢出三种情况tests/unit/risk/test_deletion_plan.py内存中的 manifest拒绝歧义别名与非字符串字段名循环、无限或敌意自定义容器统一以封闭的DeletionPlanError失败——错误消息不含输入值也不含容器自身抛出的异常消息。测试用_ExplodingMapping这类一读就抛异常的容器验证了该行为tests/unit/risk/test_deletion_plan.py。load_deletion_manifest是刻意设计的仅本地加载器读取错误与格式错误都使用不含内容的异常消息避免敏感路径或文档通过错误信息外泄openmed/risk/deletion_plan.py。此外plan_deletion_impact强制dry_runTrue传入dry_runFalse会被直接拒绝对应测试test_non_dry_run_is_not_accepted。六、显式执行边界确认令牌 注入回调规划器永远不会执行删除。如果应用有自己的本地删除实现必须注入该回调并提供经审阅计划的精确确认令牌from openmed.risk.deletion_plan import execute_deletion_plan def delete_owned_artifact(artifact): # Resolve artifact.artifact_hash through the applications local registry. # Do not pass raw paths or data into the plan or its reports. ... result execute_deletion_plan( plan, confirmationplan.confirmation_token, executordelete_owned_artifact, )执行边界由 execute_deletion_plan 强制实施包含以下机制确认令牌plan.confirmation_token的格式为confirm:{plan_digest}openmed/risk/deletion_plan.py。执行时通过hmac.compare_digest做常数时间比较缺失或错误的令牌都会抛出ConfirmationRequiredError且在令牌验证通过前不会调用任何回调。测试test_execution_requires_exact_confirmation_before_callback验证了不传令牌 / 传错误令牌两种情况下回调列表始终为空tests/unit/risk/test_deletion_plan.py注入回调executor别名delete_fn是唯一被调用的可执行对象二选一不能同时提供。回调接收的只有规范化后的DeletionArtifact不接收任何原始路径或数据稳定顺序目标回调按规范哈希升序stable hash order执行保证行为可复现不自动级联依赖者虽然出现在影响预演中但不会被自动删除——调用方必须自行决定如何处理受影响的依赖工件失败关闭只要unowned_affected_count或unresolved_dependency_count任一非零执行就会拒绝包括目标由本方拥有、但其依赖者非本方拥有的情形。测试test_unowned_dependents_block_execution_and_plan_forgery还验证了即使有人用object.__setattr__篡改计划对象中的计数执行前的重新校验依然会拦截tests/unit/risk/test_deletion_plan.py执行前重新校验在调用第一个回调之前会重新校验 manifest 摘要、plan 摘要、目标集与影响集、计数以及所有权状态见_validate_plan与执行函数的开头逻辑。任何不一致都会导致执行被拒绝回调失败不泄露回调抛出的任何异常都会被包装为不含原始消息的DeletionExecutionError。测试test_callback_failures_are_content_free用抛出自定义敏感消息的回调验证了这一点tests/unit/risk/test_deletion_plan.py。执行成功返回DeletionExecutionResult其to_dict()只包含plan_digest、requested_count、deleted_count、failed_count派生属性、dry_runFalse、executedTrue和raw_values_includedFalse——同样是计数优先、绝不携带原始值的结构openmed/risk/deletion_plan.py。七、责任边界规划器不承担的部分由于规划器不做真实删除以下责任始终在调用方保留策略retention class 只是清单中的标签规划器不强制执行任何保留期法律保留legal holds影响预演不能代替合规判断可能仍有副本存在于备份、日志或第三方系统中访问控制execute_deletion_plan的调用方必须自行确保只有授权流程能拿到确认令牌备份删除前是否需要快照由调用方决定人工复核文档明确要求删除前进行 human review。同时该模块没有网络依赖也没有强制外呼。测试时请使用合成的离线 fixtures如测试中_digest(synthetic-cache)这类无敏感含义的摘要并且永远不要把受保护的健康信息PHI、凭据或原始路径放入 manifest 或报告中。八、快速接入清单把上文内容落成一个可执行的最小流程from openmed.risk import plan_deletion_impact, execute_deletion_plan # 1. 准备清单可来自内存映射、条目序列或本地 JSON 路径 # 2. 规划永远是非破坏性 dry-run plan plan_deletion_impact(path/to/deletion_manifest.json, sha256: 0 * 64) # 3. 人工审阅报告只包含计数与摘要不含任何原始值 print(plan.to_markdown()) # 4. 若安全计数器全为零注入本地删除回调并显式确认后执行 if plan.blocked_target_count 0 and plan.unresolved_dependency_count 0: result execute_deletion_plan( plan, confirmationplan.confirmation_token, executordelete_owned_artifact, # 应用自身的删除实现 )相关源码与测试可直接在仓库中继续深入模块实现、risk 包导出、单元测试、哈希与摘要工具。核心 API 均通过openmed.risk包对外导出包括DeletionArtifact、DeletionImpactPlan、DeletionExecutionResult、plan_deletion_impact、execute_deletion_plan、load_deletion_manifest以及DeletionPlanError/ConfirmationRequiredError/DeletionExecutionError三类异常。【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMed 删除影响规划：基于本地清单的非破坏性删除预演与显式执行边界
OpenMed 删除影响规划基于本地清单的非破坏性删除预演与显式执行边界【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed导读openmed.risk.deletion_plan是 OpenMed 提供的一个本地、非破坏性的删除影响规划模块在调用方真正移除某个 OpenMed 管理的缓存cache、映射map或证据evidence工件之前它先根据一份本地清单计算删除后会波及哪些工件并输出仅含计数与完整性摘要的安全报告。读完本文你将掌握删除影响清单manifest的编写规范、反向依赖追踪的工作原理、plan_deletion_impact与execute_deletion_plan的完整用法以及该模块在隐私保护上的边界设计——它只做规划从不替调用方执行删除。需要特别强调的是该模块是规划辅助工具不是合规认证也不保证数据的所有副本都能被发现删除策略、法律保留、备份与人工复核的责任始终在调用方。一、设计定位预演在先删除在后OpenMed 是一款本地优先local-first的医疗 AI 框架其 risk 子包 聚焦再识别风险、审计与隐私治理。deletion_plan模块解决的是一个非常具体的运维问题当应用需要清理自己维护的缓存、映射或证据工件时如何在不触碰真实数据的前提下先看清删除的连锁反应。模块文档字符串见 openmed/risk/deletion_plan.py明确给出三条设计原则确定性规划是确定性的相同输入永远产生相同计划与报告非破坏性规划永远是 dry-run实际删除被显式委托给注入的回调函数隐私安全公开序列化只包含计数与完整性摘要原始标识符、路径和清单字段永远不会被复制进报告。从源码结构看模块本身不执行任何网络或文件系统操作除非调用方显式传入一个本地 JSON 清单路径这一点由单元测试test_planning_works_when_outbound_sockets_are_blocked专门验证即使把socket.socket.connect替换为直接抛错规划过程依然能正常完成见 tests/unit/risk/test_deletion_plan.py。二、Manifest 形状三种输入方式与条目字段plan_deletion_impact的第一个参数manifest支持三种输入形式源码中定义为ManifestInput类型别名见 openmed/risk/deletion_plan.py一个包含artifacts列表的映射Mapping一个条目序列Sequence一个指向本地 JSON 文件的str或Path。每个条目包含工件哈希、安全的 kind、保留类别retention class、可选的依赖链接和所有权标记。下面是文档中的完整示例from openmed.risk.deletion_plan import plan_deletion_impact cache_hash sha256: 0 * 64 map_hash sha256: 1 * 64 manifest { artifacts: [ { artifact_hash: cache_hash, kind: cache, retention_class: short, dependencies: [], owned: True, }, { artifact_hash: map_hash, kind: map, retention_class: standard, dependencies: [cache_hash], owned: True, }, ] } plan plan_deletion_impact(manifest, cache_hash) print(plan.to_json())对应源码中的DeletionArtifact数据类见 openmed/risk/deletion_plan.py各字段语义如下字段类型默认值说明artifact_hashstr必填工件引用见下文引用规范化kindstrartifact安全标签如cache、map、evidence须匹配^[a-z0-9][a-z0-9_.-]{0,63}$retention_classstrunspecified保留类别如short、standard、audit同样须为短小写标签dependencies序列()指向该工件所需的其他工件哈希ownedboolTrue所有权标记必须是真正的布尔值引用规范化不透明引用在边界处被哈希化artifact_hash的规范化逻辑位于_canonical_hash见 openmed/risk/deletion_plan.py遵循以下规则已存在的SHA-256sha256:...与HMAC-SHA-256hmac-sha256:...摘要会被原样保留并转换为规范小写形式裸的 64 位十六进制字符串会自动补上sha256:前缀其他任何不透明本地引用例如应用内部的短标识符会被立即替换为hash_text计算出的 SHA-256 摘要——hash_text定义在 openmed/core/audit.py。这样既保证了链接之间可以确定性匹配又防止调用方不小心把路径或 PHI 放进计划对象如果引用带有sha256/hmac-sha256前缀但内容不是合法摘要则直接拒绝。字段别名为兼容不同来源的清单_parse_artifact见 openmed/risk/deletion_plan.py接受一组字段别名规范字段可接受别名artifact_hashhash、digest、artifact_digestkindartifact_type、type、categoryretention_classretentiondependenciesdependency_links、depends_on、linksownedis_owned注意若同一条目中同时出现多个同义字段如同时写artifact_hash和hash会被判定为歧义别名并拒绝防止解析结果不确定。三、反向依赖追踪影响闭包是如何计算的dependencies表示从一个条目指向它所需要的工件。规划器会反向且传递地追踪这些链接以上面的 manifest 为例map依赖cache因此删除cache时报告会同时把cache和依赖它的map都标记为受影响。核心计算逻辑位于_plan_deletion_impact见 openmed/risk/deletion_plan.py规范化 manifest 与目标集合并校验每个删除目标都必须存在于清单中构建反向索引dependents对每个条目把它的哈希加入其每个依赖的依赖者集合从目标集合出发做 BFS不断把依赖受影响工件的条目加入受影响集合直到闭包稳定计算各类安全计数器目标数、受影响数、拥有/未拥有计数、被阻塞目标数、未解析依赖数、依赖边数。确定性体现在多个层面条目按artifact_hash排序、依赖去重后排序、目标集合去重后排序因此即使清单中条目的书写顺序不同输出的计划与报告也完全一致。测试test_plan_follows_reverse_dependencies_and_is_deterministic验证了这一点——它把清单顺序反转后再次规划断言两份to_json()输出相同且affected_count 3见 tests/unit/risk/test_deletion_plan.py。# 简化的影响闭包示例对应上述测试 plan plan_deletion_impact(manifest, cache_hash) assert plan.target_count 1 # 显式请求删除的工件数 assert plan.affected_count 3 # 受影响闭包cache map evidence assert plan.counts_by_kind {cache: 1, map: 1, evidence: 1}四、安全的 Dry-run 输出只有计数与摘要规划永远是 dry-run。DeletionImpactPlan提供三个序列化方法to_dict()、to_json()、to_markdown()。它们包含按 kind 和 retention class 分组的计数完整性摘要manifest_digest、plan_digest安全计数器。它们绝不包含源路径、原始标识符、未知清单字段或单个资源的值。summary属性见 openmed/risk/deletion_plan.py的完整字段如下字段含义schema_version当前为1dry_run恒为Truemanifest_digest整个清单的规范 JSON 的 SHA-256stable_hash见 openmed/core/audit.pyplan_digest由 schema 版本 manifest 摘要 目标集合派生的摘要target_count显式请求删除的工件数affected_count受影响闭包中的工件总数owned_affected_count/unowned_affected_count受影响工件中由本方拥有 / 非本方拥有的数量blocked_target_count被阻塞的目标数目标本身非本方拥有unresolved_dependency_count指向清单外工件的未解析依赖链接数dependency_edge_count受影响闭包内的依赖边总数affected_by_kind/affected_by_retention_class分组计数confirmation_required恒为Trueraw_values_included恒为False机器可读的隐私保证to_markdown()会渲染成包含上述指标表格、按 kind 与保留类别分组列表、以及两个摘要的 Markdown 报告并明确声明This is a non-destructive dry-run; no artifact was deleted.见 openmed/risk/deletion_plan.py。计划对象可以向注入的本地执行器提供规范哈希引用target_hashes、affected_hashes属性但这些引用不会被报告序列化器输出——报告层面做到绝对只计数、不泄露。五、有界处理固定上限与失败关闭为了防止恶意或异常输入造成资源耗尽模块为所有输入路径设置了固定上限常量定义见 openmed/risk/deletion_plan.py维度上限本地清单文件大小16 MiBmanifest 条目数100,000单条目依赖数4,096总依赖链接数1,000,000删除目标数100,000单个引用字符数4,096单条目字段数32配套的严格校验包括JSON 文件通过object_pairs_hook拒绝重复对象字段通过parse_constant/parse_float拒绝NaN、Infinity等非有限数字见_json_object、_reject_json_constant、_parse_json_floatopenmed/risk/deletion_plan.py。测试覆盖了重复字段、NaN、1e999溢出三种情况tests/unit/risk/test_deletion_plan.py内存中的 manifest拒绝歧义别名与非字符串字段名循环、无限或敌意自定义容器统一以封闭的DeletionPlanError失败——错误消息不含输入值也不含容器自身抛出的异常消息。测试用_ExplodingMapping这类一读就抛异常的容器验证了该行为tests/unit/risk/test_deletion_plan.py。load_deletion_manifest是刻意设计的仅本地加载器读取错误与格式错误都使用不含内容的异常消息避免敏感路径或文档通过错误信息外泄openmed/risk/deletion_plan.py。此外plan_deletion_impact强制dry_runTrue传入dry_runFalse会被直接拒绝对应测试test_non_dry_run_is_not_accepted。六、显式执行边界确认令牌 注入回调规划器永远不会执行删除。如果应用有自己的本地删除实现必须注入该回调并提供经审阅计划的精确确认令牌from openmed.risk.deletion_plan import execute_deletion_plan def delete_owned_artifact(artifact): # Resolve artifact.artifact_hash through the applications local registry. # Do not pass raw paths or data into the plan or its reports. ... result execute_deletion_plan( plan, confirmationplan.confirmation_token, executordelete_owned_artifact, )执行边界由 execute_deletion_plan 强制实施包含以下机制确认令牌plan.confirmation_token的格式为confirm:{plan_digest}openmed/risk/deletion_plan.py。执行时通过hmac.compare_digest做常数时间比较缺失或错误的令牌都会抛出ConfirmationRequiredError且在令牌验证通过前不会调用任何回调。测试test_execution_requires_exact_confirmation_before_callback验证了不传令牌 / 传错误令牌两种情况下回调列表始终为空tests/unit/risk/test_deletion_plan.py注入回调executor别名delete_fn是唯一被调用的可执行对象二选一不能同时提供。回调接收的只有规范化后的DeletionArtifact不接收任何原始路径或数据稳定顺序目标回调按规范哈希升序stable hash order执行保证行为可复现不自动级联依赖者虽然出现在影响预演中但不会被自动删除——调用方必须自行决定如何处理受影响的依赖工件失败关闭只要unowned_affected_count或unresolved_dependency_count任一非零执行就会拒绝包括目标由本方拥有、但其依赖者非本方拥有的情形。测试test_unowned_dependents_block_execution_and_plan_forgery还验证了即使有人用object.__setattr__篡改计划对象中的计数执行前的重新校验依然会拦截tests/unit/risk/test_deletion_plan.py执行前重新校验在调用第一个回调之前会重新校验 manifest 摘要、plan 摘要、目标集与影响集、计数以及所有权状态见_validate_plan与执行函数的开头逻辑。任何不一致都会导致执行被拒绝回调失败不泄露回调抛出的任何异常都会被包装为不含原始消息的DeletionExecutionError。测试test_callback_failures_are_content_free用抛出自定义敏感消息的回调验证了这一点tests/unit/risk/test_deletion_plan.py。执行成功返回DeletionExecutionResult其to_dict()只包含plan_digest、requested_count、deleted_count、failed_count派生属性、dry_runFalse、executedTrue和raw_values_includedFalse——同样是计数优先、绝不携带原始值的结构openmed/risk/deletion_plan.py。七、责任边界规划器不承担的部分由于规划器不做真实删除以下责任始终在调用方保留策略retention class 只是清单中的标签规划器不强制执行任何保留期法律保留legal holds影响预演不能代替合规判断可能仍有副本存在于备份、日志或第三方系统中访问控制execute_deletion_plan的调用方必须自行确保只有授权流程能拿到确认令牌备份删除前是否需要快照由调用方决定人工复核文档明确要求删除前进行 human review。同时该模块没有网络依赖也没有强制外呼。测试时请使用合成的离线 fixtures如测试中_digest(synthetic-cache)这类无敏感含义的摘要并且永远不要把受保护的健康信息PHI、凭据或原始路径放入 manifest 或报告中。八、快速接入清单把上文内容落成一个可执行的最小流程from openmed.risk import plan_deletion_impact, execute_deletion_plan # 1. 准备清单可来自内存映射、条目序列或本地 JSON 路径 # 2. 规划永远是非破坏性 dry-run plan plan_deletion_impact(path/to/deletion_manifest.json, sha256: 0 * 64) # 3. 人工审阅报告只包含计数与摘要不含任何原始值 print(plan.to_markdown()) # 4. 若安全计数器全为零注入本地删除回调并显式确认后执行 if plan.blocked_target_count 0 and plan.unresolved_dependency_count 0: result execute_deletion_plan( plan, confirmationplan.confirmation_token, executordelete_owned_artifact, # 应用自身的删除实现 )相关源码与测试可直接在仓库中继续深入模块实现、risk 包导出、单元测试、哈希与摘要工具。核心 API 均通过openmed.risk包对外导出包括DeletionArtifact、DeletionImpactPlan、DeletionExecutionResult、plan_deletion_impact、execute_deletion_plan、load_deletion_manifest以及DeletionPlanError/ConfirmationRequiredError/DeletionExecutionError三类异常。【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考