一、先判断共享账本是否适合业务
NIST《区块链技术概述》将区块链描述为分布式实现、能够显露篡改并抵抗篡改的数字账本，正常运行条件下，已发布的交易记录不能被随意改变。政务应用可以据此评估多方共享记录的需求，但不能仅凭这一特性判断建设效果。
适用性判断应从业务出发：哪些部门需要共同核对记录，记录变化需要如何追溯，各方是否有明确的共享权限。如果主要需求只是单一机构保存和查询材料，应先比较现有数据库与数字签名能否满足要求。
二、区分记录完整性与内容真实性
材料提交后能否发现改动，与材料在提交时是否真实，是两个不同问题。即使记录被完整保存，错误录入、失实申报等问题仍需通过业务审核处理。
因此，应明确材料由谁提供、谁负责审核、出现错误后如何更正。涉及纠错时，可在设计中保留原记录与后续更正的关联，并让办理人员能够识别当前有效信息，避免把历史记录直接当作现行依据。
三、把隐私边界落实到数据设计
共享记录之前，应确定每项信息的使用目的、可访问主体和必要范围。身份证明、资格信息等材料，不宜仅因技术上能够共享就向所有参与方开放。
设计时可评估将业务原文保存在受控系统中，仅共享必要的核验信息。即使使用摘要或标识符，也应检查其能否与其他数据关联到个人；可追溯性越强，越需要审视跨业务关联带来的隐私影响。
四、凭证验证必须结合业务规则
W3C《可验证凭证数据模型2.0》区分签发者、持有者和验证者，并明确可验证不等于声明内容必然真实。其数据登记设施可以采用可信数据库或分布式账本，因此电子凭证并不必然要求使用区块链。
在政务核验中，应分别检查签发主体是否被认可、证明是否有效、凭证是否仍适用，以及内容是否满足办理条件。凭证验签成功，只能完成其中一部分核验，不能直接替代审批判断。
五、常见问题与运行责任
上链后是否就能自动审批？只有业务条件明确、输入信息经过必要核验、例外情况有处理路径时，才适合讨论自动化。技术记录本身不能决定行政业务规则。
多个部门共同使用是否意味着责任自然明确？仍需约定信息维护、访问授权、纠错和争议处理的责任。上线前还应考虑凭证失效、权限变更和系统不可用时如何继续受理，避免技术环节阻断正常服务。