Core Rev C Clean Validation And Bench Sensor Readiness Update

The last update was about Core hardware becoming a managed product artifact.

Since then, the board work has moved from "cleaner" to something more concrete: a clean validation baseline.

That is a meaningful step.

It does not mean the board is proven in the real world yet. A manufactured prototype still has to be built, assembled, powered, measured, and tested. But it does mean the current Rev C design is no longer sitting in an ambiguous preflight state. The main design checks now have a clear answer, and the remaining work is easier to name.

The schematic and PCB checks are clean

The latest Rev C pass brought the schematic and PCB into agreement.

The design-rule check is clean. The schematic electrical-rule check is clean. The board has no unconnected PCB items in the current validation run.

That matters because it changes the posture of the work.

Earlier hardware review was still partly about eliminating known structural problems: missing connections, footprint mismatches, unclear schematic warnings, routing cleanup, and manufacturing-readiness questions. Those are the kinds of issues that make it hard to trust any higher-level review because the basics are still moving.

Now the basics are much more stable.

The board can be reviewed from a cleaner baseline, and that makes every remaining concern more specific.

The validation harness now matches the board state

One useful outcome from this pass was that the validation tooling itself got better.

The full validation harness briefly disagreed with the authoritative board check because it was checking zones without refreshing them first. That was not a board failure. It was a stale-check problem in the harness.

That is the kind of issue worth fixing immediately, because validation only helps if the tools are checking the design in the same state that KiCad actually uses.

The harness was corrected, the report wording was refreshed to match the current sensor direction, and the full validation run now passes.

The current preflight suite covers:

• PCB validation checks
• schematic validation checks
• schematic-to-board parity
• first-order power and timing simulations
• audio-burst load behavior
• sensor-rail behavior
• sensor-bus timing assumptions
• reset timing
• battery sag
• battery ADC divider behavior
• and LED current budget

That is not the same as real hardware proof.

It is still an important milestone because Apex now has a repeatable report instead of a pile of one-off notes.

The sensor direction became clearer

The board also moved to a clearer pressure-sensor path for Rev C.

The important public point is not the exact part number. The important point is that the design moved away from a weaker availability position and toward a newer sensor path that can still fit the board without reopening the whole layout.

That is exactly the kind of decision that matters before prototype production.

If a part is hard to source, unclear for assembly, or not the right long-term fit, it is better to make that decision while the board is still in review than after the first production package is already in motion.

The remaining bridge is firmware and bench validation. The hand-wired Core has already proven the major product workflows, but it does not yet represent the full Rev C sensing path. The next bench step is to wire up the new sensor boards, confirm that firmware can detect the expected devices, and confirm that readings look sane.

That will give the manufactured prototype a much stronger starting point.

The manufacturing package is closer to review-ready

The manufacturing package has also been refreshed around the current design.

That includes the fabrication outputs, placement data, assembly review materials, mechanical export, checksums, and validation artifacts.

This is not glamorous work, but it matters.

Prototype manufacturing is not only a PCB file. It is a bundle of decisions: board stackup, fabrication tolerances, drill capability, assembly data, component availability, part substitutions, mechanical fit, and validation evidence.

The current package is much closer to being something that can be reviewed deliberately instead of guessed at.

What is still not proven

The clean validation baseline is good news, but it should not be overstated.

There are still things that only real hardware, supplier review, or bench measurement can prove:

• RF and location services behavior
• assembly interpretation
• charger and regulator thermal behavior
• final antenna tuning
• enclosure effects
• production tolerance behavior
• and the new sensing path running on the bench and then on the manufactured board

That is normal for this stage.

The value of the current work is that those risks are now named more cleanly. The board is not blocked by obvious KiCad validation failures, and the next uncertainties are the kinds of uncertainties that belong in prototype bring-up.

Why this matters

This phase is about reducing ambiguity.

Apex Infinity has already proven many of the Core workflows in the hand-wired prototype: audio, replay, storage behavior, Companion-managed content, Bluetooth telemetry, and Wrist-facing validation. Rev C is about turning that into a physical board that can be manufactured, tested, and improved from a known baseline.

The latest work gets the project closer to that point.

The board checks are clean. The validation harness passes. The sensor direction is clearer. The manufacturing package is better aligned with the current design. The next bench work is known.

That is the kind of progress that matters before sending a board out.

The next step is to bring the new sensing path onto the bench, validate it in firmware, and then use that evidence alongside the manufacturing package review before committing the Rev C prototype to production.