Trust at the edge
Once a platform can open a valve or switch a breaker, trust stops being a feature. These are the principles we build to.
When software reaches into the world
A monitoring system that gets something wrong produces a misleading chart. A system that acts on the physical world and gets something wrong can flood a basement, overheat a transformer or close a gate on a delivery. The stakes change the moment a platform can move equipment, and so must the way it's built.
We think about trust in four layers: knowing exactly what is connected, protecting what travels between site and platform, keeping a person in charge of every change, and keeping a record nobody has to reconstruct afterwards.
1 · Know every device
Every node and every probe has its own identity on the platform. Nothing joins a site without being claimed — usually by a person scanning its label with a phone, on site — and every reading and every command is attributed to the device it came from or went to. An unknown device is not a guest; it's a question.
Knowing devices individually also means knowing when one goes quiet, starts reporting implausible values or drifts away from its siblings. The platform watches the health of the sensing itself, not only the readings, so a failing sensor is caught as a failing sensor rather than mistaken for a failing machine.
2 · Protect what travels
Readings and commands cross networks we don't control. They should travel encrypted, be accepted only from known devices and people, and carry enough integrity that tampering is detectable. Access inside the platform is by role — what an operator can do is not what an administrator can do — and sessions end when people walk away, rather than staying signed in for ever on a shared screen.
For the most sensitive sites, the strongest protection is not sending the data anywhere. The platform, including its AI, can run on the operator's own hardware, on their premises.
3 · A person decides
This is the principle we care about most, and it shapes the architecture rather than sitting on top of it:
- Proposals, not surprises. When the AI assistant concludes that something should change — a rule, a setting, a programme — it proposes the change in plain words, showing the current value and the new one, and waits for Allow, Allow for this conversation or Deny. Deleting and sharing always ask, every time.
- Changes that undo themselves. Monitoring programmes — a load test, a vibration watch, a quiet period — change how part of a site runs for a window, then put every setting back automatically.
- Reflexes that are rehearsed. An automatic rule ("when this happens, do that") can be dry-run against yesterday's data before it's switched on, so its behaviour is seen before it's trusted.
4 · Keep the record
Every change — who asked, what changed, when, and why — goes into an audit log and into the site's memory, where the next person on shift will see it in context. When a node applies a command, that becomes a memory naming the person or rule that asked for it. The story of a site is never something to piece together after an incident; it's already written.
AI that shows its work
An assistant that answers questions about physical equipment must be held to a higher standard than one that drafts emails. Ours answers from the data it reads, says under every answer where its numbers came from, and flags any number it couldn't find in that data instead of letting it pass. When it doesn't know, it says so.
Earned, not declared
No platform becomes trustworthy by announcing it. Trust is earned in pilots, measured against labelled faults and real incidents, and kept by being honest about what the system misses. That's how we intend to earn it.
Let's make sense of your site.
Tell us about a site — a plant, a dam, a campus, a cold store. We'll show you the platform on demo data like yours and plan a pilot with nodes on your equipment.