One core, many AI models: how a new use case stops being a new product

The most useful question a prospective customer asks us is never “what does your AI do?” It’s “can it see this?”

That question is usually asked defensively, because most of the market has trained people to expect a bad answer. Ask a fixed-function detection vendor for a second use case and you get a second box, a second install, a second contract and a second set of cameras. Ask a cloud-video platform and you get a bandwidth quote and a question about your uplink. Either way the answer is a new product, and the honest cost is the site visit.

We built Edgegenix the other way around: one runtime on the device in the field, and a library of models on top of it. This post is the technical spine of that, in plain language, and then three use cases with the actual path from pixel to outcome for each — including which of them is live today and which we’re still building.

The core, in four steps

Everything Edgegenix does in the field is the same four operations, in the same order, regardless of what the model is looking for.

1. Decode. A camera, a drone downlink or a sensor feed arrives and gets turned into frames. Not a special camera — the one already on the pole, the gate, the dozer, the shed. If it produces a standard stream, the core reads it. This step is boring and it is the reason the rest is cheap: nothing needs replacing.
2. Infer. The model runs on the device. There is no round trip to a data centre, which matters for two separate reasons that get confused with each other: latency (a decision in the time it takes to decide, not the time it takes to upload) and independence (the thing keeps working when the link doesn’t). Inference on-site also means raw imagery can stay on the customer’s own hardware.
3. Decide. A raw detection is not an event. The core applies rules and confidence thresholds — how many frames, how long, in which zone, at what score, during which hours — before anything is raised. This is where most of the field engineering actually lives, and where a demo becomes a system somebody trusts at 3am. Every output is advisory: the platform recommends, a person decides.
4. Sync. What leaves the site is the event — a timestamp, a location, a classification, two confidences, a keyframe — not a video river. A few kilobytes travels where gigabytes can’t, so the same design works on a fibre-fed substation and a haul road with one bar of LTE. When the link drops, events queue locally and reconcile when it returns.

One runtime, many models · the model library deploys over the air onto hardware already in the field; the four core stages never change; what changes is what the site can now see. · Open full size

Here is the part that matters commercially. Because the four stages don’t change, a new use case is a new model — not a new product. A model is a file. Files deploy over the air. No new hardware, no second install, no site visit.

Use case one — smoke and fire

Live in production

Powerline corridors, plant yards, forestry blocks, remote depots. The failure mode isn’t that nobody sees smoke — it’s that the person who sees it isn’t looking at the right monitor, and by the time a call is made the thing is no longer a one-truck problem.

The path. Fixed cameras on existing infrastructure → decode → a detection model trained on smoke and flame signatures, running on-site → decide (persistence across frames, zone masking so the same steam plume and the same access road don’t cry wolf twice a day, a confidence floor tuned per site) → sync an event with a keyframe to the operations console and to whoever is rostered.

The outcome. The clock that matters is the one between ignition and someone competent knowing. Compress that and everything downstream gets smaller: fewer trucks, less containment line, less loss. The counterfactual isn’t theoretical in this country.

No detection system prevents an asset failure. What it changes is the interval between the failure and the response — which is the interval where a fire is still cheap. This is the module we run in production today, and it’s the one that proved the core.

Use case two — wildlife on haul roads

In development

This one is a good illustration of why classification, not detection, is the valuable part.

An autonomous or semi-autonomous haulage fleet already detects obstacles — that is table stakes and it is deliberately conservative. An unclassified object in the path is a full stop, because the only safe assumption about an unknown obstacle is the worst one. That behaviour is correct. It is also, at a busy site, expensive: a kangaroo at dusk and a person in high-vis produce the same response, and the fleet doesn’t move again until a human resolves it.

The path. Cameras already on the vehicle or on the road furniture → decode → a classifier that distinguishes animal from person from vehicle from debris, on the vehicle → decide, and this is the whole point: a classified animal is an advisory; a person is an unconditional stop. The rule is deliberately asymmetric and the confidence threshold for “this is not a person” is set far higher than for anything else → sync the event so the pattern — which crossings, which hours, which weather — is visible to the people who plan the road.

The outcome. Two things, and the second is bigger than the first. Immediately: fewer full-stop events resolved by a human, which is availability recovered without loosening a single safety rule. Over a season: a map of where and when animals actually cross, which turns fencing, lighting and scheduling from guesswork into a decision. How many stops per shift and what each one costs is entirely site-specific — that’s the first number we’d work out with you, on your data, not ours.

Use case three — person down

In development

A worker alone in a shed, a pump house, a packing line, a remote yard. The dangerous gap isn’t the incident — it’s the hours between the incident and anyone noticing, which on a farm or a remote site can be the length of a shift.

The path. An existing camera in the space → decode → a model that detects a person and their posture, plus absence of motion, on-device → decide (a fall posture held past a threshold, or no movement in an occupied zone for longer than the work plausibly allows, with occupancy-aware rules so an empty shed is quiet and a lunch break isn’t an emergency) → sync an alert to a phone and a console, with a keyframe so the responder knows what they’re walking into.

The outcome. Someone knows at once instead of at shift change. That is the entire value proposition and it does not need embellishing. Worth being explicit about the design constraint: this runs on-device precisely because continuous video of workers should not leave the site. What leaves is an event.

What was the same in all three

Read those three back and notice what didn’t change. The cameras were already there. The networks were the ones the site already has. The compute was the same device. Decode, infer, decide, sync ran in the same order. What differed was the model file and the decision rules on top of it.

That is the platform claim, and it’s worth stating plainly because it’s the thing that changes a buying decision:

• The second use case costs a fraction of the first. The expensive part of an edge deployment is the site work — mounting, power, network, commissioning, integration. Do it once. Every model after that arrives over the air.
• You’re not betting on one detection. A site that installs for fire gets the option on everything else in the library later, without a forklift upgrade.
• Bandwidth stops being the constraint. Events instead of streams is what makes remote sites viable at all, and it’s why the cost curve doesn’t bend upwards with every camera you add.
• Sovereignty is architectural, not contractual. Inference happens on your hardware, in-country. That’s a property of where the compute sits, not a clause in an agreement.

So what does a fourth model actually take?

We’d rather answer this honestly than impressively, because the honest answer is what a pilot conversation should be built on.

Adding a use case is not free and it is not instant. It takes representative data from the environment it will run in — your site, your light, your dust, your weather, not a public dataset. It takes labelling, and then it takes the unglamorous part: field validation, where the model meets the six things nobody predicted and the decision rules get rewritten around them. The model is the fast bit. Making it trustworthy at 3am, unsupervised, is the work.

What the core buys you is that none of that work is hardware work. You’re not paying for a second deployment, and you’re not waiting for one. That is the difference between a use case being a project and a use case being a decision.

Where we are

Fire and smoke detection is live in production on the Edgegenix Edge AI Core. Wildlife on haul roads and person down are in development with partners — real work, not a roadmap slide, and not yet a shipped product. We say which is which every time, because the fastest way to lose a critical-infrastructure customer is to be vague about it once.

If you have a camera already on site and a thing you wish it could see, that’s the conversation. Bring the use case; we’ll tell you honestly whether it’s a model we can train, a rule we can write, or something that isn’t ready yet.

Edgegenix is a multi-industry operational-intelligence platform built in Australia. Edge AI runs detection on-asset in the field; Cloud AI is the operations console; ECIA connects them. Every detection the platform produces is advisory — a person makes the call.