Kimedes finds water leaks from orbit. Most of what we learn doing that never leaves the company. It sits in project reports, in code review, in a slide someone made for a council meeting. This is where some of it will live in public instead.
There are three sections, and the split is not decorative. Different people need different things from us, and asking them all to read the same post serves none of them.
Research
The science. SAR and InSAR methods, model results, what we tried on funded projects and what did not work. Written for someone who could reproduce it, or argue with it.
Product
Syracusa. What we ship, what each module does, and what an operator can actually do with it on a Tuesday morning. Written for the person who has to justify the tool inside their own organisation.
Engineering
How it is built. Architecture, the processing engine, the decisions behind moving satellite imagery at scale. Written for engineers, including the ones who do not work here.
What you will not find
No figure that has not been verified. If we cannot source it, it does not go in a post, even when the rounder number would read better.
No case study written as a testimonial. When a client’s network appears, it appears as evidence, with the method attached.
No publishing schedule. We post when there is something to say. A blog that ships on a calendar ends up writing to fill the calendar, and you can tell which posts those are.
The tone, since you will notice it anyway
Short sentences. One idea each. We would rather understate a result and have it hold than oversell it and spend the next meeting walking it back. Where something is uncertain, the post says so.
Most leaks are found when they surface. The interesting work happens before that.
Start with Product if you want to know what we build. Start with Research if you want to know whether it works.
