PAGE 02 · THE CORE PITCH

Five qalarc project areas, one rail-welding data problem

Each project below exists today at the stated maturity and answers a specific question steddi will face as it grows: how to capture data where there is no reception, how to see welds in space, how to keep humans in the loop as welding automates, and how to turn thousands of measurements into network intelligence.

01 — The overlap in one view

Where the data stops, and what should be behind it

The steddi GO instrument generates calibrated, geotagged, standards-compliant measurements. The companion app logs and exports them. Everything after the phone is the opportunity.

TODAY THE MISSING LAYER — WHERE QALARC PROJECTS LAND STEDDI GO LASER · TEMP · GPS BLUETOOTH PHONE APP DATA STOPS CSV EXPORT · PHOTOS WELD DATABASE TIMESERIES · GPS-KM chanalyse ingest ANOMALY DETECTION >3σ DRIFT ALERTS chanalyse pipeline 3D CORRIDOR VIEW TERRAIN · WELD MAP Rule the City engine COMPLIANCE REPORTS AS 1085.20 · EN 14730-1 chanalyse publishing REMOTE CORRIDORS: OFFLINE-FIRST CAPTURE + STORE-AND-FORWARD SYNC — RFAI PATTERN
Fig 1 — the steddi data path: solid boxes exist today; dashed boxes are the missing layer
  • Devices get copied; data platforms get entrenched. A network's historical weld database, once it exists, is very hard to displace — the first credible platform wins the category.
  • Nothing in the missing layer requires new science. Every box is a system qalarc already runs in production, in another domain.
02 — Project by project

What exists, what it does, where it lands

Fit ratings describe how directly existing capability transfers to a steddi use case. Every project name links to its live qalarc.com page or write-up.

01 RFAI Working · live demo · SDR + local AI

An offline-first radio-frequency intelligence stack: SDR hardware (HackRF One, Airspy Mini) captures transmissions, local Whisper models transcribe them, entities are extracted and archived to a searchable database — no cloud, no API keys. Supporting libraries include a pure-Python DSP kit and a waterfall display layer. Technical write-up: the HackRF post.

  • Remote-corridor sync: Rio Tinto's Pilbara network and Queensland Rail's regional corridors run through country with no mobile reception. A GO measurement synced to a phone still has to get home — store-and-forward with opportunistic uplink is the missing pattern, and local-first is RFAI's default architecture.
  • Adjacent service: the same SDR stack detects and geolocates RF interference — a growing concern as rail signalling goes wireless. A corridor-comms offering sells to the same buyers.
  • Credibility: the scanner runs at version 10 with an archived history and a deployed demo. The hard part — local AI on constrained hardware — is already solved.
Fit — high
02 Rule the City Working · live · Three.js real-topography engine

A tactical wargame engine that renders real 3D topography — Copernicus elevation data plus OpenStreetMap, 89 citymaps with Sydney first — with terrain heightfields, line-of-sight logic and a strategic layer. Deployed to production with a documented pipeline.

  • Track Twin: a 3D corridor viewer where each GO measurement is a marker on the rail, heat-strips show geometry deviation over kilometres, and fault reports pin to exact locations. Structurally the same problem the engine already solves: heightfield + entities + visibility.
  • The tender differentiator: track engineers currently get PDFs and spreadsheets. A 3D corridor view of weld history is a visible step up — and it reuses the DEM/OSM pipeline built for 89 cities.
Fit — high
03 chanalyse Working · live product · ingest → anomaly → publish

A continuous data pipeline — collection, embedding-based clustering, >3σ anomaly detection, automated analysis and publishing — on PostgreSQL/TimescaleDB with live dashboards. It already runs as a public product with hundreds of published articles.

  • The platform gap, filled: every GO measurement (geometry, temperature, GPS, timestamp, crew, device serial) is a timeseries record. Ingest, store, detect, report — the architecture transfers almost one-to-one. "Alert when a crew's welds drift out of spec" is the same code as "alert when a topic spikes."
  • Compliance as a subscription: automated report generation against AS 1085.20 / EN 14730-1 turns a regulatory chore into recurring value. Principals audit contractors with this paperwork today, by hand.
Fit — high
04 Folkus vision suite Working · live demo · custom-trained image models

Custom-trained image classification models — MobileNetV2 fine-tuned in-house on the 86,744-image FairFace dataset (two-phase training: frozen backbone, then full fine-tune), reaching 92.1% gender accuracy and 5.37-year age MAE, temperature-calibrated and exported to ONNX INT8 for sub-25 ms on-device inference. Deployed in the Smart Glasses Face Tracker live demo.

  • Photo pre-screening: the GO workflow already produces geotagged photographs. A small on-device model that pre-screens grind quality — pass, rework, suspect — turns every welder into a consistent first-pass inspector.
  • The compounding asset: photo + geometry + temperature is exactly the input set for predictive weld-failure models. The labelled dataset accumulates from day one.
Fit — medium
05 robot_hand Hardware prototype · teleoperation + vision closed loop

A 3D-printed tendon-driven hand that mirrors a human operator in real time — webcam MediaPipe tracking drives the robot, and a second camera watches the robot itself for closed-loop verification, with comparison dashboards and pose-sequence recording for supervised task learning.

  • Near-term — the training simulator: steddi's pitch is correct alignment irrespective of training and experience. The complement is a simulator that watches a trainee's alignment technique and scores it against steddi-defined values — the same human-tracking + reference-comparison pattern robot_hand already implements.
  • Long-term — teleop supervision: as grinding and welding robotise, one specialist supervising several machines inside a short possession is the human-in-the-loop layer. Rail certification for track robotics is a long road; this is the most speculative overlap, stated honestly.
Fit — medium
03 — What the data layer looks like

A corridor, not a spreadsheet

Track engineers reason in kilometres and corridors. The Rule the City engine already renders exactly this kind of geography — welds become points on real terrain.

EVERY GO MEASUREMENT = A POINT ON THE CORRIDOR TERRAIN (DEM) TRACK & WELDS DIPPED — FLAGGED FOR REWORK KM 42.0 — KM 44.6
Fig 2 — Track Twin concept: diamond size tracks geometry deviation; the outlier is flagged automatically
  • Heat over length: deviation encoded per weld along the corridor makes slow drift visible — by crew, by machine, by rail grade.
  • One flagged weld, one tap: from corridor view to the underlying measurement record, photo and compliance state.
04 — Integration pathway

Proof demos first, platform pilot second

  • WeeksProof demos on sample data: a corridor viewer fed by GO-style CSV exports, a dashboard mock, a training-simulator concept. Zero integration risk — everything runs on public specs.
  • MonthsA platform pilot with one friendly customer already using GO: ingest, dashboards, compliance reports, and offline sync for one regional crew.
  • DirectionMachine-readable QA output for welding trains and grinding robots — the independent measurement layer that automated welding will require. Detail in the auto welding review and the roadmap.

Published as an interested overlap

This page is an independent analysis, not a product claim. steddi® is a trademark of Bartoleni Engineering & Consulting; everything here reads public information alongside qalarc's own project portfolio.