Sometimes the research question finds you before you go looking for it.
There is a particular kind of frustration that comes from watching a system do something it apparently should not do, documenting it, and then discovering that the available explanations do not quite account for what you saw.
Now imagine doing that with two vendors.
I did not set out to write a cross-vendor academic case study. I was trying to understand what my devices and my vehicle were doing. The Apple inquiry began with Messages photo selection and image-handling observations; a separate investigation followed Jeep/Stellantis service and diagnostic records. Together they raised a more interesting question: what can we actually know about a system when the state we can see is only one representation of the state it maintains?
That question became Cross-Vendor State Observability: An Evidence-Bounded Case Study of Mobile and Automotive Systems.
And, yes, the journey from fault to paper involved more paperwork than I would have preferred.
The fault is not the explanation
A visible failure is useful evidence. It is not a mechanism.
On the Apple side, the record includes reported photo-selection behavior across Messages conversations, path-dependent image-handling observations, and a later explanatory companion describing a FrontBoard scene-creation watchdog termination. On the Jeep side, it includes display complaints, separate driver-assistance and electrical observations, service history, stored diagnostic-code descriptions, and a post-release chronology.
Those records are not interchangeable. A user-visible event, an operating-system diagnostic, a stored vehicle code, and a service disposition may describe different layers, different moments, or different interpretations of a system's behavior.
It is tempting to draw a line between two interesting events and call the line an explanation. That is exactly where an investigation can become less useful.
So I kept the histories separate and asked what each artifact could actually support.
The Apple reproduction has its own evidence trail
The August 28, 2025 screen recording preserves two Messages PhotoPicker/JPEG reproduction cases. G1 shows maroon rendering corruption, followed by an application crash during image selection. G2 shows green rendering corruption, followed by an application crash during the send operation. The recording documents the visible outcomes and their sequence; it does not identify an internal cause.
The broader Apple investigation also includes cross-conversation photo-picker observations, extreme-geometry JPEG experiments, and the original watermarking and image-transformation workflow used to examine representation fidelity. A separate iPhone restore/cache experiment records observed outcomes around restoration. These are observations and interventions within the Apple inquiry; they do not establish an Apple-to-Jeep causal relationship.
The part that kept bothering me
Modern systems do not have one universal, instantly synchronized notion of state.
An application has lifecycle state. An interface has session state. A display presents a representation of state. Diagnostics preserve yet another representation, sometimes after the conditions that produced it have changed. Each may be maintained by different components and updated on different schedules.
That creates a useful explanatory possibility: representations can diverge across a transition without every participant recognizing the transition at the same time.
A screen can remain stale while an underlying process has moved on. A diagnostic can describe a prior condition while the current user-visible behavior looks normal. A service test can fail to reproduce an intermittent observation without retroactively erasing the observation itself.
None of those examples, on its own, proves what happened in either vendor's implementation. They illustrate why state ownership, lifecycle boundaries, and representation fidelity are productive places to investigate.
The paper develops that model as an explanation worth testing, rather than presenting it as a recovered internal architecture.
Two vendors. One methodological problem.
The common thread is not a claim that Apple caused a Jeep fault, or that the two platforms share a defect.
The common thread is partial observability.
An external researcher can preserve videos, timestamps, diagnostic excerpts, service records, and vendor responses. That can establish a surprisingly detailed chronology. But chronology and causality are different deliverables.
The paper therefore separates observations, vendor statements, interpretations, and unresolved questions. It also specifies what stronger attribution would require: better synchronized captures, event-time diagnostic context, controlled comparison conditions, and evidence of an actual interface transition or data path where one is alleged.
The distinction matters. The explanatory model is technically meaningful without pretending that an unobserved cross-vendor propagation path has been demonstrated.
From frustration to a research method
Somewhere along the way, the working question changed.
It stopped being only, “Why is this thing doing that?”
It became, “Which state is being observed, who owns it, what transition should have occurred, and what evidence would distinguish competing explanations?”
That shift is what made the work portable. The individual complaints are specific; the method is not. The same discipline applies wherever interfaces, lifecycle transitions, cached representations, and diagnostic records make it difficult to determine which version of reality a system is currently presenting.
And it is why a negative or inconclusive result is not automatically wasted effort. An investigation can narrow a claim, identify a missing measurement, or establish the exact point where the available evidence stops. Those are useful outputs—especially when the next person can reproduce the reasoning without inheriting the original researcher's assumptions.
FIELD RECORD / SELECTED ARTIFACTS
Evidence in the record
The August 28 Apple Messages photo-picker reproduction; the September 16 dealership record and follow-up; the September 17 firmware photograph; and the October vehicle observations. Each item is presented for what it documents.
A firmware-to-documentation discrepancy
The original version photograph records an FCA R1-Low head unit running Android 8.1.0, security patch level March 5, 2020, kernel 4.4.138-perf+, and build FCA_R1L_ARM64_00.47.03.26.00 release-keys. The build identifies radio release R47.03.26.
That release is named in FCA TSB 08-172-24 (July 31, 2024), which covers specified 2022–2023 Jeep Compass vehicles, not the 2024 Compass documented on the September 16 service order. The bulletin describes a USB radio update to R47.03.26. The photograph therefore connects the observed release to service documentation for an earlier model-year population, without establishing bulletin eligibility or repair history for this vehicle.
For comparison, TSB 08-215-24 (October 2, 2024) covers specified 2024–2025 Compass vehicles and describes a separate over-the-air branch, U31.42 to U33.43, with applicability restricted by build date and equipment codes. The service order and photograph do not establish those vehicle configuration details or equate the U-levels with R47.03.26.
Why it matters: the observed 2024 vehicle carries R47.03.26, a release documented in a bulletin for 2022–2023 Compass vehicles, while the 2024–2025 bulletin describes another software branch. This discrepancy warrants examination alongside the dealership complaint and reproduced display behavior; by itself, it does not show an incorrect installation or explain the green-line artifact.
From dashcam to phone
4K source; publication copy scaled to 1080p. GPS metadata and in-frame coordinates are removed; speed, timestamp, road sequence, and audio are retained.
The phone recording preserves the CarPlay display and the accompanying audio.
The dashcam recording concludes with the researcher referencing a subsequent phone recording at Taco Bell. Both recordings are presented together to preserve the documented observation sequence. Players are independent and remain under viewer control.
Diagnostic reference: ExcUserFault_CarPlay-2026-09-16-152630.ips. The filename is documented here as a reference associated with the September 16 record; the raw diagnostic is not included in this publication bundle.
The paper
The resulting manuscript is an evidence-bounded case study, not a declaration that a shared vulnerability or causal chain has been found. It presents the documented observations, a layered state-divergence model, the limits of the available record, and a falsifiable plan for deeper interface investigation.
Read the paper Cross-Vendor State Observability: An Evidence-Bounded Case Study of Mobile and Automotive Systems · PDF
Selected publication media appear above. The complete evidence corpus, original dashcam recording, vendor correspondence, and private diagnostic records remain outside this post; the manuscript describes their provenance and limitations.
I started with systems that were behaving strangely. I ended with a question about how systems preserve, transform, and expose state—and a paper explaining why that question deserves a more rigorous answer than a shrug.
Not exactly farm to table.
From fault to paper.
History remains indistinguishable from the truth if the intermediate steps between the past and present are never fully and honestly represented.
A reminder that the boundary between light and logic is often just diffraction.
— An Anonymous Researcher