Logbook Date Fidelity and Dense Replay Validation

This round of work was not about adding a flashy new surface.

It was about making the data behind the product more trustworthy and the validation loop behind that data much stronger.

Two things changed in a meaningful way:

• imported Core data can now carry the real date instead of quietly falling back to the import date
• and replay validation can now be densified enough to make logbook and KML output much more credible

Those are important changes because the logbook is one of the places where Apex Infinity has to prove that sensing, storage, transfer, and presentation all agree about what happened.

Imported data now has real date fidelity

One of the most important fixes in this round was finally preserving real time data from Core into Companion.

The problem was subtle but serious. Imported data could look structurally correct while still showing the wrong date. That makes the logbook feel less trustworthy than it needs to be, because history only works if the platform can say when something actually happened.

That path is now much healthier:

• Core captures real UTC during the summary flow
• the offload metadata path exposes that time correctly
• and Companion uses that imported metadata instead of treating the current day as a fallback answer

That may sound like a small detail, but it is the difference between “the import worked” and “the imported data can be trusted as history.”

The replay path is now dense enough to test KML quality better

This same round also added a new tool for generating synthetic Apex replay files with phase-aware density.

That matters because the original replay inputs were useful for validation, but they were still relatively sparse in the parts of the data where map and path quality are easiest to judge visually. If the replay source itself is too thin, then exported CSV and KML can only become so smooth no matter what the rest of the platform does.

The new replay tooling makes it possible to:

• keep some data at a lower rate where that data is less important
• increase the rate of the interesting data
• and generate Apex-format replay files that are much better for import and KML validation

That tool was then validated on hardware using a denser synthetic hop-and-pop replay.

The practical result was clear:

• the imported data carried materially more data than the earlier version
• and the KML path looked noticeably smoother

That is exactly the kind of test improvement Apex Infinity needs. It is not only “more data.” It is better validation data in the parts of the session where presentation quality matters most.

Phase-based logging experiments also clarified the storage story

Another useful outcome from this round was learning what phase-dependent logging cadence really changes.

The first pass on that work showed that reducing less important logging while increasing the active parts of the data is a good storage optimization, but not automatically a fidelity increase when the replay source itself is still sparse.

That is a useful answer.

It means the platform now has a clearer split between two kinds of work:

• storage optimization in the logger
• and replay-density or replay-pacing work in the validation path

Those should not be confused with each other. They solve different problems.

The next replay problem is also clearer now

The next replay issue is no longer vague.

The current replay engine still does not fully honor source timestamp pacing in wall-clock playback. In other words, the data can now be denser and more useful, but the playback loop itself still needs to learn how to move through that data in a more physically faithful way.

That is good news in a way, because the problem is now narrow and explicit.

The platform no longer needs to guess whether replay quality is limited by the source data, the importer, the KML path, or the runtime loop. Those questions are separating cleanly.

Edge hardware decisions are becoming more disciplined

The rectangular Wrist work also continued to reach better decision points.

The current Hosyond-based Edge path was useful enough to teach the platform where the fragility is, but not trustworthy enough to justify unlimited time. That makes the new hardware direction even more sensible:

• the next Edge bring-up will shift toward a higher-performance display path
• and a more ambitious follow-up display evaluation is still queued behind it
• and the goal is to move the rectangular path onto a more defensible display stack instead of endlessly working around a fragile one

That is not retreat. It is engineering discipline.

Why this matters

This round is a good example of the kind of progress that makes everything else more believable.

It is not just about moving data from one device to another. It is about making that data mean something once it arrives:

• the date should be right
• the path should look like what actually happened
• the validation inputs should be strong enough to reveal real quality differences
• and the hardware path should be honest about where effort is likely to pay off

That is how Apex Infinity becomes more than a set of interesting components. It becomes a platform that can explain itself and be trusted.

What is next

The next steps are straightforward from here.

Replay should learn to honor timestamp pacing more faithfully. The logbook will continue to improve around lifecycle and third-party imports. And the next Edge hardware bring-up will shift onto a higher-performance display path so the rectangular device can move forward on a stronger base.

That is not the end of the logbook story.

It is the point where the history behind the logbook, the validation behind the history, and the hardware behind the next device are all starting to align in a more serious way.