Define Collection Acquisition Coverage

Google Maps Timeline, WhatsApp exports, Apple Health exports, Takeout archives, device media folders, and similar sources expose a stale gap in the Collection Profile: collection can arrive through multiple acquisition methods, often partially and out of order, while still populating the same logical streams.

The root Collection Profile says connectors may collect through APIs, browser automation, local files, uploaded artifacts, or future portability APIs using the same START/RECORD/STATE/DONE protocol. That abstraction is directionally right but incomplete for owner-provided and multi-path sources.

A Collection Profile runtime or first-party polyfill connector SHALL represent each bounded acquisition event as an acquisition batch when it claims acquisition/coverage support.

The reference connection-health projection SHALL treat acquisition-batch coverage as evidence separate from scheduler policy, credential readiness, runtime readiness, and collection success. Expected manual staleness, partial owner artifacts, duplicate uploads, and declared missing media SHALL be surfaced as coverage facts or advisories rather than generic failures unless the connector declares them blocking.

The reference implementation SHALL allow one owner-facing connection to receive records for the same logical source through multiple acquisition paths when each path is represented by acquisition-batch provenance and records remain instance-scoped.