AI Wearable Factory Acceptance Tests: What to Agree Before a Greater Bay Area Pilot Build

The short answer: agree two separate release gates

Before a pilot build, agree a versioned factory acceptance plan that states the device configuration, test method, measurement limits, record format and decision owner. Keep a separate product-validation plan for AI accuracy, user experience and real-world battery life. A factory pass should mean the agreed assembly checks passed, not that the product is ready for every customer.

Consider an illustrative voice-recording wearable: a clip that captures audio and sends it to a phone for transcription. A repeatable acoustic check can help screen the capture path. It cannot establish transcription quality across accents, crowded rooms or different wearing positions. Those require a different experiment, with its own conditions and success criteria.

For a team working remotely with a Shenzhen or Dongguan manufacturing partner, the useful handoff is not a message saying 'test everything.' It is a small, reviewable package that lets both engineering teams make the same decision from the same evidence.

Write a test-plan row that another engineer can repeat

Use the following worksheet as a proposed starting point, not a universal standard. Every row needs a named owner and an agreed numerical limit or explicit expected state. 'Microphone works' and 'Bluetooth OK' leave too much room for different interpretations.

Separate tests intended for every unit from longer engineering or sample-based checks. Record the chosen sampling rule, the reason for it and the action triggered by a failure. Do not describe a sampled check as if every delivered device underwent it.

Make the audio measurement independent of the AI result

Listen's published open-loop microphone example records a known acoustic stimulus on the device, transfers the recording for analysis, and evaluates frequency response and sensitivity. It also says the example acceptance limits must be adapted to the device. That is a useful distinction: test the audio path with a controlled input before treating a transcription result as a hardware measurement.

For your own plan, have the acoustic engineer specify the source, calibration method, distance, orientation, enclosure configuration, capture gain and relevant environmental conditions. Decide whether the test is checking the assembled product's capture path or the microphone component alone. Keep the path and settings consistent between the approved reference units and the pilot units.

Ask what happens when an audio result is borderline. A cloud-model retry should not silently turn a questionable acoustic result into an assembly pass. Keep waveform evidence where justified, using synthetic or approved test audio rather than customer conversations.

Sources: Listen: Open Loop Microphone Test (V4)

Do not let a successful pairing stand in for the whole radio test

Nordic's nRF5x white paper describes over-the-air production testing of a fully assembled Bluetooth Low Energy product, including its antenna. This is a platform-specific example, but it highlights why the finished device deserves attention alongside the assembled board.

Ask the responsible RF engineer which failure modes a simple connection check covers and which need instrumented measurements or separate validation. Record the chosen peer or tester, firmware mode and physical arrangement. Do not substitute an uncontrolled office connection for a test whose acceptance limits were developed in a different fixture.

Treat power checks with the same discipline. Compare measurements taken in defined states, not an unexplained current number. Longer user-duty-cycle battery tests belong in the product-validation plan. Charging and cell-safety procedures must be approved by qualified engineers; this guide supplies no battery safety test recipe.

Sources: Nordic Semiconductor: nRF5x OTA Testing with LitePoint Bluetooth Advanced

Keep the first result, the retest and the final disposition

An end-of-batch 'all passed' spreadsheet is not enough to diagnose an intermittent problem. As an editorial starting point, request a record for each run containing device identifier, hardware and firmware revision, station and fixture identifier, test-plan version, timestamp, measured values with units, outcome and failure reason. Link any rework and retest to the original run.

Store device identifiers in those records, not private provisioning keys or account credentials. Agree who can access the records, how they are exported and how long they are retained before the pilot starts.

OpenHTF is one publicly documented option for organizing hardware tests around measurements and test records, including attachments. The important requirement is the evidence format and traceability, not a particular software brand.

Report first-pass yield separately from the final accepted quantity. For an explicitly defined first-pass metric, divide units passing their first completed run by the units completing a first run; report aborted or missing runs separately. A unit that passes only after rework must not be relabelled as a first-pass success.

Sources: OpenHTF: Official Source Repository

Prove that the test station can distinguish a failure

Before the supplier uses the plan for the pilot batch, review repeat runs on approved reference units and engineer-approved fault specimens. This is our suggested handoff check: confirm that normal setup variation does not reverse the decision, and that the selected faults fail the intended checks.

Do not use one reference unit to define all acceptance limits. Ask the engineers to justify the limits from design requirements, measurement uncertainty and appropriate validation evidence. Record fixture maintenance and calibration responsibilities, and decide what pauses testing when a reference check drifts.

Agree a controlled change process. A new test-script revision, fixture replacement or limit adjustment should have an owner, a reason and an effective point. Retain the earlier results instead of overwriting them to match a later rule.

Release the pilot with an evidence package, not a shipment photo

Agree the pilot-release evidence before work begins. The table below separates three decisions that can otherwise be collapsed into a single 'ready' message. This is a proposed division of responsibility; the actual owners and acceptance terms need written agreement.

An unresolved failure does not automatically mean the entire design is unusable. It does mean the release owner needs to decide whether to investigate, rework, accept a specifically documented exception or hold the affected units. Record that decision and its scope.

Bring the handoff package to your Greater Bay Area partner

For the next supplier discussion, prepare the approved product revision, draft test matrix, available reference units, proposed fault coverage, record example and open engineering questions. Ask the partner to identify unsupported checks, missing fixtures and assumptions requiring confirmation. Assign owners and dates to those gaps.

Start with a non-confidential description before sharing detailed design files or proprietary datasets. Jimhang Capital welcomes US, UK and European AI hardware teams that want to discuss supply-chain coordination and investment readiness with Justin Zhan. A useful introduction states your product stage, existing test evidence and the next manufacturing decision you need to make.

Manufacturing engagements and investment discussions require separate assessment. The immediate aim is a pilot that produces trustworthy evidence, not a promise of financing or a guaranteed production outcome.