Manual entries and wearable observations can disagree without either being a software bug. A user might correct their weight, log an activity that a watch missed or choose a different source for a daily value. The product needs an explicit precedence rule instead of silently allowing the last write to win.
The contract to define first
Keep the source observation and user adjustment distinct. Define which value is used for display, calculations and exports, and provide a way to undo an override. A later wearable synchronization should not overwrite a deliberate correction unless that is the clearly communicated product contract. Record the applicable rule so derived results can be explained.
A worked scenario
A synthetic user corrects a daily value after an incomplete device sync. The next import brings the original observation again. A stable override should survive that replay, while the underlying source record remains available for reconciliation and audit.
An implementation and review sequence
- Separate source observations from user overrides
- Define precedence independently for display and calculation
- Offer an explicit reset-to-source action
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| The same source record is reimported | A deliberate override is preserved |
| User clears the override | The documented source policy resumes |
| An export includes adjusted values | Their origin is identified |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Unlimited overrides can make cross-device comparisons hard to interpret. Constrain editing where necessary and show when a value is user-entered rather than implying device verification.
Use the result to make a decision
The practical output is straightforward: specify precedence correction and user-visible audit history. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Wearable integration starts with permissions and data ownership.
Health Connect duplicate records
Health data provenance architecture
References and current platform requirements
Android: synchronize Health Connect data
Platform capabilities, programme terms and access conditions can change. Check the linked primary references against the version and account you actually use; the patterns above do not establish a provider approval, certification or universal compatibility guarantee.
Discuss the workflow
Bring the supported devices, required metrics, and your current sync failure examples.
Explore the relevant AptixLabs service
Should a wearable import overwrite a manual correction?
Manual entries and wearable observations can disagree without either being a software bug. Unlimited overrides can make cross-device comparisons hard to interpret.
Which failure cases should be included in the review?
Include these explicit cases: The same source record is reimported: a deliberate override is preserved; User clears the override: the documented source policy resumes; An export includes adjusted values: their origin is identified.