Beta testing

From ship's proprietary data to operational insights.

OpsMar is a ship-operations system for a single vessel, now in beta testing aboard. It runs at the edge, on one GPU workstation aboard (an RTX 4080-class machine), the model, the search and the documents all stay on the ship, nothing is sent to an external cloud. It answers over the ship's own corpus: manuals, SMS, noon reports, routes and calibration. I build it and use it in my own work as a master mariner. It is not sold as software, it stands here as evidence of the ship-operations and performance work I take on, on which I am open to consulting.

Beta testing 100% local model This ship's corpus only Tailnet-only surface

OpsMar Main board: the ship at a glance, passage and ETA, drafts with the hull drawn at its trim, sea state and weather rose, last ingested noon report / stability condition / engine log, condition weights, bunkers remaining per grade, bridge-app reachability, event log and pinboard — **The Main board.** The ship at a glance, passage and last-known ETA, drafts with the hull drawn at its actual trim, sea state, the last ingested noon report / stability condition / engine log, bunkers remaining per grade, and a pinboard of the artifacts in hand. Assembled deterministically, with no model in the loop. Filenames shown are anonymised.

What it does

Three things, fitted to one ship

Developed on a real vessel's operational data. Three functions:

Search the vessel's corpus

Plain-language queries over the ship's manuals, drawings, noon reports and history. Each answer carries a citation to the source document and page; when the corpus does not hold the answer, it says so rather than inventing one.

Compute from the ship model

Voyage, fuel and performance figures come from the same ship-performance and routing engine used in WindMar, not from summarising a document. Figures are deterministic and traceable.

Fitted to one vessel

The corpus, calibration and surfaces are specific to a single ship. This per-vessel commissioning is the work a horizontal AI platform does not do.

OpsMar databases grid: the ship's own corpus, SMS, equipment manuals, RTZ route library, conventions library, ship knowledge base, calibration dataset, port calls, voyages, risk assessments, each with an item count — **The ship's databases.** SMS, makers' manuals, route library, calibration dataset, port calls, risk register, each with its item count. This per-vessel corpus is what a horizontal platform does not assemble.

Agentic planning

Plan a passage by asking

One line, “study Algeciras to New York, laden, departure tomorrow noon, 13 knots”, and the assistant calls the routing tools itself: it builds the voyage from the route library, runs a baseline and a weather-optimised isochrone, and leaves a passage brief and a map in the Voyages track. The numbers come from the ship-performance engine, not from prose.

OpsMar chat: a plain-language request to study an Algeciras to New York passage triggers the assistant to call create_voyage_from_route and list_routes, then report an optimisation complete with distance, hours, fuel and ETA, and 0.9% fuel saved versus the direct baseline — **The ask → agentic tool calls.** The request drives deterministic `create_voyage_from_route` / `list_routes` calls; the reply reports the optimised leg, distance, hours, fuel, ETA, and the saving versus the direct baseline.

OpsMar Voyages: the planned Gibraltar TSS to New York Pilot passage with the optimised great-circle track over the North Atlantic, a baseline-versus-optimised route table (fuel, passage hours, distance, max roll) and speed / wind / wave / current profiles along the leg — **The voyage on record.** The optimised track over the North Atlantic, a baseline-vs-optimised table (fuel, passage time, distance, max roll) and speed / wind / wave / current profiles along the leg, kept as a planning record, verified on the bridge.

3,178 nm

Optimised distance

188.4 MT

Fuel, optimised leg

−3.9 h

Passage vs baseline

126

Passage legs decomposed

Ship model

A performance model fitted to this hull, and checked against reality

Every noon report the crew ingests is scored against the vessel's own performance model: predicted fuel versus what the ship actually burned, leg by leg. Where ERA5 reanalysis covers the track, the replay is the real model error; elsewhere it falls back to the logged weather. A candidate model is only ever staged, the officer promotes it, nothing auto-deploys, and nothing leaves the ship.

OpsMar performance model: a predicted-versus-actual fuel scatter across the vessel's noon legs with an ERA5-covered subset highlighted, headline errors (ERA5 MAE 1.41 MT/d, overall 2.75 MT/d), a GREEN held-out verdict, and a condition heatmap of where the model is wrong by loading and sea state — **Replay report, predicted vs actual.** The fuel scatter across the ship's noon legs with the ERA5-covered subset called out, a held-out verdict, and a condition heatmap (ballast / laden × calm / moderate / rough) showing exactly where the model is weak. Diagnosis first, never promote on one bucket. Figures are from a reference vessel.

1.41 MT/d

ERA5 held-out MAE

Knowledge graph

Regulation as a graph you can query

The conventions and the ship's own instruments are held as a typed graph, not a flat pile of PDFs: SOLAS, MARPOL, the ISM, IBC and IGF Codes, ISGOTT, STCW, the Polar Code and the IMO resolutions, linked by what they actually do to one another, requires, amended by, supersedes, implements, refers to. You can ask a question and be answered only from the graph shown, so every claim traces to a node.

OpsMar Lens regulatory reference map: 67 documents and instruments drawn as a network of 67 nodes and 150 typed links, edges coloured by relationship (supersedes, amended by, requires, implements, refers to), with a superseded/amended flag on affected nodes — **Regulatory reference map (Lens).** 67 instruments, 150 typed links, edges coloured by relationship; superseded or amended instruments are flagged. The public instruments read plainly, SOLAS, MARPOL, the ISM and IBC Codes, ISGOTT, STCW, the Polar Code and the IMO resolutions; the ship's own private documents are softened. “Ask the map” answers only from what is shown.

Relationship types

CII · EU-ETS · FuelEU

Emissions, computed and audit-ready

The same noon-report accrual that feeds the performance model rolls up into the regulatory carbon picture: a per-day CO₂e ledger built from the clean daily records, then read through each regime's own scope mask, CII rating against the IMO reference line, EU-ETS scoped tonnes and EUA cost, and the FuelEU intensity and penalty. Every figure is an estimate the ship can see early; the appointed verifier owns the legal filing.

OpsMar environmental report for a reference vessel: an environmental fingerprint, a 'how these numbers are built' provenance chain from noon reports to per-year CO2e, and per-year CII rating, EU-ETS scoped tonnes and EUA cost, and FuelEU intensity and penalty — **Environmental report (reference vessel).** Built from the noon-report accrual, CII rating against the IMO reference line, EU-ETS scoped tonnes and EUA cost, FuelEU intensity and penalty, each traceable back to the daily records. Marked *ESTIMATE until verified, the verifier owns the legal figures*. Ship name hidden.

4 regimes

CII · EU-ETS · UK-ETS · FuelEU

Shared surface

Answers the whole crew can see

One shared channel. The crew talk to each other and, by naming OM, the ship's own local AI assistant, put a question to it; the answer is posted for everyone, cited to the ship's own guides, and always flagged as a draft for an officer to check. Only that mention calls the model; the rest is ordinary crew chat, and all of it stays on the ship.

OpsMar crew channel: the crew ask the assistant for a risk assessment and a port-call schedule; each answer is posted to the shared channel with citations to the ship's own guides and flagged as a draft for review — **The crew channel.** A cited risk-assessment draft, a port-call schedule, and plain crew chat in one shared surface, a local alternative to a group-messaging app, with the assistant available to all but the model running on the ship. Names shown are illustrative.

Worked outputs

Artifacts from the ship model

Examples of what OpsMar produces from the ship model. Figures below are from a reference (anonymised) vessel, not a named ship.

Loading plan for a reference MR tanker: stowage plan across 16 tanks, drafts, IMO stability criteria all passing, and longitudinal strength (shear force and bending moment within allowable limits) — **Loading plan (reference tanker).** Deterministic stowage across 16 tanks with drafts, all IMO intact-stability criteria passing, and shear-force / bending-moment within allowable limits. The ship's approved loadicator remains authoritative; this is planning support.

OpsMar port call brief for a reference call: schedule and berth, crew relief, spares expected, visitors, operations, contacts and outstanding actions, in a fixed paradigm — **Port call brief.** Assembled into a fixed paradigm, schedule & berth, crew relief, spares, visitors, operations, contacts, actions, from voice, typing, email or a photo of a handwritten note. The OCR transcribes and the model organises; neither invents, and unstated fields are shown as “not stated”. Names shown are illustrative.

Hull biofouling growth curve: added shaft power rising to +12.2% over 351 tracked days, flagged STALE and PROVISIONAL pending ISO-19030 calibration — **Biofouling growth curve.** Added shaft power from tracked exposure, flagged STALE when the input is behind and PROVISIONAL until ISO-19030 calibration.

Mooring pre-plan at a reference terminal: 14 lines, peak 10.2% MBL, starboard alongside, with wind vectors over a 48-hour window; marked not OCIMF-validated — **Mooring pre-plan.** Line pattern and peak line load (% MBL) over a 48-hour wind window from WindMar. Marked *not OCIMF-validated*, a planning aid, confirmed on the berth.

Engineering layer

Built in the open, on the ship

OpsMar is not a closed appliance. It carries its own engineering surface, an editor and a local coding agent (qwen3-coder, running on the same workstation), so the system can be extended and repaired at the edge, against the ship's own repositories, without a connection ashore.

OpsMar engineering surface: a code editor with the project tree and a local coding-agent panel, editing a research script, the layer used to extend and maintain the system on the ship's own GPU workstation — **The engineering surface.** Editor, project tree and a local coding agent, the layer used to extend and maintain OpsMar at the edge, on the ship's own machine.

Evidence

Measured results

OpsMar is in beta. The routing and performance engine it uses is further along, with published figures:

2.5 to 6.0%

Fuel reduction, feeder route study (WindMar v0.2.3)Range across cases vs. the baseline route, one leg saving ~8.4 MT. Published with the per-case numbers. Feeder routing study →

Local models (qwen3:14b · qwen3-coder:30b)RTZ routing & isochrone optimisationSMS & regulations knowledge graph Noon-report performance fitERA5 walk-forward replayDeterministic tool callsPage-cited answersTailscale / LAN only