Services
Teams whose problem is not an off-the-shelf workflow
When the instrument is not the hard part
Most seismic software consultants adapt generic tools to your problem. Our seismologists and engineers start from the physics. What we build is correct by design, not by approximation.
The problem
Generic tools, adapted until they nearly fit
The usual options are a consultancy bending a general-purpose toolkit to your problem, or a software team treating seismology as a data-processing exercise. Both produce something that works on the demo and breaks on the edge cases. The edge cases are physics, and the physics was never the starting point.
Where we usually start
We work across the full stack. Real-time processing plugins on the sensor edge. Acquisition and post-processing pipelines. The dashboards and reporting that turn a result into a decision.
- 01Detection
Neural-network phase pickers scan your waveform archive continuously, recovering microseismic events that template matching or manual review miss. How far down the completeness magnitude goes depends on your station geometry and noise environment, not on the picker — we will tell you what your array can support before you commit. This runs on your archive; on-sensor phase detection is still in development.
PhaseNet · EQTransformer · SeisBench - 02Localization
From single-array to multi-network geometries, we produce high-resolution hypocenter catalogs with calibrated uncertainty — tracking induced seismicity migration during injection, or mapping fault structures at regional scale.
Calibrated uncertainty · migration tracking - 03Characterisation
Source mechanisms through full moment tensor inversion or finite fault models, plus standard magnitude and stress-drop parameters — delivered in the formats your reporting already expects.
QuakeML · StationXML · publication-ready figures
What you are left with
Not a framework you then have to adapt. Each engagement is scoped to your archive, your station geometry and your reporting obligations.
QuakeML catalogs, StationXML metadata, MiniSEED waveforms. What we build hands off to whatever you already run, and to whoever maintains it next.
Processing plugins run on customizable firmware. Project-specific code stays portable, documented, and separate from the standard acquisition and data interfaces.
How an engagement runs
- 01Scope against real data
We start from a sample of your archive and the question you actually need answered. If an off-the-shelf tool solves it, we will say so.
- 02Build and validate together
Work runs against your data throughout, with your team seeing intermediate results rather than a delivery at the end.
- 03Hand over something maintainable
Standard formats, documented interfaces and code your people can read — so the work outlives the engagement.
Typical engagements
- Sensor firmware plugins
- Automated earthquake catalogs
- Geothermal injection monitoring pipelines
- Structural health monitoring dashboards
- Seismological algorithms integrated into existing institutional software
Questions we get asked
Seismologists who use it. Our CTO is lead author of the peer-reviewed method behind SeismiQ Catalog, a core developer of Pyrocko, and a researcher at GFZ Potsdam. Our CEO builds signal-processing and deep-learning systems for embedded fleets. Engagements are not handed to a generalist contractor.
Tell us what the data has to answer.
Send a description of the problem and, if you can, a sample of the archive. We will tell you what it would take, including when an existing tool already does it.