来源数据模型：描述产品、过程与责任主体
产品溯源首先需要表达对象之间的关系。W3C的PROV-O以实体、活动和代理主体等概念描述来源信息，支持不同系统交换与整合这些信息，并允许面向具体领域扩展。
应用到产品溯源时，可以把原料批次和成品批次建模为实体，把加工过程建模为活动，把相关企业建模为责任主体。这是一种建模示例；实际系统仍须明确批次如何对应、活动使用了什么、产出了什么，以及由谁负责。
智能合约：把业务规则变成程序
以太坊开发者文档将智能合约解释为运行在区块链上的代码与状态，用户通过交易调用其功能。合约可按预设规则执行，也可以与其他合约交互。
在溯源设计中，可以用合约表达记录提交权限或状态变更条件。例如，只有满足指定条件才能提交某类记录。适用前提是规则足够明确，能够转化为可检验的程序条件；现实中的模糊争议仍需另外处理。
链外信息与预言机：连接现实事件
该文档还说明，智能合约无法自行获取链外事件，预言机用于把外部信息提供给合约。因此，生产、运输等现实环节的信息需要经过外部输入机制才能被链上程序使用。
这里应区分两个问题：程序是否按输入执行，输入是否符合现实。即使合约正确处理了一条加工记录，也不能据此认定加工确实发生。溯源方案需要说明信息由谁提供、如何核验，以及发生错误时如何处理。
权限与协作：明确谁能提交和确认
产品溯源可能涉及多个参与方，需要分别定义提交、确认和变更权限。多签机制要求多个有效签名共同满足执行条件，可用于需要共同确认的操作。
例如，某类关键记录可以设计为由多方共同确认后再进入下一状态。但签名数量增加并不直接证明记录真实，各参与方的身份、职责和核验依据仍应明确。
适用条件与常见问题
跨系统溯源尤其需要统一标识和字段含义。若各方对同一批次或同一活动的理解不同，即使能够交换记录，也难以准确还原来源关系。PROV-O提供的是来源信息表达框架，采用它本身不要求使用区块链。
智能合约也不等于完整的溯源系统。数据模型负责表达关系，合约负责执行规则，外部接入负责提供现实信息。判断方案是否适用，需要看这些环节能否衔接，以及记录能否关联到明确的对象、活动和责任主体。