In development

OpsMar — a local-first ship-operations hub

OpsMar is a ship-operations system for a single vessel, which I'm developing. 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.

In development 100% local model This ship's corpus only Tailnet-only surface

OpsMar Today board: the ship's digital twin — bunkers remaining, last loading condition, engine log, operations status, next port call and a 'needs you' row of drifts and failed jobs — **Today board.** Bunkers remaining, last loading condition, engine log and open items — assembled deterministically, with no model in the loop. The “needs you” row lists fuel-performance drift and failed jobs.

What it does

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.

Answers the whole crew can see

One shared channel. The crew talk to each other and, by naming the assistant, ask it a question — 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

Examples of artifacts 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.

How it differs from a horizontal AI platform

Several sovereign, on-premise “knowledge platforms” exist for industry. The differences relevant to a ship:

OpsMarBuilt by a serving master mariner; the domain model is the system.

Horizontal platformBuilt by software teams; the domain is a connector and a landing page.

OpsMarNumeric answers computed by a ship-performance model.

Horizontal platformRetrieval over documents; no ship physics.

OpsMarCommissioned to one vessel's documents and calibration.

Horizontal platformOne connector template applied across industries.

Measured results

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

2.5–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 →

cited

Answers trace to a document pageCorpus answers carry a [doc p.N] citation to the source page; when the corpus can't answer, OpsMar says so.

local

No third-party cloudThe stack runs at the edge on one GPU workstation aboard (RTX 4080-class), on the ship's own network. Data does not leave the ship by design, not by policy.

27 yr

Built by a master marinerQuantitative research in weather routing and ship performance. About SL Mar →

Local models (qwen3:14b · qwen3-coder:30b)RTZ routingSMS & regulations corpus Noon-report performance fitDeterministic tool callsPage-cited answersTailscale / LAN only