Start with the right scope.
Map the requirements, define an initial product area and agree on a practical route from preparation to pilot.
Explore the approachShip management software
Vessel. Shore.One connected platform.
Technical management, procurement and vessel operations.
One connected direction for your entire fleet.
One platform. Different responsibilities. Technical teams Marine operations Procurement teams Ship managers
The connected maritime platformA complete view.
A complete view.
Not another disconnected system.
Follow the work from equipment and maintenance to purchasing, delivery and vessel records.
Keep every asset, job and decision connected.
Bring equipment, planned maintenance, defects and work orders into a structured technical record — from the engine room to the technical office.
Explore maintenance
OneMarisProduct previewMaintenance overview
WORKSPACEDue this week24
In progress08
Awaiting review03
| Recent work | Assigned to | Status |
|---|---|---|
| Main engine · 500-hour service | Engine team | In progress |
| Cooling system · Condition review | Chief engineer | For review |
| Deck machinery · Planned inspection | Deck team | Scheduled |
| Generator No. 2 · Filter renewal | Engine team | Completed |
Connected records · Assigned responsibilities · Activity history
Product scope & availability
Technical ManagementAssets, maintenance & work orders
Procurement & InventoryPurchasing, delivery & stock
Vessel OperationsVessel and operational records
HSEQ & ComplianceIncidents, audits & corrective actions
Crew ManagementPeople, qualifications & rotations
Drydock & ProjectsProjects, quotations & progress
Performance & EmissionsVoyage data, fuel & emissions
Fleet IntelligenceCross-vessel views & reporting
Technical Management, Procurement & Inventory and Vessel Operations form the core of the platform; the other areas describe the product direction. Contact OneMaris to confirm scope and availability for your operation.
From vessel to shoreDifferent responsibilities.
Different responsibilities.
One operational picture.
Keep the maintenance finding with the requisition, the delivery with the order, and the next action with its owner.
On boardWhere the work happens
The connected recordContext travels with the work
AshoreWhere teams support and decide
01
Clear ownership
Know who is responsible for the next step.
02
Connected context
Keep the original requirement in view.
03
Documented handovers
Retain the evidence behind an action.
04
A wider perspective
Follow a summary back to its source.
The implementation approachBuilt around your operation.
Built around your operation.
Not the other way around.
The starting point is your workflow: the people involved, the records they rely on and the decisions they need to make.
Data & integrationYour records.
Your records.
Their relationships intact.
A proposed migration approach that considers asset structures, work histories and the context behind the data.
Data & integration approachConnected from the source
Technical recordsAssets · Jobs · Supporting documents
Purchasing contextRequirements · Orders · Receipts
PrepareValidateConnect
People & adoptionDesigned for the team
Designed for the team
doing the work.
Role-based guidance and a phased implementation direction, shaped around the realities of ship and shore.
Training & adoption approach01 / UNDERSTAND
Map the workflow.
Identify the people, information and operational handovers.
02 / PREPARE
Start with a pilot.
Define responsibilities, prepare the records and test the scope.
03 / DEVELOP
Build on experience.
Use practical feedback to shape the next step.
Implementation, migration and support are scoped with your team.
ONEMARIS PERSPECTIVESThe work behind
The work behind
every voyage.
People, decisions and the information between them. A closer look at the work that connects vessel and shore.
Discover the platformTalk to OneMarisLet’s map
Let’s map
the way forward.
Tell us about your fleet and priorities.
Vessel. Shore. One platform.A more connected maritime operation.
Platform architectureConceptual view
Control, permission and traceability start in the platform’s shared layer.
The OneMaris architecture is designed to keep operational records, user permissions, change history and connected workflows under the same control model.
This page is a conceptual view of the product architecture. It is not an infrastructure topology, not a statement of security certification and not a statement of class approval.
Controlled operation modelPermission.
Permission.
State.
Trace.
Relation.
Who may act, what state the record is in, who changed it and when, and where the action came from — combined in one model.
Shared control servicesPermissioned Traceable Linked Controlled
Four properties every record is designed to carry.
Every action is evaluated in the user’s permission context.
Seeing a screen does not mean being able to change the record. Scopes can be configured by role, record type and operational context — technical department, procurement approval scope, voyage and bridge duties.
The actor and time of a change can be recorded.
Operation history (“what happened to this equipment or record?”) and the audit trail (“which user performed which action?”) are kept as two separate lines and are not used in place of each other. Record time is kept consistent so that vessel and office clocks do not break traceability.
Related records keep their source references.
Work order, requisition, purchase order, goods receipt, defect and voyage each keep their own identity; the relation is kept visible as the process moves on rather than dissolving into the next record.
Reading, changing and approving are not the same action.
View, search, open and review are separated from create, edit, submit, approve and cancel by a permission check. State transitions follow the business rules of each record type.
Record modelRecord lifecycle Locked states Controlled approvals Operation integrity Inventory movements Evidence and timeline
How a record lives, locks and is corrected.
A record is more than its current state.
Draft, submitted, reviewed or approved, active or issued, completed or closed — transitions are governed by the record type’s own rules.
Leave a new trace instead of rewriting history.
Certain decided commercial records — a received quotation, an issued purchase order, a posted goods receipt — are corrected through controlled new actions such as reversal or cancellation. The original record stays in history. This is not presented as a general rule for every record type.
Starting an action and deciding it can be separated.
Approval flows apply only to supported record types — requisition, purchase order and postponement. In the supported procurement flows the user who created a request cannot approve it. No approval step is claimed for other record types.
A half-finished action must not break the record chain.
Connected critical changes are designed to be handled as one operation: validate, apply the related changes, commit — or roll back. Resubmitting the same critical action, such as posting a goods receipt, must not create a duplicate record.
Stock is followed through its movement history.
Receipts, issues, returns and adjustments leave a traceable history from which the current quantity follows.
Evidence stays with the record; events read on one timeline.
Measurements, photos, documents and notes are attached to the same record, and events from separate record types are designed to merge into one history view of that record.
Context and directionVessel context PLATFORM DIRECTION PLATFORM DIRECTION AI control boundary See our approach
Vessel context today, wider boundaries as the platform grows.
A record does not lose the vessel it belongs to.
Equipment, work orders, defects, requisitions, voyages and certificates are kept with their vessel context; the context is part of the record’s identity.
Company and fleet boundaries.
Wider company and fleet data boundaries are part of the platform’s expansion architecture. Vessel and office use are intended to progress on a common record model.
Limited-connectivity design.
The assumption that a vessel’s connection may be slow, intermittent or limited is part of the product design. Recently viewed screens can be read without a connection; data entry requires a connection. An offline entry and synchronisation model is one of the platform’s technical development areas.
AI is not above the permission model.
The assistance layer reads permitted records, produces summaries and drafts and leaves the action to the user. Uncertain permission does not mean automatic permission: outside the known scope the outcome is block or review. This is defined as an architectural principle, not a security statement that every edge case has been verified.
See not only the outcome of an operation, but how it came to be.
Designed to support operational records and follow-up workflows related to ISM, SOLAS, MARPOL, STCW, GMDSS and PSC requirements — without claiming compliance on the operator’s behalf.