Research
Field notes from systems that run where it is hard.
We write about what we have built and operated, not about the industry. Five notes, drawn from delivered work in energy, agriculture and public sector verification.
Published.
Each one reports on a system that had to run somewhere difficult: what was built, what it refused to do, and where the record ran out.
Reporting absence: why an operations platform should refuse to estimate
Absence as a first-class value, enforced at the database layer, and what that changes for the operator pricing a loss or the statistician publishing an indicator.
02Forecasting against persistence in data-poor grids
A solar yield forecast is only a capability once it beats the dumbest possible model on real data. Holding forecasts to that bar in low-telemetry environments.
03Separating technical from non-technical loss without full conductor data
Where the physical basis for a loss figure ends, what can still be honestly said, and why the right answer is sometimes unavailable.
04Delivering machine learning advisory in low-resource languages
What changes when the output language is a low-resource local language and the reader is a farmer: confidence, review paths, and the shape of an advisory worth acting on.
05Field verification instrument design for donor-funded programmes
Designing instruments whose records survive audit years later: offline capture, hash-chain audit, and why harmonisation is a data quality decision.
Each note is written from a system that was built and operated, and goes no further than that work supports. None of them is a forecast of what the technology will one day do.
Every note starts where the evidence runs out.
The field notes above and the positions below argue the same case from opposite ends. A system that cannot say what it does not know will put something in the gap, and whatever it puts there will be read as a measurement.
So the first engineering decision is not which model to use. It is what the system is allowed to do when the basis for an answer is missing.
How AI should behave in essential services.
Six positions on secure and aligned AI. They are engineering positions rather than policy commentary: what a deployment has to enforce before a model is allowed anywhere near a grid, a field programme or a national indicator.
AI alignment at the point of deployment
Alignment as an engineering property of deployed systems: mandates written as policy, envelopes that bound behaviour, and failure directions chosen in advance.
07Secure AI for essential infrastructure
Mostly not about the model: input integrity, bounded authority, and the size of the blast radius when everything else fails.
08Aligning AI with the energy ecosystem
Grid codes, certification boundaries, tariff rules and community trust, translated into constraints the system structurally cannot break.
09Transparent and verifiable AI
An output that cannot be checked is a rumour with confidence. What a model's answer must carry: basis, age, method and confidence.
10The cooperative AI ecosystem
Essential services are multi-party by nature. AI has to cooperate across trust boundaries rather than compete to own them.
11Why attribution-based control is insufficient
Audit trails tell you who did what after it happened. Control is what stops the wrong thing happening at all.
