前面的讨论已经把数据工程化推进到了一个重要位置。我们不再把系统中的表、字段和记录直接等同于数据本身，而是重新回到业务活动，识别业务对象、业务事实以及对象之间的关系，并进一步讨论这些内容如何在数据世界中形成具有明确身份、语义和边界的数据对象。经过这一过程，原本依附于具体系统的数据开始获得相对稳定的业务含义：客户不再只是客户表中的一行，设备也不再只是资产系统中的一个编码，来自不同系统、不同时间和不同业务环节的记录，可以围绕同一个业务对象重新组织，并在相对一致的语义框架下被理解和使用。

这一步解决的主要是对象的表达问题。一个设备对象应当如何识别，它具有哪些属性，能够处于哪些状态，与站点、部件和组织之间存在什么关系；一个客户对象如何区分主体身份，如何描述客户属性和业务关系；这些问题一旦被定义清楚，数据便获得了一种相对稳定的结构。问题在于，现实业务并不会停留在这一结构之中。设备仍然会运行、告警、检修和迁移，客户仍然会不断产生新的交易和关系，合同仍然会履行、变更和终止。对象定义可以保持相对稳定，但对象在某一具体时点上的事实、关系和状态始终处于变化之中。

于是，一个对象被定义清楚以后，数据工程化必须继续回答一个新的问题：当业务世界不断发生变化时，已经建立起来的数据对象如何继续保持对现实业务的有效表达。这个问题意味着数据工程化开始由对象的结构进入对象的运行，也由数据对象定义进一步走向数据持续生产。

数据对象定义首先建立的是对象在数据世界中的合法表达空间。仍以设备为例，我们可以规定设备具有唯一身份，描述型号、规格、所属组织、安装位置等属性，与站点、部件和人员建立明确关系，并定义运行、停机、检修、故障等业务状态。完成这些定义以后，无论相关数据来自资产管理系统、生产系统还是运维系统，都可以被重新放回同一个设备对象之下理解。

但这种定义解决的是“设备可以怎样被表达”，而不是“某一台设备此时究竟是什么状态”。规定设备可以处于运行或故障状态，只是确定了两种合法的业务表达；它不能解释某台设备为什么会在上午九点四十分由运行转为故障。对象模型能够定义位置关系，却不能说明某一次迁移发生以后，旧的位置关系何时终止、新的位置关系从何时开始生效；能够定义设备与部件之间存在组成关系，却不能自动判断一次部件更换是否已经完成并具备业务效力。

对象定义与对象当前状态之间由此形成了一个清晰边界。前者规定对象能够以什么方式存在，后者则取决于现实业务中已经发生并被确认的事实。对象定义可以告诉我们哪些结果是合法的，却不能单独决定某个结果为什么在当前对象上成立。

这一差别在静态的数据建模过程中并不容易被察觉。面对已经加工完成的数据表时，我们看到的是“状态=故障”“位置=站点B”这样的最终结果，很容易把这些结果理解为业务系统直接提供的数据。但真实业务并不是如此。一台设备最终被认定为故障，往往经历了连续异常、系统告警、现场确认以及检修处置等多个环节；设备从站点A迁移到站点B，也不是简单修改一个位置字段，而是经过迁移申请、拆卸、重新安装和验收等一系列业务活动，最终才形成新的有效位置关系。

对象定义因此只能解决对象表达的规范性，而无法独立解决对象状态的形成问题。如果企业完成了对象模型建设，却没有进一步明确业务事实如何作用于对象，那么数据在结构上可以高度统一，具体对象状态却仍然可能依赖不同系统、不同团队甚至不同人员的临时判断。许多企业已经完成数据标准、主数据和模型建设，却仍然频繁发生口径确认、状态核对和人工修正，原因往往不在于对象“是什么”没有定义，而在于对象“为什么现在是这样”仍然缺乏稳定的形成机制。

数据工程化必须从这里继续向前。

现实业务的变化不会直接同步为数据对象的变化。设备真实发生故障，并不会因为现实中的设备停止运行，数据库中的设备状态就自然变成“故障”；设备完成迁移，也不会因为物理位置已经改变，所有数据系统中的位置关系就自动完成更新。业务活动首先留下的是记录，数据系统能够直接获得的也始终是这些记录以及它们所承载的事实。

一台设备从正常运行到故障，可能先后出现温度异常、振动异常、系统告警、人工检查和工单确认。数据系统看到的是传感器读数、告警消息、检查记录和工单状态。这些记录虽然都与同一台设备有关，却处在不同业务环节，表达不同层次的事实。一条高温记录只能说明某一时点发生了异常观测，告警记录说明系统根据既定条件识别到了风险，而现场检查则可能进一步确认设备确实存在故障。它们都与最终的设备状态有关，却不能简单地与“设备故障”画等号。

由此需要把三个层次区分开来。系统记录描述的是某个系统在某个时点记录了什么，它受系统功能、字段设计和业务流程影响；业务事实关注这些记录在业务语境中究竟说明了什么，例如某一观测是否构成异常、某一次检修是否已经完成；对象状态则是在已经确认的业务事实基础上，对对象在当前时点所处状况的综合表达。系统记录可以承载事实，事实可以影响对象状态，但三者之间并不是简单的一一映射。

这一区分直接改变了数据处理的逻辑。如果把系统记录直接等同于对象状态，数据工程就容易退化为字段复制：源系统出现一条告警，下游便立即把设备状态修改为故障；工单系统出现一次“完成”，设备就被自动恢复为正常；位置字段发生变化，旧的位置关系立即被新值覆盖。这样的处理方式在技术上并不复杂，却隐含了一个非常强的假设，即某一种记录已经足以唯一决定对象当前状态。

真实业务往往不满足这个假设。一次告警可能来自误报，一次工单关闭也不一定意味着设备恢复正常，新的位置记录如果缺少验收依据，也未必已经具备业务效力。数据系统能够获得的是关于对象的新事实，而不是已经完成解释的最终结论。对象状态需要在这些事实之上形成，而不是由某一条记录直接替代。

因此，当业务持续运行时，数据工程化真正面对的是一个不断变化的事实环境。新的事实持续进入，原有事实可能被补充、修正甚至失效，对象当前状态也需要随之重新判断。数据世界并不是对现实世界的自动镜像，而是建立在持续获得、确认和解释业务事实基础上的工程化表达。

如果把上述关系进一步抽象，数据持续生产的对象就会变得更加清晰。

任意一个业务对象在某一时点上的数据状态，都建立在此前已经获得并确认有效的一组业务事实之上。这些事实可能描述对象自身属性，也可能描述对象经历的事件、与其他对象建立的关系或者某些已经生效的状态变化。在对象定义和业务判断的共同约束下，这些事实形成对象在当前时点能够成立的数据表达。

这里的“状态”并不只是狭义的状态字段。对于设备对象而言，当前安装在哪个站点、由哪个组织负责运维、装配了哪些部件以及设备处于什么运行状态，这些在特定时点仍然有效的属性、关系和业务状态共同构成了对象的当前数据状态。数据对象因此不是一组彼此孤立的字段，而是对业务对象当前有效事实的一种组织结果。

新的事实出现以后，这种状态不一定立即改变。假设设备上午九点处于正常运行状态，九点十五分出现一次温度异常，从记录层面看，系统已经增加了一条数据，但对于设备对象而言，这条事实可能不足以改变当前状态。随后连续出现异常，九点二十五分触发告警，对象可能被判断为异常；九点四十分，现场人员完成检查并确认部件故障，新的事实与此前已有观测和告警共同构成更充分的判断依据，设备对象由此进入故障状态。

从九点到九点四十分，系统可能产生几十条乃至数百条记录，但对于数据工程化而言，关键并不在于记录数量增加了多少，而在于随着事实集合发生变化，我们对于设备对象当前状态的有效判断发生了怎样的变化。

这种变化也并不是简单的“旧状态加上一个新事实”。新的事实可能只是补充当前状态，也可能证明已有判断不再成立；它可能建立新的关系，也可能使旧关系失效；某些迟到但可信程度更高的事实甚至可能要求修正此前已经形成的历史状态。对象状态由此表现为一个在业务事实持续进入过程中不断被确认和更新的结果。

从这一意义上看，数据持续生产可以被理解为：在业务活动不断产生新事实的条件下，依据既定的数据对象定义和业务判断机制，持续形成并更新业务对象在特定时点上的有效数据状态。

这一概念与传统的数据采集、同步和转换存在明显区别。数据采集解决的是新的记录能否被获得，数据同步解决的是记录能否及时到达目标系统，数据转换关注的是数据能否按照既定规则从一种技术结构转变为另一种技术结构。数据持续生产则继续向前一步，它关心这些新的业务事实进入以后，如何改变企业对某个业务对象当前状态的认识。

因此，数据持续生产的基本工程关系并不是简单的“记录到记录”，而是“业务事实到对象状态”。传统数据处理可以为这一过程提供技术基础，但只有当事实能够稳定进入对象并形成具有明确业务含义的当前状态时，数据对象才真正开始运行起来。