Short notes on method, written by the people who build the systems. No announcements, no
customers named, no results from anybody's deployment. Just the reasoning behind decisions that
are otherwise invisible from the outside of a product page.
· PHAROS · Method
The circle on the datasheet is not the coverage.
Every sensor sold for coastal surveillance comes with a range. Ten kilometres, eighteen,
thirty. Put a hundred of them on a map at the ranges in the brochure and the coast is
covered twice over. That map is the reason gaps get discovered by the thing that crossed
the barrier rather than by the plan.
A range figure is a statement about the sensor in open water. It is not a statement about
the water in front of this buoy. A headland, a sandbank, a shipping channel with the wrong
bottom profile, and the usable footprint stops being a circle and becomes a polygon with
bites taken out of it. So PHAROS never draws the circle. It walks the depth profile out
along every azimuth from the node, finds where the geometry stops the sensor, and returns
the polygon that survives.
The second correction matters as much. Where a radar footprint and a sonar footprint
overlap, most planning tools take the union and report the larger area as protected. That
is backwards for the question a coastguard is actually asking. A sonar contact is worth
something operationally where the radar picture is also clear, because that is where the
contact can be resolved and acted on. Protected water is the intersection. Take the union
and you overstate the coast, sometimes by a factor that would embarrass anybody who signed
the layout.
The consequence is uncomfortable and correct: a barrier that looked continuous on a range
map usually is not, and the number of nodes needed to close it honestly is higher than the
first budget assumed. We would rather have that argument at the planning table than after
an incident review.
The same masking pass feeds the maintenance model. Once you know which polygon each node
actually contributes, you know which node failing opens a hole and which one merely thins
an overlap, and the boat gets routed to the first kind before the gap opens.
· TerraScan · Method
A composite score is only worth having if it comes apart.
Every risk product eventually produces a single number per unit of territory. It has to.
A county council with ninety localities cannot read forty indicators for each of them, and
a ranking is the only artefact that turns imagery into an order of work.
The failure mode is well known. The number gets built by weighting a dozen indicators
together, the weights come from a workshop nobody wrote down, and six months later a mayor
asks why their locality scores 71 while the neighbouring one scores 48. If the honest answer
is that the model says so, the score is finished as an instrument. It will be quietly
ignored from that day, and the imagery behind it will have been wasted.
So we build the score to be taken apart on demand. Every composite in TerraScan carries the
indicator values that produced it, the normalisation applied to each, the weight it received
and the contribution in points that weight bought. Open a score of 71 and you get the
sentence that matters: vegetation dryness and exposure account for 44 of those points, and
both were measured on the pass eleven days ago.
Two rules keep it usable. Weights are configuration, not code, and they are visible to the
customer who lives with the consequences. And a missing indicator is never silently treated
as a zero or filled from a regional average. It is declared missing, the composite says it
is computed on incomplete evidence, and the ranking makes clear which units are being
compared on less information than the rest.
It costs a slightly less confident headline number. It buys a score that survives its first
serious challenge, which is the only property that matters, because a prioritisation
instrument nobody trusts prioritises nothing.
· Across the products · Principle
Measured, computed, estimated: the label belongs on the number.
An operations screen shows a state of charge of 46 per cent. Somewhere else it shows a
projected 12 per cent at the end of the shift. The two numbers sit in the same table, in the
same font, and one of them was read off a vehicle two minutes ago while the other is the
output of a consumption model that has never seen this route in February.
Presenting them identically is the most common lie in operational software, and it is
usually accidental. Nobody decided to hide the difference. It just never had anywhere to
live, because provenance was treated as metadata for the data engineers rather than as part
of what the value is.
In our products it is part of the value. Every operational figure carries one of three
labels and the interface shows it: measured, it came from a sensor or a record, with its
timestamp; computed, it is a deterministic function of measured inputs, and the function can
be opened; estimated, a model produced it, and the model states its assumptions and its error.
The discipline pays for itself in three places. Operators calibrate their trust correctly
instead of uniformly, which is the difference between using a projection and ignoring the
whole screen. Disagreements between two upstream systems become visible as disagreements
rather than being resolved silently by whichever pipeline wrote last. And when a decision is
reviewed a year later, the log says not only what was recommended but on what class of
evidence, which is what a defensible decision actually means.
It also makes the gaps impossible to hide from ourselves. A screen where most values are
marked estimated is a screen telling its own builders where the next integration has to go.
Book a briefing
Disagree with any of this?
These notes describe choices, and a choice can be wrong. If you plan barriers, score
territories or run an electric fleet and you read one of these differently, we would
rather hear it than not.
Notes are dated on publication and are not edited afterwards. Corrections are published as new notes.