From device to system of record to closed loop
A four-phase technology roadmap for rail-weld measurement, each phase annotated with which qalarc capability plugs in. The phases are cumulative and each de-risks the next. Phases zero and one are buildable now with existing systems; phases two and three track the automation wave documented on the auto welding page. This is a scenario, not a commitment on anyone's behalf.
Cumulative, each one de-risking the next
Devices are already in the field. The platform is the next step, and everything after it depends on the data that platform accumulates.
Scenario · not a planMeasurement hardware plus a companion app
ONE and MINI digitise pre-weld alignment; GO verifies post-grind geometry at 0.01 mm vertical resolution, captures rail temperature, syncs over Bluetooth and produces geotagged photographic proof. Deployed at Sydney Trains, Queensland Rail and Rio Tinto. Data currently terminates on the phone as CSV exports and photographs.
Capture, aggregate, report, visualise
Ingest device exports and photographs into a time-series weld database keyed by GPS, track kilometre, crew and device serial. Deliver network dashboards, per-weld compliance records against AS 1085.20 and EN 14730-1, automated reports for principals, and a 3D corridor viewer — "Track Twin" — so engineers see welds on real terrain. Offline-first capture with store-and-forward sync handles no-reception corridors by design.
From records to foresight
With months of accumulated geometry, temperature and location data: statistical process control per crew, per machine and per rail grade; anomaly detection beyond three sigma flagging drift before welds fall out of spec; correlation of grind quality against later track-geometry-car readings to understand dipped-weld formation; and on-device photo pre-screening models trained on the accumulating labelled set. A training simulator fits here — the instrument defines what correct means, the simulator teaches to it, and the platform measures the improvement.
Independent QA for machine welding
As flash-butt welding trains and grinding robots industrialise the weld itself, the measurement layer becomes the neutral verification tier: machine-readable QA output per automated weld, an audit trail held on behalf of the asset owner rather than the contractor, and eventually measurement feedback that closes the loop on automated grinding. Human-in-the-loop teleoperation — one specialist supervising several machines inside a short possession — is the long-horizon extension. Automated welding, independently verified.
The 90-day version
"Data platform" is a vague phrase, so here is the concrete smallest version, assembled entirely from components that already run in production elsewhere.
| Week | Deliverable | Built from | What it establishes |
|---|---|---|---|
| 1–2 | Export parser and weld schemaGPS · track kilometre · geometry series · temperature · crew · device serial | chanalyse ingest patterns | That the data model survives contact with real exports |
| 3–4 | Dashboard: weld list, map pins, geometry profile per weld, spec-band shading against AS 1085.20 and EN 14730-1 limits | Time-series stack with dashboards | Whether a network engineer finds the view usable |
| 5–8 | Track Twin corridor demonstrationone corridor on real DEM and OSM terrain, welds as heat-strip markers | Rule the City Three.js engine | Whether spatial context changes how the data is read |
| 9–10 | Compliance report generatorper-weld PDF with photograph, geometry and signature block | chanalyse publishing pipeline | Whether the generated artefact is accepted as-is by an auditor |
| 11–12 | Offline capture queue specification and prototype syncstore-and-forward with opportunistic uplink | RFAI local-first architecture | Whether remote corridors are handled by design rather than by luck |
Why 90 days is a credible envelope
Every row reuses a system that already runs in production in another domain: the ingest and anomaly stack publishes live today, the terrain engine renders 89 real cities today, and the offline-first pattern runs on a live field demonstration today. The only genuinely new engineering is the device export format — which is a documented CSV and app export, not an unknown.
What changes when the market is European rather than Australian
Four factors that change the shape of a data platform.
- Standards tailwind. EN 14730-1 is already referenced in steddi's own published material, and the EU market is standards-driven. A compliance-reporting platform aligned to EN norms is an easier proposition in Europe than in Australia, simply because the documentation burden is higher and more uniform.
- Data residency. An EU-hosted tier — or on-premises deployment at national rail operators — will be asked for. A local-first architecture is an advantage rather than a compromise here: processing happens at the edge, and the amount of data that must leave the corridor is minimal by design.
- Competition. Europe has established track-measurement vendors with existing relationships. The pre-weld alignment niche combined with a data platform is still a defensible wedge, but the window is the market entry itself — retrofitting a platform after incumbents bundle one is considerably harder.
- Sequencing. Hardware scale-out and platform build are different kinds of work with different funding shapes. The platform is what makes the customer relationship durable at the moment European volume arrives, which argues for it existing before the volume rather than after.
What could stop this, and the answer to each
Stated plainly, because a roadmap that only lists upside is not an engineering document.
| Risk | Mitigation |
|---|---|
| Rail procurement moves more slowly than a small company's runway | Sell the platform to contractors, who buy tools faster than principals do and need the compliance evidence for their own audits |
| Device data access is restricted because the app is closed | Phase 1 works entirely from CSV and photo exports — no device changes needed. A formal API is a partnership conversation, which a working demonstration is what opens |
| An incumbent bundles a platform first | Speed and focus. The pre-weld niche is genuinely distinct; incumbents optimise for post-weld inspection cars and are unlikely to move first into alignment |
| Copycat hardware undercuts the devices | The durable asset is the accumulated weld database and the calibration credibility, not the widget — which argues for building the database before the copycats arrive |
| Overreach — attempting phases 2 and 3 too early | Strict sequencing: no predictive claims until phase 1 data exists; no automation interface until a customer is actually running automated welding plant |
| Consolidation by an adjacent player, e.g. inspection-data acquisition | Independence is the product. A verification layer owned by the party doing the welding is worth less to an asset owner than one that is not |
Scope of this roadmap
These are scenarios drawn from public information, published as part of an independent qalarc analysis. They are not statements of anyone's plans, and the phase timings are engineering estimates rather than schedules.
See the steddi analysis for the product and company detail behind Phase 0, the project overlap for the engineering that each phase reuses, and the auto welding review for the automation wave that Phases 2 and 3 track.