ADR-001: Published Telemetry Is Dual-Source (Sidecar + Embedded Tracks)

Architecture Decision Record: every published phenom carries telemetry both as embedded SRT tracks inside the signed MP4 and as an uploaded sidecar JSON. SRT-only is deferred behind three hard gates. Adopted 2026-06-11.

Status

Adopted 2026-06-11. Ratified after a structured multi-perspective architecture review (software architecture, product, finance seats). Supersedes the implicit SRT-only decision embedded in build 80 commit 95caf74. May only be superseded by a new ADR after the three gates below pass.

Context

During the MOV to MP4 pipeline transition (build 75, commit 8724785), two regressions appeared and were fixed on separate branches that hard-conflict (3 blocks in PublishScreen.tsx) and encode opposite architectures:

  • PR #195 (feature/194-sidecar-forwarding): restores the sidecar upload that a path re-derivation bug had silently broken (issue #194). Telemetry ships twice: embedded and as .sidecar.json on S3.
  • PR #197 / build 80 (feature/196-mp4-telemetry-hud): fixes HUD playback (mp4 muxer drops the title tag; handler_name survives) but also deleted the sidecar upload entirely, making the embedded SRT tracks the only copy.

The SRT-only position has real merit: the sidecar is (today) unsigned and outside the C2PA envelope, so it can drift from the sealed telemetry without detection, which weakens the provenance story. The dual-source position counters with three facts on the ground: the Android postprocessor is a stub (no embedded tracks at all on one platform), the Share-with-HUD burn-in feature fetches the server-side sidecar, and social-platform re-encoding strips subtitle tracks, so the embedded copy alone does not survive the distribution channels that matter.

Decision

  1. Dual-source is canonical. Every published phenom uploads the .sidecar.json alongside the video. The embedded SRT tracks (readable + JSON) remain in every signed MP4.
  2. PR #195 merges first. PR #197 is rebased to keep its playback fix and restore the upload it deleted (#199).
  3. The sidecar gets a cryptographic tether: its SHA-256 is embedded as an assertion in the C2PA manifest at signing time (#200), converting the redundancy from “two copies that can drift” into “one sealed truth with a verifiable external projection”.
  4. SRT-only is deferred, not rejected. It becomes adoptable only when all three gates pass (#203):
    • Android postprocessor reaches iOS parity (mux, hash, sign);
    • burn-in reads embedded SRT directly and no longer needs the server file;
    • telemetry recovery after a subtitle-stripping re-encode is demonstrated (durable-credential soft binding or equivalent).
  5. Process guard: architecture changes may not ride inside bug-fix commits. PRs touching the telemetry pipeline, publish upload paths, or the C2PA envelope require a linked ADR (#204).

Consequences

  • GPS and sensor data return to published phenoms in build 81 (both fixes merged).
  • Storage cost of the second copy is negligible (≈0.3 MB sidecar vs ≈100 MB video, about $0.000012 per upload at S3 Standard rates).
  • The unsigned-sidecar weakness is acknowledged and closed by #200 rather than by deleting the file.
  • A named owner must verify the deprecation gates with evidence artifacts; advisory gates are explicitly rejected (they become permanent debt).
  • Build sequencing risk accepted: #200 (sidecar hash) and the container work share the signing path; if both cannot produce clean verification artifacts in the build 82 window, the later item slips one build rather than stacking unvalidated signing changes.

References