About

M&E engineer in Singapore, moving into condition-monitoring pre-sales. The judgement layer is built; the customer at-bats are what I am looking for.

I maintain mechanical and electrical plant for a living, which means I spend my days around equipment that is already instrumented and already logging — and almost none of it is ever read. Every project on this site started from that gap rather than from a procurement request.

What I'm looking for

Pre-sales, solutions or application engineering in condition monitoring and reliability — the technical seat in a customer-facing team. Singapore-based, comfortable regionally, and genuinely interested in the Thailand-facing side of the region.

Here is my position stated plainly, because you will work it out in the first interview anyway:

What I bring is the judgement layer, which is the part that normally takes years to teach. Qualifying an opportunity out when the evidence says so. Stating coverage limits before a customer discovers them. Killing a feature that demos well and means nothing. Turning a spectrum into a maintenance date and a budget line, in whichever dialect the room speaks.

What I do not have is at-bats. Zero real customer rooms. That gap closes with volume and nothing else — no amount of preparation substitutes for reps in front of people who can say no.

So I am looking for the team that hires for the first and supplies the second. If your pipeline provides the reps, I will not need to be taught what to care about.

The commercial layer

The technical case studies are the easy part to evidence. This is the part that decides whether the technical work is worth anything, so it goes first.

I qualified out my own employer. I ran discovery on my own plant and concluded it was not a candidate — the nuisance trips were correctly being run to failure, and calendar maintenance was genuinely holding. Recommending add nothing is the same skill as knowing when to instrument, and it is the one that makes every later recommendation credible.

I killed my own best-looking feature. An earlier version of the anomaly tool produced a weighted per-day risk percentage. Against real data it returned roughly the same number every day, including days when nothing happened. It was the most impressive-looking output the project ever produced and the least honest, so it was removed rather than tuned.

I have watched a pilot die commercially. The escalator monitoring pilot was approved in principle and designed down to the sensor part numbers. It was killed by who is allowed to drill and who owns what — never by engineering. That case study is on this site in full, including the parts that reflect badly on the proposal, because why pilots die is the most useful thing I currently know.

I state what is not claimed. One confirmed fault event is a demonstration, not a catch rate. A threshold set on two weeks of data is a guess with a Greek letter attached. Both of those sentences appear on this site about my own work, because a finding that oversells itself is worth less than one that admits its bounds — and because "no, our system won't catch that" is the sentence that makes every yes bankable.

I can say the same thing three ways. I came to this from teaching before engineering, which turns out to be the transferable part. Fault detection is table stakes; what actually lands is translation — the same finding rendered for the engineer who wants the mechanism, the manager who wants the money, and the IT lead who wants to know which ports open.

The technical anchor

Condition monitoring is the domain, and it is what makes the commercial layer more than opinion. Vibration, current signatures, enveloping, the physics of how rotating machines fail and what they emit while doing it. You cannot honestly qualify an opportunity out, or tell a customer what a technology will not detect, without knowing where each method sits on the P-F curve.

The case studies here are the evidence: real plant telemetry, real findings, arithmetic that can be walked through line by line in a room with someone who has been doing this for twenty-five years.

Where this goes next

Machine learning, then AI — deliberately sequenced after the commercial work rather than before it, because that is the order the job actually needs.

The seam I want to reach is model auditing. Bearing kurtosis falls back toward normal in late-stage failure, so a classifier trained on "high kurtosis = bad" will clear a machine that is days from seizure. Someone in the room has to know that, and it has to be someone who can also explain it to the buyer. The bearing study is the first step in that direction, not the finished article — and it says so.

I am stating this as a direction, not a credential.

How I work

I direct AI through the work and audit what comes back. That is the honest description, and it is stated on every page of this site rather than left for you to infer — each project carries a note saying which parts were mine and which were the machine's, because the split genuinely differs between them.

The short version: I choose the question, set the standard, decide what gets claimed and what does not, and stay fluent enough to catch the confident answer that is wrong. I have done more this way than I could have done alone. I have not done it without understanding it, and the difference is the whole discipline. The full method is here.

Everything below is what that direction is actually for.

Start with the telemetry that already exists. Every case study here was built with zero new sensors. Meter and relay logs were already being written and never opened. Instrumentation is the expensive, slow, politically hard step — it should be the second one, justified by what the free data showed.

Deterministic where it matters. The analysis paths in these projects contain no machine learning and no LLM. Every number in a report is computed arithmetic against a physical law, so it can be defended line by line in a room with an engineer who has been doing this for twenty-five years. That constraint is not modesty; it is what makes the output usable.

Stay fluent enough to audit. As AI briefing layers replace raw data, the people who could check the machine stop being able to read the numbers — the tool that makes expertise unnecessary erases the expertise needed to catch it failing. I take that seriously enough to apply it to myself, which is why the domain learning happened separately and deliberately, by deriving mechanisms and getting corrected rather than by reading.

Background

Teaching before engineering, then M&E maintenance, now condition monitoring. Currently working through formal condition-monitoring theory alongside the applied work — self-directed, not yet certificated — and building the tooling out in the open. The glossary is where that study is kept honest: every term in three registers, because a definition I can only give one way is one I have not finished learning.

Start here

The fastest way to judge whether this fits is to read one of the case studies rather than a CV.

• Fan drift — the most complete, and the strongest findings
• The escalator pilot — the commercial one: what killed it, and why that had nothing to do with the sensors
• Bearing prognostics — where I am heading rather than where I am

Email me — happy to talk about any of it, including the parts that did not work.