How to Write a Final LoRa Mesh Pilot Acceptance Report
Prepared by the ChatField Editorial Team. Evidence reviewed August 18, 2026.
A pilot is not complete when the last field message is sent. It is complete when the buyer can trace each mandatory requirement to versioned evidence, understand every exception and make an authorized buy, revise or stop decision.
Short answer
Write the report around requirements, not chronology. Identify the exact product and software, users, routes, test conditions, results, failures, recovery, safety and privacy boundaries, commercial scope and approvers. Preserve marginal and failed evidence instead of turning the document into a sales summary.
1. Executive decision
State the recommendation in one paragraph: buy, revise and retest, or stop. List the mandatory requirements that passed, open exceptions, proposed quantity and conditions that must be included in the quotation or contract.
Do not write “successful pilot” without defining the approved criteria.
2. Scope and exclusions
List sites, routes, checkpoints, users, phone models, message workflows and dates. State what was not tested, including emergency use, unapproved environments, other countries, unlisted phones, unsupported functions or future products.
The off-grid communication overview can anchor the local equipped-team scope.
3. System identity
Record application build, phone OS, J25 hardware, firmware, regional radio configuration and group assignment. Current public J25 evidence includes FCC ID 2BVP9-J25.
For current J25 use, the phone is the interface, Bluetooth connects it to the carried terminal, and the configured terminal carries supported traffic through the local LoRa mesh.
Attach the How It Works page and relevant J25 specifications.
4. Requirement-to-evidence table
| Requirement | Method | Evidence ID | Result | Exception | Owner |
|---|---|---|---|---|---|
| Required route checkpoint | Repeated bidirectional test | Pass / Marginal / Fail | |||
| Supported PTT workflow | Recipient confirmation | ||||
| Bluetooth recovery | Controlled disconnect |
CISA lifecycle guidance recommends tying testing procedures to an acceptance test plan that tests stated requirements. Each result should point to a log, photograph, version record or signed observation rather than an untraceable claim.
5. Route and range evidence
Record direct and supported relay paths separately. Include map and route distance, terrain, structures, vegetation, vehicles, device position, direction, repeated trials and human understanding.
Current J25 evidence includes 5 km in urban-obstructed testing and up to 10 km in ideal open terrain. Preserve those conditions. For current planning, evaluate no more than two participating relay nodes where the tested layout and configuration permit.
6. Failure and recovery
List Bluetooth disconnections, terminal power loss, removed participating nodes, wrong groups, delayed messages, unclear PTT, battery issues and user errors. Record detection, recovery steps, time, fallback and retest result.
A workaround does not erase the original failure. It becomes a documented operating dependency.
7. Human and operational evidence
Separate technical delivery from correct recipient understanding. Include training time, user errors, attention risks, shift handoff, phone-terminal assignment and support requests.
State whether the operating procedure was realistic for the intended role.
8. Safety, privacy and IT review
List prohibited uses, fallback communication, unsafe zones, BYOD or company-phone rules, permissions, group access, image and location handling, update process and lost-device response.
Record the responsible approver. A product team should not self-approve the buyer's safety or privacy program.
9. Commercial conversion
Translate the approved pilot into production quantity, spares, phones, accessories, application scope, customization, documents, training, shipping, warranty, repair and support. State assumptions, exclusions and acceptance milestones.
ChatField's current B2B discussion begins at a minimum order quantity of 100 units. Final terms remain quotation-specific.
10. Retest triggers
- New phone or operating-system version
- Application or firmware update
- Regional hardware change
- Route, building, vegetation or vehicle change
- New message workflow or user role
- Changed relay placement
- Revised safety, privacy or IT policy
Contact ChatField procurement support with the approved acceptance report and open exceptions to request a production quotation or bounded retest.
Sources reviewed
CISA does not endorse ChatField or J25. Its material provides lifecycle and acceptance-planning context, not approval of a particular pilot result.