Custom builds
Each of our systems began as a specific organisational requirement.
The four systems on this site exist because a specific organisation had a specific question and no existing product addressed it. Where that is the case, the detection, alerting, field-verification and evidence components are already established, and development is confined to the requirement-specific elements.
Engagement types
Common engagement types.
A new application domain
Coastline change, canal and irrigation networks, encroachment on public land, crop-loss assessment, solar or wind asset inspection. The sensor and model differ; the processing pipeline is unchanged.
An existing system, adapted
One of the four products, but against your jurisdiction hierarchy, your report formats, your imagery contract or your on-premise infrastructure. This is the most frequent engagement type.
A detector trained on your data
Where imagery and labelled examples of the target feature already exist. We train and score a detector on it, and keep the human-review loop so it improves rather than plateaus.
A single defined study
A defined question over a defined area, delivered as data and a report rather than a running system. Where a recurring system is not required, the engagement is delivered as a study.
How it runs
Feasibility before commitment.
Feasibility is established before procurement rather than after it: the costly failure in this field is discovering that the imagery could never have answered the question.
Scope
A conversation about the decision you need to make, not the technology. What area, what change, how often, and who acts on the finding.
Feasibility
We check whether the available imagery can resolve the requirement at the revisit interval required. If it cannot, we say so at this stage rather than after a purchase order.
Pilot
A working demonstration over a real part of your jurisdiction, scored against ground truth you can verify. Fixed scope, fixed duration.
Build
The pilot becomes a system: alerting, field verification, reporting and the deployment model you require.
Hand over
Documentation, training for the officers who will run it, and data in open formats. Continued engagement after handover is optional and is not required by the architecture.
Scope
When a custom build is not the right approach.
- One of the four already does it
If your requirement is Forest Monitoring with different report formats, that is a configuration, not a build. It is identified as such at the scoping stage.
- The imagery cannot resolve it
Sub-metre optical will not reliably find a boundary pillar or read a vehicle number plate. No amount of model work fixes a sensor limit.
- Nobody is accountable for acting on the output
A monitoring system requires a designated owner for its alerts before deployment is worthwhile. The organisational half has to be real before the technical half is worth building.
Describe the decision the system must support.
The system follows from the decision more often than the other way round.