Zyglox

Zyglox is a pre-seed rail-tech startup building predictive maintenance analytics for train wheelsets. I was founding engineer and first full-time technical hire, January to May 2026, working directly with the founders. The work below was proof-of-concept and exploratory research, not deployed production systems.

Five workstreams across modelling, simulation, data engineering, video and frontend, with one engineer. That was possible because I made AI-assisted development the default way of working, using Codex and Gemini as primary tools and agent-based workflows for operational and non-engineering tasks, adopting them on whether they solved a real problem rather than on novelty.

Surrogate models for finite element simulation

Wheelset behaviour under load is modelled with finite element analysis (FEA). FEA is accurate but takes minutes per run, far too slow to evaluate every wheelset on every train continuously. The task was to approximate its output from live sensor readings fast enough for operational monitoring.

I trained a multi-layer perceptron on FEA outputs. An MLP suits this because the target function is smooth and continuous: linear regression cannot capture the non-linearity, and tree-based methods approximate smooth functions with step functions, introducing systematic error between training points. Inputs were engineered features rather than raw streams, covering vibration amplitude and frequency, rotational speed, axle load, temperature, and GPS-derived track curvature, with time-series reduced to windowed summary statistics. I evaluated on the shape of the error distribution rather than RMSE alone, because systematic underestimation of wear is dangerous in a way overestimation is not, and tuned decision thresholds toward false positives. The result was inference in milliseconds instead of minutes, several orders of magnitude faster than the simulation, at an accuracy cost acceptable for trend and anomaly detection. Output was framed as a prompt for human inspection, never a replacement for it.

Digital twin of the sensor hardware

Data pipeline development was blocked on hardware availability. I built a digital twin of the proprietary sensor hardware, simulating its signals and modelling its data output as mathematical functions, then delivering that over virtual COM connections so the rest of the stack could not tell the difference between it and the real rig.

This unblocked ingestion and processing development entirely. Because the signals were known and repeatable, failures could be attributed to code rather than to hardware.

Rail network simulation

Realistic sensor signals are only half the picture. The data also needed to behave like a real railway at the operational level. I used SUMO (Simulation of Urban MObility) to build rail track simulations, modelling schedules, train runs and stops to approximate real-world operations as closely as possible.

Combined with the sensor digital twin, this produced a complete synthetic stack: realistic train movement feeding realistic sensor output, with no hardware and no access to a live network required to develop against.

Video processing

Sensor events needed corresponding video, and raw footage was too large to move around freely. I built extraction and processing to identify the video segment best matching a given timestamp, implemented compression and edge detection to reduce the data and isolate structure, and researched event detection methods on the processed output. Timestamp-to-segment matching worked. Event detection was established at proof-of-concept level.

Sensor KPIs and dashboard

Railway engineers are domain experts, not software users, and raw sensor readings are not decisions. I built proof-of-concept transformations from raw sensor data into customer-relevant KPIs and implemented features on the IoT sensor data dashboard those KPIs fed into. Supporting pipeline work covered cleaning noisy time-series data, spatial lookup to match noisy GPS traces to track segments, and the storage and transformation underneath, using Python, Pandas, NumPy, Scikit-learn, QuestDB and Jupyter.

I designed backwards from the decisions operators actually make rather than from the data available. Early versions showed raw vibration frequency charts, which was the wrong instinct. The direction was status-level indicators answering one question, is this wheelset fine or should someone look at it, with detail available on drill-down rather than forced on anyone.

Role: Founding engineer and first full-time technical hire.

Zyglox GmbH, incubated at Science Park Graz. January to May 2026.