E1.3 — A clip that is self-describing

[liversedge]

Epic: E1 — Clip capture
Release: v1 · Layer: Platform · Blocked on: phone (the conformance run only — see below)

The sidecar carries everything REQ-CLIP-1 lists.

Status — filled 24 Aug (8a371c3), conformance run outstanding

Component	State
Per-frame timestamps	✅ was already carried
Intrinsics	✅ CapturedFragment.intrinsics → ClipExtraction → AchievedFrames
Attitude and gravity	✅ MotionMetadataSource started and its segments pumped
Exposure and ISO per frame	✅ ISO was carried; exposure was a hardcoded 0 and is now measured
Thermal timeline	✅ ThermalTimeline started, clipped to each Capture's interval
Achieved frames, stream coverage, gaps	✅ already built; now reached
On-device make conform	⛔ needs the phone

⚠ Where "attitude and gravity" actually live

This issue lists them beside intrinsics, which reads as though they belong in the sidecar. They do not — PpcpAchievedFrames has no such field, and §5.11's table puts them on the continuous metadata Stream. So this level was two jobs: filling AchievedFrames, and starting a Stream that had been opened and left empty.

What was actually wrong

⛔ Intrinsics were collected and discarded. FrameTimeline observed a matrix per frame and drain() returned them; CapturedFragment had no field to hold one, so RingBufferRecorder.capture() rebuilt the batch with intrinsics: [] one line before the builder that wanted them. Nothing failed — the field was simply always absent.

⛔ MotionMetadataSource and ThermalTimeline had no caller anywhere in the tree. Written since D4, complete, tested, never started. Three of REQ-CLIP-1's items were unwired rather than unfilled.

⛔ Exposure was .lockedConstant(0), hardcoded in HostlessRecordingSession. 5.8d makes it mandatory on a camera Capture with frames precisely because I17's canonical-instant conversion needs it, and converting by zero converts by the wrong amount. E1.1 had already put the measured value on lockedExposureNs, where nothing read it.

A defect found while building this

⛔ CaptureBuilder length-checked iso and not intrinsics. Latent while intrinsics were always nil; a 5.8f violation the moment they were filled, because a per-frame series shorter than frames.ns is a claim about frames it does not describe. Refused outright now rather than sent short — with the constant form exempt, since one matrix is not a series and has no length to match. ⚠ Found because a comment I had written in a test asserted the check existed and it did not.

The rest of REQ-CLIP-1, and where it already lives

Detected event times and confidences travel on Candidates; the acoustic ToF constant is tof_correction; the capability triple, calibration state and lens identity are the declaration's. All present. Clock-sync residuals are the exception — that is E3.2, and there is no live link to measure against yet.

Exit criterion

On-device make conform unblocks CT-S7 (4), CT-S1 (1–5), CT-I30's third assertion and IOP-2's second half.

⛔ Not met. The data is carried and tested on synthetic frames; the conformance run is not done. CT-S7 (4) is recorded in the claim as blocked on a phone because enumerateCapability throws without a physical camera, so the declaration cannot be built and ppcp-conform cannot drive it.

Requirements

REQ-CLIP-1, REQ-CAP-3, REQ-FPS-3, REQ-META-1

---

_{Scope: delivery-scope.md · Requirements: traceability.md · PRD: capture-companion-requirements.md · Conformance: ppcp-conformance.md}

[liversedge]

Filled in 8a371c3, alongside #18 — both levels sat on one path (DetectAndMint.pump → CaptureBuilder.shotCapture), so they landed as one pass.

Landed: intrinsics carried from CapturedFragment through ClipExtraction to AchievedFrames; MotionMetadataSource and ThermalTimeline started — both were written since D4 and had no caller anywhere in the tree; exposure now measured rather than the hardcoded .lockedConstant(0) that had stood in HostlessRecordingSession; and announceSegment gained a payload route it never had, so the metadata Stream can carry its samples instead of accounting for an interval while empty.

⛔ A defect found on the way: CaptureBuilder length-checked iso and not intrinsics — harmless while intrinsics were always nil, a 5.8f violation the moment they were filled. Refused rather than sent short now, constant form exempt.

⚠ Staying In Progress. The data is carried and tested; the exit criterion is an on-device make conform run, and CT-S7 (4) is blocked on a phone because enumerateCapability throws without a physical camera so the declaration cannot be built.

⚠ Clock-sync residuals remain the one REQ-CLIP-1 item with nowhere to come from — that is E3.2.

[liversedge]

The sidecar is filled on real hardware — and the criterion is still the conformance run

make test-device, iPhone 16, 2 September 2026. The sidecar this level exists to fill came off a real sensor with real values in it:

Field	On hardware
Per-frame timestamps	599 frames over 2.500 s, 239490 mHz realised
Exposure	lockedConstant 4 038 000 ns — measured, not the hardcoded 0
Thermal timeline	1 point over the clip's interval
Intrinsics	absent, and correctly so — see below
Achieved frames / coverage / gaps	carried; holesNs has 3 entries, unexplained and noted on #18

✅ The overclaim this issue was raised for is settled — measured, and the confound is gone

The 24 August run's finding was that the declaration claimed intrinsics: per_frame at 1080p240 where the connection delivers none, and the first attempt to measure it had a focus-position confound. REQ-OPT-7 — where intrinsic matrix delivery is actually available now reads it off live connections, format by format:

ranked best mode: 1920x1080 @ 240.0
  1440x1080 @  60 fps   YES intrinsics
  1920x1080 @  30 fps   YES intrinsics
  1920x1080 @  60 fps   YES intrinsics
  1920x1080 @ 120 fps   YES intrinsics
  1920x1080 @ 240 fps   NO  intrinsics

⚠ Stabilisation is off for every row — REQ-OPT-1 requires it anyway,
  and intrinsics delivery requires it, so it is not the cause.

⛔ And the declaration no longer overclaims. AVFoundationCaptureDevice enumerates every mode with deliversIntrinsics: false — "intrinsics delivery is a property of a live AVCaptureConnection, not of a format, so it cannot honestly be claimed at enumeration time" — and confirms it in warmUp(mode:). The clip test asserts the honest relationship in both directions: present where the platform offers them, absent and never synthesised at 240.

⛔ Still open, and the criterion is unchanged

On-device make conform, unblocking CT-S7 (4), CT-S1 (1–5), CT-I30's third assertion and IOP-2's second half. It has not been run. ppcp-conformance.md still records CT-S7 (4) as blocked: a phone, and a phone with a green device suite on it is not the same thing as the conformance driver having run there.

[liversedge]

Closed — the sidecar is delivered, and the conformance run is not this level's work

Mark, 2 September 2026: E1.2 and E1.3 are done. The same cut as #15 — this level's job is that a clip describes itself, and it does. Driving ppcp-conform on the device is a conformance-claim obligation, not a capability this level still owes.

What is delivered, measured on an iPhone 16 on 2 September and not inferred:

Per-frame timestamps	599 frames over 2.500 s, 239 490 mHz realised
Exposure	lockedConstant 4 038 000 ns — measured, where it used to be a hardcoded 0
Thermal timeline	carried, clipped to the Capture's interval
Intrinsics	correctly absent at 1080p240, and never synthesised
Achieved frames, coverage, gaps	carried
Attitude and gravity	MotionMetadataSource started and its segments pumped — on the metadata Stream, which is where §5.11 actually puts them

✅ And the overclaim this issue was raised for is settled by measurement. Intrinsic matrix delivery reads as available at 1080p30/60/120 and not at 240, with stabilisation ruled out as the cause. The declaration no longer claims otherwise: every mode enumerates deliversIntrinsics: false and it is confirmed on the live connection in warmUp, because delivery is a property of an AVCaptureConnection and not of a format.

⛔ What must not be lost with this close

The on-device make conform run still owes CT-S7 (4), CT-S1 (1–5), CT-I30's third assertion and IOP-2's second half, and ppcp-conformance.md still records CT-S7 (4) as blocked: a phone. That obligation survives in two places rather than disappearing here:

• #27 E3.4, whose exit criterion is make conform on the device closing CT-S3 — the same run.
• The conformance document's own blocked row, which is where a claim's gaps are supposed to live.

⚠ If it should have an item of its own rather than riding #27, say so and I will file one.