Offerings and example engagements for Ship owning and management — not published client case studies.
Why · How · What
Why
A vessel generates operational, technical, commercial and regulatory data on four different clocks, into four different systems, owned by four different departments. Emissions regulation has made that fragmentation expensive.
How
Start where the noon report, the flow meter, the bunker delivery note and the ledger disagree. That gap is the compliance problem.
What
Fleet and voyage data integration, emissions and compliance reporting pipelines, PMS and procurement integration, ERP, charter-party data exchange, fleet analytics, cloud and observability.
Why this matters now
2026 is the year three rulebooks bite at once. EU ETS coverage reached 100% of covered emissions from 1 January 2026, with methane and nitrous oxide added alongside CO₂. The first FuelEU Maritime report was due to a verifier on 31 January 2026, covering the 2025 reporting year. IMO CII applies to ships of 5,000 GT and above, and a vessel rated D for three consecutive years or E for a single year must submit a corrective action plan, with required intensity tightening to roughly 11% below the 2019 baseline this year.
They measure different things with different boundaries, and optimising for one can quietly make another worse. A decision that flatters a CII rating may do little for the ETS bill, and a fuel switch that helps FuelEU can be the wrong lever for CII. A fourth layer is coming: the IMO approved a global GHG pricing mechanism in principle at MEPC 83 in April 2025, with formal adoption adjourned by a year at the October 2025 session and entry into force expected around 2027.
Scopes of work
Example engagement — illustrative. Typical scopes of work, not named client case studies.
One model that speaks all three rulebooks
Why it happens
Each regulation arrived separately and was absorbed by whichever team was closest — sustainability took CII, finance took ETS, operations took FuelEU. Three spreadsheets grew from three extracts, and none reconciles to the others, so nobody can answer what a proposed voyage costs across all three.
How we work it
We build a bottom-up voyage dataset from noon reports, flow meters, bunker delivery notes and AIS, reconciled against each other with the disagreements surfaced rather than averaged away. Each regulatory calculation runs over that same base data with its own boundary rules, the trade-off between the three is exposed for a proposed decision, and every calculation is versioned so a past submission can be reproduced exactly.
What you end up with
One reconciled voyage dataset serving all three calculations, trade-offs visible per decision, and every past submission reproducible.
Noon reports, flow meters and the bunker note disagree
Why it happens
Each measurement was designed for a different purpose and a different audience, and until allowances were bought against consumption the differences did not matter enough to resolve. Now they are financially material and nobody has a defensible source hierarchy.
How we work it
We reconcile noon report, flow meter and bunker delivery note per voyage leg and classify variances by vessel, fuel type and reporting officer, separating systematic bias from random error. Reporting completeness and timeliness are instrumented per vessel, and verified figures are carried forward rather than convenient ones.
What you end up with
Per-vessel variance analysis separating bias from noise, completeness and timeliness instrumented, and a documented source hierarchy.
Charter-party data exchange has become contractual
Why it happens
Charterers and owners have tightened clauses on data exchange, reimbursement and reconciliation, particularly where vessels move between EU and non-EU trading or a voyage profile changes mid-charter. The clauses are contractual; the data satisfying them is still assembled by email.
How we work it
We model what each clause requires and when, then build the exchange as a defined interface with charterers rather than an attachment. Allocated cost is reconciled against clause terms per voyage, a per-charter statement is produced with its underlying evidence attached, and disputes are instrumented by cause.
What you end up with
A defined data interface per charter with reconciliation against clause terms, and disputes attributed to cause rather than argued from spreadsheets.
Technical management systems arrived with acquisitions, fleet segments or managers, each configured to its own equipment hierarchy. Nobody chose fragmentation; it accumulated. The consequence is that maintenance history and spares data cannot be compared across the fleet, and procurement cannot see aggregate demand.
How we work it
We define a canonical equipment, component and job model and map each PMS to it, including the hierarchies that genuinely differ. Integration with ERP purchasing gives requisitions consistent identity, spares demand is aggregated across the fleet to expose consolidation, and each PMS stays the local system of record rather than being replaced.
What you end up with
A canonical technical model giving fleet-wide comparability, aggregated spares demand visible to procurement, and local systems untouched.
Vessel-to-shore bandwidth is constrained and costed per megabyte, and transfer was designed around what fits rather than what matters. Reports arrive late, incomplete, or not at all, and shore systems keep working on stale figures without indicating that they are stale.
How we work it
We classify data by the latency the shore side actually requires rather than by system of origin, and prioritise and compress accordingly. Transfer becomes resumable and idempotent so a dropped link does not lose a report. Per-vessel arrival completeness and lag are instrumented, and alerting is on staleness rather than transfer failure, because staleness is the business consequence.
What you end up with
Prioritised resumable transfer inside the bandwidth budget, with completeness and lag instrumented per vessel and staleness alerted.
Verification requires a trail from raw measurement to submitted figure, but the reporting process was built to produce the figure, not the trail. So the trail is reconstructed each year from emails and spreadsheet versions, which inflates administrative cost and increases the risk of a finding.
How we work it
Provenance is captured at ingest for every input, and every calculation is versioned so a figure can be reproduced with the logic that produced it. Approval and correction history is retained with timestamps, the verifier’s pack is generated from the system rather than assembled, and a mock verification runs mid-year to find gaps while there is still time to close them.
What you end up with
A reproducible trail from raw input to submitted figure, a generated verifier pack, and gaps found at a rehearsal.
