Derived records become stale when their underlying observations change. In Ovulab, cycle synchronization treats tracker-generated history as a projection of the current logs.
This article discusses data reconciliation in the application. It does not interpret health observations or provide medical guidance.
Make derivation repeatable#
The pure helper filters recorded flow values, orders entries by date, and groups nearby observations. A group needs a qualifying flow value before it becomes a derived cycle record.
Running that helper again after an edit produces the current set of starts. It avoids making the stored derived history the sole authority for what the observations now imply.
Upsert the current projection#
Synchronization loads observations and existing tracker records, computes the new projection, and upserts using user, start date, and source as the record key.
Those fields define identity for this derived record. The source marker also distinguishes it from history that a person entered manually.
Remove stale derived records#
An upsert alone cannot remove a record whose start date no longer appears after an edit. The synchronization process compares existing tracker records with the newly computed starts and deletes stale tracker identifiers.
For example, changing the earliest observation can move a group's derived start. The new start needs an upsert, while the previous start needs removal. Without cleanup, both could remain visible as separate history.
Manual records are excluded from the tracker-record removal query. The cleanup is scoped to data the application derived and can recompute.
Keep interpretation separate#
This process improves consistency between logs and generated history. It does not establish that a derived cycle or prediction is clinically correct. Provenance helps explain why a record exists; clinical validation would require different evidence beyond the synchronization code.