Platform Reliability, Storage, and Support Readiness

Some progress makes a product look different.

Other progress makes a product harder to break.

This round was mostly the second kind.

The work focused on the parts of Apex Infinity that users should not have to think about every day, but absolutely need to trust: whether Core data has really been synced, whether storage is healthy, whether a custom UX transfer actually lands on the device, whether firmware update checks fail cleanly, and whether the product is beginning to explain itself clearly enough for real users.

That is not a flashy category of work, but it is a product-readiness category of work.

Synced Core data now has a clearer lifecycle

The Core-to-Companion logbook path had already reached the point where Companion could import real Core data and avoid duplicate local entries.

The next question was what happens after that data has been safely copied.

That matters because Core has finite onboard storage. Imported data cannot just remain in an ambiguous state forever. The system needs to know the difference between data that is still only on Core and data that has already been offloaded to Companion.

The platform now has a stronger foundation for that lifecycle:

• Companion can mark Core log entries as offloaded after a successful sync
• Core can persist that offloaded state
• Companion can skip data that already exists locally instead of importing it again
• and future storage cleanup logic can use the offloaded state as the safe boundary for reclaiming space

This does not mean Apex Infinity should casually throw data away. It means the platform is starting to understand the difference between protected, not-yet-synced data and data that has already been handed off.

That distinction is essential before Core can make intelligent decisions about storage pressure.

Storage visibility moved closer to being user-facing

Storage is one of those things that should feel boring when it works.

But for an always-on device that logs real activity, storage cannot be invisible forever. The user should not discover a storage problem only after something important failed to record.

This round added better visibility into Core log capacity from two directions.

First, Core gained a local USB debug command that can report NOR log status in human-readable terms: total capacity, used space, free space, record counts, number of stored activity records, and estimated remaining capacity.

Second, Companion began presenting Core storage more like a persistent device state instead of a temporary sync-only detail. That is the right direction. The user should be able to understand at a glance whether Core is healthy, filling up, or approaching a point where sync is required.

The next policy question is now clearer: Core should calculate capacity dynamically from the installed NOR flash, estimate remaining storage conservatively, and eventually reclaim offloaded data only when it needs to preserve safe headroom for future logging.

The important rule is simple:

Core should never silently fail to log because storage management was vague.

The custom UX path became more trustworthy

Classic and Edge also had an important reliability pass.

A custom UX transfer could appear to complete in Companion while the receiving device did not actually end up applying the new UX. That is exactly the kind of mismatch that makes a system feel unreliable: one surface says the operation is done, while the device tells a different story.

The fix started by treating storage failure as a real failure instead of letting a partial file linger.

The receiving side now behaves more defensibly:

• failed writes abort the current transfer
• partial UX bundles are removed instead of left behind
• storage availability is checked before accepting a new UX
• stale non-active UX bundles can be cleaned up
• and the device keeps only the intended active UX instead of accumulating unnecessary copies

That made the face transfer path much more predictable.

It also clarified a future product requirement: Companion should eventually know not only that a transfer finished, but that the device accepted and applied the UX successfully.

Firmware update checks now fail more gracefully

Another small but important reliability fix landed in Companion.

The Core firmware update section could request a hardware-target-specific manifest path that was not available in the current firmware feed layout. Instead of giving the user a useful answer, that produced a raw access-denied response from the storage backend.

That is not the kind of failure a user should see.

Companion now tries the hardware-target feed first and falls back to the generic device/channel feed when that hardware-target path is missing or inaccessible. It also avoids surfacing raw backend XML in the user-facing message.

The result is a more forgiving update-check path, while still leaving room for hardware-targeted feeds later.

Documentation is becoming part of the product

This round also started the consumer documentation path in a more formal way.

That matters because Apex Infinity is no longer just a bench system with a handful of developer notes. Companion, Core, Classic and Edge, Face Studio, account behavior, UX libraries, firmware updates, storage state, and logbook flows are all becoming real product surfaces.

Users will need a manual.

Support will need consistent language.

The product will need online documentation that explains what each surface does without assuming the reader has followed every development step.

The first Companion manual draft and documentation structure are now in place. They are early, but they mark an important transition: Apex Infinity is starting to document itself as something people will actually use, not just something we are still assembling.

Audio warnings are becoming a design consideration

The Core storage conversation also exposed an important limitation: Core is primarily an audible device.

If Core ever reaches a state where it cannot safely guarantee room for another log, it needs to warn the user. But audio alone cannot be the only warning, because a user may miss it if the device is not nearby, not being worn, or competing with other noise.

The better direction is layered:

• Core should automatically reclaim already-offloaded data before storage becomes critical
• Companion should show persistent storage and sync-required state
• Classic and Edge should mirror critical storage warnings
• Core should still provide clear audio warnings as a last-mile alert

That led to the next voice-prompt planning step: generated voice assets for both female and male voices, plus a non-spoken tone option for users who prefer beeps over spoken prompts.

Why this matters

The theme across this round is not one feature.

It is trust.

The platform is getting better at knowing what has been synced, knowing what can be reclaimed, knowing how much storage remains, knowing whether a device operation really completed, and explaining failure states without leaking implementation details to the user.

That is how Apex Infinity moves from “working in the lab” toward “safe to depend on.”

What is next

The next major Core step is the storage retention and reclaim policy.

The likely direction is conservative:

• calculate capacity from the installed NOR flash instead of assuming a fixed size
• estimate remaining activity records using measured and worst-case data, not just optimistic averages
• keep not-yet-offloaded logs protected
• automatically reclaim the oldest offloaded logs when storage headroom gets low
• and surface warnings through Companion, Classic and Edge, and Core audio

That is the right kind of next problem.

It means the platform is ready to stop asking only whether it can log data and start defining how it protects that data over time.