ADR-0007: Expire photo originals by default and keep automated results provisional
- Status: Accepted
- Date: 2026-09-19
- Scope: Meal-photo analysis, storage, and UX
Context
Meal photos may expose location, people, surroundings, routine, and other context beyond nutrition logging. Automated recognition can be incomplete or wrong. Keeping every original indefinitely and presenting estimates as facts would create avoidable privacy and wellness risk.
Decision
- Raw uploads use a versioned
quarantine/ key. The API validates the upload contract, applies
orientation, and re-encodes JPEG/PNG bytes without metadata before creating an immutable
processing/ object.
- The sanitized checksum and processing-object version are committed atomically with the job.
The API then deletes the exact raw quarantine version; completion replay retries that deletion.
One-day current/noncurrent lifecycle rules cover both prefixes as a crash fallback.
- Providers receive only the sanitized processing reference. A separate, explicit adult choice
copies that exact sanitized source version to a deterministic key
in an encrypted, non-public, non-versioned diary-retention bucket.
- The retained object creation time determines the database
retainedUntil deadline. The worker
deletes objects at or after that deadline and records cleanup idempotently.
- The diary-retention bucket expires current objects after 365 days as a fallback; it cannot preserve
noncurrent versions because versioning is not enabled.
- Longer retention is not preselected and is not required for ordinary analysis.
- Enforce metadata removal on both mobile and API boundaries; never retain or send the raw upload
to a provider. Do not place image bytes or URLs in routine logs.
- Library originals remain outside PlatePilot’s deletion ownership. Picker-returned cache files,
camera captures, sanitized copies, and generated crops are app-owned temporary files tracked for
cleanup on replacement, confirmed navigation/discard, and sign-out. Cleanup completes before
session tokens are removed.
- Cropping operates on the currently selected app URI and produces an app-owned centered crop;
choosing another library image and retaking with the camera remain separate, permission-gated
actions.
- Provider input is minimized and covered by reviewed retention/deletion terms.
- M1 validates uploaded bytes with Sharp and uses a deterministic synthetic face marker adapter
for local/test behavior. A reviewed production face-detection adapter is still pending and the
deterministic adapter is not evidence of production-grade face detection.
- Automated nutrition output is labeled provisional with source/provenance.
- The adult can review, edit, reject, or replace the result with manual entry.
- Provider failure does not block manual logging.
Consequences
- The worker is the primary retention enforcer; the synthesized lifecycle supplies a bounded
fallback if reconciliation is interrupted.
- A deleted original may leave an adult-confirmed text record where policy permits; the distinction must be explained.
- Short retention can reduce debugging evidence, so synthetic fixtures and structured non-sensitive telemetry are preferred.
- Estimates cannot be treated as authoritative for medical or billing decisions.
Follow-up
- Treat any future thumbnails as derived restricted data with the same or shorter local lifetime.
- Add access, metadata-stripping, and provider-deletion tests before a real provider is enabled.
- Validate retention and provisional-result copy in adult usability research.