Controlled deployment across secure deep-sea basins.
Deploy within governed maritime zones, enforce survey boundaries, and keep an audit-ready view of what the system did, where it stopped, who approved it and how it rolls back.
You define the expedition boundary.
Three ways to put the same array in the water. The engine, the budget and the log are identical; what changes is who holds the watch.
- 01Maximum control
Own vessel
Bathys runs on your research vessel. Hardware, relay plan and console stay inside your survey boundary; we provide the array and the engine.
- Buoy-ready instances in < 2 min
- Offline-capable console
- Encrypted uplink when in range
- 02Governed
Managed station
Deploy from a Bathys-operated ocean station. Policy enforcement, telemetry integrity and operational isolation are contractually defined.
- Shared relay mesh
- Audit-ready logs
- Seasonal maintenance included
- 03Extend
Hybrid
Your vessel deploys, a managed station keeps watch between expeditions. The topology is one array; the responsibility boundary is explicit.
- Handover protocol
- Dual console access
- Governed model updates
You define the expedition boundary.
Run Bathys from your own research vessel for maximum control, or extend across managed ocean stations without compromising policy enforcement, telemetry integrity, or operational isolation.
- Buoy-ready instances deploy in < 2 mins
- End-to-end encrypted telemetry streams
- Governed model updates via secure CLI
Built for governed operator control.
Interact with Bathys through terminal workflows, deterministic scripts, or API surfaces designed for repeatable control, auditability, and high-confidence operational automation.
- Comprehensive local CLI environment
- Inject dynamic parameters into live models
- High-throughput WebSocket SDKs
What the system does, where it stops, who approves, how it rolls back.
Five automated behaviours, each with its permissions, approval, output, audit trail, exception path and rollback. Open a row; nothing here is hidden behind vague copy.
01 Autonomous ballast release Releases ballast on a mooring when a cascaded pressure threshold is crossed inside the warning window.
- Permissions
- Policy armed by an operator with the Rules role; Survey tier requires arming per event.
- Action
- Ballast released, ascent profile started, relay path pinned.
- Approval
- None inside the window — that is the point. An operator hold placed before the threshold always wins.
- Output
- Event closed with the rule that fired, the readings that triggered it and the minutes of lead it had.
- Audit
- Immutable log entry, exportable; the hold and the release are both recorded.
- Exception
- Relay loss: the policy still executes locally on the hull and reports when the link returns.
- Rollback
- Ballast cannot be un-released; the mooring is recovered on the next cycle. The policy itself can be disarmed in one command.
02 Model rollout Applies a new version of thermocline_alpha, salinity anomaly detection or pressure mapping to a deployment.
- Permissions
- Models role through the secure CLI; key bound to one programme.
- Action
- Version pulled, run in shadow-sm mode next to the current model.
- Approval
- Explicit apply by an operator after reviewing the shadow-sm diff.
- Output
- Versioned model active, previous version kept warm.
- Audit
- Version, diff, who applied it and when.
- Exception
- Shadow divergence above the tolerance blocks the apply and opens a review event.
- Rollback
- One command restores the previous version; events already opened keep their model tag.
03 Acoustic relay re-route Replaces a noisy short hop by a cleaner longer one to keep the array inside the 12 ms budget.
- Permissions
- Automatic; no operator role needed.
- Action
- Path pinned for the affected moorings.
- Approval
- None. The re-route is reversible and visible on the topology.
- Output
- New latency printed on the topology map, event only if the budget is exceeded.
- Audit
- Every re-route logged with before / after latency.
- Exception
- No clean path: the mooring is flagged "degraded" and readings are timestamped on-hull until the link recovers.
- Rollback
- Automatic when the original hop is clean again for ten minutes.
04 Survey boundary enforcement Keeps moorings, relays and the console inside the maritime zone defined for the expedition.
- Permissions
- Boundary defined by the programme lead at topology planning; changes need the same role.
- Action
- Deployment plan refused outside the polygon; drifting instruments raise a boundary event.
- Approval
- Boundary changes are applied by the programme lead only.
- Output
- Boundary shown on the topology, drift events with distance and bearing.
- Audit
- Every boundary version kept with the plan that used it.
- Exception
- A recovered mooring outside the boundary is quarantined from the topology until an operator re-admits it.
- Rollback
- Previous boundary restorable; deployments made under it stay valid.
05 Data export Exports telemetry, events, logs and bathymetry contributions to the programme.
- Permissions
- Data role; scoped to the programme that owns the data.
- Action
- CSV or API export, SIEM feed on Fleet.
- Approval
- None for the owning programme; a second programme needs written consent recorded in the log.
- Output
- Signed archive with the model versions and topology in force.
- Audit
- Who exported what, when, to where.
- Exception
- Export of anonymized array statistics is opt-out per programme and stops immediately when disabled.
- Rollback
- Not applicable — exports are copies. Consent can be withdrawn and future exports stop.
Controls tied to concrete risks.
No badges, no acronyms we cannot back. Four design facts about how the array protects a programme’s data, and the contract clause each one maps to.
-
Encrypted end to end
Telemetry is encrypted on the hull before the first acoustic hop and stays encrypted through the relay mesh and the uplink. Keys are per programme; a managed station cannot read a neighbour’s stream.
-
Roles, not accounts
Rules, Models, Data and Programme-lead roles; every console action carries the role that performed it. Fleet contracts map roles to your identity provider.
-
A log you cannot edit
The system log is append-only and exportable. Two states of the array can be diffed; nothing is rewritten, including operator holds and refused deployments.
-
Isolation by contract
Managed stations run programmes on a shared mesh with defined isolation; Fleet programmes get a dedicated mesh. The boundary is written in the contract, not assumed.
Security questionnaires and a review call with your team are part of Expedition on request and included in Fleet. See the comparison.
From first call to live telemetry.
Typical lead time is one season. The shadow-sm deployment is free and the survey boundary is yours.
- 01
Shadow deployment
Weeks 1–3 · no hardware
The engine runs against your existing telemetry or a historical export. You receive every event it would have opened, with its lead time, and a report you keep.
- 02
Survey boundary and topology plan
Week 4 · programme lead
Depth range, mooring count, relay plan and the maritime polygon the array must respect. The plan is versioned from day one.
- 03
Mooring provisioning and vacuum bench
Weeks 5–8 · Bathys workshop
Hulls pressure-tested, hydrophones calibrated against the reference ping, batteries fitted, keys issued per programme.
- 04
Deployment cycle
36 h per mooring pair · your vessel or ours
Moorings lowered, relays placed, each hop measured against the 12 ms budget before the next pair goes in.
- 05
Live telemetry and governed rollout
Season 1 onwards
The console is live, models are applied in shadow-sm mode first, and the watch is kept by you, by the station, or by both under the handover protocol.
Start with a shadow-sm deployment.
No hardware, no risk: we run the engine against your existing telemetry and show you what it would have flagged. The report is yours whether or not you continue.