Causal Continuity as a Criterion for Attributing Accumulated Expe-rience in Continually Learning Computational Systems

Problem. A persistent checkpoint, a durable activity log, or a large runtime event count does not by itself establish that the recorded events form the accumulated experience of a single continually learning system. In a multi-process runtime, events may originate from local snapshots, state branches may diverge, and an architecture may be replaced without verified state transfer. Relevance. Without explicit state lineage, activity counts and system uptime can overstate how much recorded experience actually shaped the current authoritative state. This makes subsequent claims about learning, memory, or adaptation difficult to substantiate. Method and data. This study compares two runtime configurations of one experimental continual-learning project, selected because they bracket a shift from competing state copies to centralized checkpoint ownership. The analysis draws on source-code snapshots, checkpoints, experience and event records, and internal technical audits. The early audit recorded 3,343 experience entries; a later cumulative experience-log snapshot contained 6,795. These are records of activity, not statistically independent observations. Findings. In the early configuration, the audit identified mechanisms and state discontinuities consistent with competing in-memory copies and potential overwrites or lost updates. The retained telemetry was insufficient to reconstruct a unique state lineage. In the later configuration, a single consumer process became the canonical checkpoint writer, but auxiliary runners continued to generate events from locally loaded snapshots. The event queue and experience log lacked the source-state, application-parent, committed-descendant, branch, and merge identifiers needed to calculate the number of causally attributable experiences. Contribution. The paper proposes causal continuity as an operational criterion for attribution and specifies a minimal state-lineage audit protocol. Experience is attributed to the current authoritative state only when its generation and application provenance, together with the resulting committed transition, can be traced into that state. Where branches are merged or architectures changed, an explicit, auditable merge or transfer procedure must preserve the relevant lineage. The criterion supports strong claims about accumulated experience but does not, by itself, demonstrate functional learning.