Designing a road-monitoring pilot that can earn trust

A small pilot should produce more than a demonstration that data can reach a server. It should show whether the evidence is useful, whether a result can be explained and whether the system behaves sensibly when a journey or upload is interrupted.

Xinexis is planning an initial Road Monitor pilot for approximately ten users. The iPhone recording and review prototype and a local server baseline already exist. Public cloud hosting, participant accounts and server comparison across multiple drivers remain implementation work.

Keep the capture workflow independent

Road observations happen wherever the vehicle travels, including places with poor connectivity. The phone therefore records locally first. A connection can be used later to transfer a completed recording without making collection depend on a continuously available server.

The current implementation preserves original recording chunks and checks their integrity. Its local upload path can recognise repeated submissions and reconcile partially transferred data. Those properties are an engineering foundation for the internet-connected pilot, although they do not by themselves provide a complete multi-user service.

Give each part of the system a clear responsibility

The planned cloud architecture keeps four responsibilities distinct: participant access and uploads; private storage of originals; bounded background processing; and authorised evidence review. Processing should be able to restart without requiring a person to upload the same journey again.

We plan to use a spatial database for roads, traversals and derived evidence, while retaining high-rate recording files in private object storage. This lets the review system query useful summaries without treating every sensor sample as a screen-ready result.

A small deployment can run several of these components together. Clear contracts make it possible to separate them later if processing or user demand grows. The pilot does not need a large fleet architecture before its central hypothesis has been tested.

Make every result traceable

An observation should lead back to its source recording, analysis version and quality checks. A repeated-road summary also needs the road-network version, aggregation rules and time range used to produce it.

That history matters when the interpretation changes. A revised matcher may move an uncertain observation to another road section. A different detector may group a signal differently. The system should explain those changes without counting a reprocessed recording as a new physical pass.

Deletion needs the same care. In the planned aggregate service, removing an eligible source must also remove its contribution from affected summaries. Derived evidence should not keep claiming support from a recording that has been removed.

Share the evidence appropriate to the role

A participant, a research reviewer and a future road-maintenance user may need different views. Our design keeps access tied to an authorised project and sharing scope. A reviewer of suspected road features may not need a participant's complete journey.

Location histories can reveal personal routines even when names are replaced with identifiers. The pilot needs an explicit agreement about what is collected, who can inspect originals, how long recordings are retained and how deletion works. These are design requirements to implement and verify before opening the service to participants.

Test reliability and usefulness separately

Our existing software checks use synthetic recordings to exercise known signals, gaps, integrity failures, repeated uploads and restart behaviour. They establish specified engineering behaviours. They do not measure pothole detection accuracy on real roads.

The field study must add independently identified surface features, same-direction repeated passes, different vehicles and clear mounting records. We plan to examine location error, false alerts per distance, missed known features and the effort required to review a candidate. Evaluation should include complete roads and vehicle groups held apart from method development.

A useful pilot outcome may be a credible way to shortlist sections for inspection. It may also show where phone data is insufficient. Both outcomes can guide the next investment more effectively than an unsupported accuracy claim.

Define success with the people doing the work

For future municipal or fleet use, the next discussion is about decisions: what needs inspection, what evidence helps, how freshness matters and who reviews uncertain cases. We have not established a City of Toronto deployment or partnership.

If your team can help define those acceptance criteria, discuss a Road Monitor pilot with Xinexis. The aim is a bounded experiment with reviewable evidence and a clear decision about what to build next.