Bench Sensors, Edge Hardware, And Platform Readiness Update

The last update was about Core Rev C reaching a cleaner validation baseline.

Since then, the work has moved one step closer to the kind of evidence that matters most before prototype production: real parts connected to real firmware.

That is an important change in posture.

Design-rule checks, schematic checks, simulations, and manufacturing packages are necessary. They reduce ambiguity before money and time go into hardware. But they cannot prove that the bench device, firmware, and selected sensors are actually moving together.

This week started to close that gap.

The bench Core is gaining the missing sensor truth

The Core bench prototype now has a new hand-wired sensor on the same shared sensor path as the rest of the sensor stack.

The first useful result was simple but important: the device was detected by firmware and produced changing X, Y, and Z readings when the board was moved and rotated.

That is not a finished sensing feature.

It does not yet mean the system has calibration, enclosure effects, or final production placement solved. Those are separate steps. The sensor has to be characterized inside the actual product environment, because nearby components, wiring, board orientation, and enclosure choices can all change what useful readings look like.

But raw changing values are the right first proof. They show that the bus wiring, device identity, driver path, and basic sample path are alive.

The next firmware step is to make that stream more deliberate: capture X, Y, and Z at a stable rate, log it consistently with the other sensors, and use that evidence to begin calibration work instead of guessing from static readings.

The sensor decision is being corrected before fabrication

The bench work also caught a useful hardware-process issue early.

The sensor on the bench is not the same device family that the current Core PCB review path had been carrying.

That is exactly the kind of mismatch that should be found now, not after prototype boards are ordered.

The practical outcome is a cleaner decision point: either align the PCB with the bench-proven path, or deliberately choose a different production sensor and make firmware, sourcing, schematic, layout, and validation all agree.

The important part is not that a part number changed. The important part is that Apex is treating the board, firmware, and bench harness as one system. A sensor is not "chosen" when it appears in a schematic. It is chosen when the electrical design, physical placement, firmware driver, logging path, calibration strategy, and supply path all survive review together.

Classic and Edge are becoming real hardware profiles

The display side of the platform also moved forward.

Classic and Edge are no longer just different screen ideas competing inside one firmware path. They are becoming separate hardware profiles with their own constraints.

Classic continues to represent the round display direction. It has already proven useful as a working display target with BLE telemetry, custom face delivery, touch behavior, and separate firmware configuration.

Edge is the rectangular direction. It moved from firmware bring-up into a dedicated board direction, with a display-first layout, a cleaner product boundary, and a sensor set that fits the role of a wrist or visual companion device rather than trying to carry every Core responsibility locally.

That separation matters because it keeps the product architecture honest.

A round display, a rectangular display, and the Core audible device should not be forced to share the same physical assumptions. They can share platform behavior, telemetry, face assets, and validation habits while still having different board shapes, power budgets, controls, and enclosure realities.

Why this matters

This phase is about turning Apex Infinity's hardware work from a collection of promising paths into a disciplined platform.

The Core board is moving through validation toward manufacturable hardware. The bench prototype is starting to prove the sensor path that the manufactured board will depend on. The display layer is splitting into clearer Classic and Edge hardware profiles instead of staying as one general experiment. And the firmware work is being tied back to logs, sample rates, and calibration needs rather than treated as a one-time bring-up.

That is the shape of real product work.

It is not only "does the device turn on?" It is:

• does the schematic match the part being tested?
• does firmware identify the device correctly?
• do the logs capture enough data to debug the behavior later?
• does the board profile match the physical product?
• can the same validation habits follow the platform from bench wires to manufactured prototypes?

Those questions are less flashy than a new screen or a new sensor, but they are what make the hardware path trustworthy.

What is still next

The new sensing path still needs real calibration work.

The Core hardware still needs final sensor alignment, manufacturing review, assembly, power and thermal checks, RF/location services validation, and enclosure-aware testing.

The Classic and Edge display boards still need to move from clean design intent into physical prototype evidence.

But the direction is better now than it was a few days ago.

The board checks are becoming more reliable. The bench device is carrying more of the production sensor story. The display family is separating into clearer hardware identities. And the remaining unknowns are becoming specific enough to test.

That is the kind of progress Apex needs before the next round of hardware becomes expensive.