Application Overview

What the Domestic Vessel Safety Management System models, and why it is structured the way it is.

The Domestic Vessel Safety Management System (VESSELSAFETY) is a demonstration prototype of the operational Safety Management System required for an Australian domestic commercial vessel. It is built from the domestic_vessel_sms proforma pack and is grounded in Marine Order 504 (Certificates of operation – national law) 2024 (commenced 1 June 2025) and the AMSA Guidelines and templates for a Safety Management System. It contains no real vessel, crew or regulatory data and is not legal or regulatory advice.

The core operating chain

The 54 models follow one operating cycle, and the menu mirrors it:

Vessel & operating context   Organisation → Vessel → OperatingArea →
                             CertificateType → VesselCertificate
      │
      ▼
SMS & authority              SafetyManagementSystem → SmsSection / SmsRevision;
                             Role → PersonRole → StatementOfAuthority
      │
      ▼
Crew competence              Person → QualificationType → PersonQualification;
                             TrainingCourse → TrainingRecord; Induction;
                             CrewingAssessment
      │
      ▼
Fitness & fatigue            FatigueRiskManagementPlan → WorkRestRecord →
                             FitnessForDutyDeclaration; DrugAlcoholPolicy
      │
      ▼
Hazards & controls           Hazard → RiskAssessment → RiskControl;
                             ManagementOfChange
      │
      ▼
Procedures & emergency       Procedure → ProcedureAcknowledgement;
                             EmergencyPlan → EmergencyDrill
      │
      ▼
Maintenance & inspections    MaintenanceItem → MaintenancePlan → MaintenanceWork;
                             Defect; InspectionTemplate → InspectionTemplateItem →
                             VesselInspection → InspectionResult
      │
      ▼
Voyage execution             Voyage → VoyageReadiness / CrewAssignment /
                             PassengerRecord / VesselLogEntry
      │
      ▼
Incident & action            Incident → IncidentInvestigation → CorrectiveAction
      │
      ▼
Assurance & review           Audit → AuditFinding; SmsReview; Document; Evidence;
                             ConsultationRecord; Notification

The design separations that matter

The model deliberately keeps apart things that are easy to conflate but must not be, because each separation preserves a link in the evidence chain:

A thing existing	… is separate from	Modelled as
a certificate	its being verified and current	`VesselCertificate.verification_status` + `verified_by_person_id`
a crew assignment	the person being qualified and fit	`CrewAssignment` vs `PersonQualification` + `FitnessForDutyDeclaration`
a documented procedure	crew acknowledgement of it	`Procedure` vs `ProcedureAcknowledgement`
physical maintenance completion	defect verification	`MaintenanceWork` vs `Defect` (status → verified)
incident reporting	investigation and corrective action	`Incident` → `IncidentInvestigation` → `CorrectiveAction`
an SMS review	the revision it may trigger	`SmsReview.revision_required` → `SmsRevision`

Readiness is a gate, not a checkbox

A Voyage is gated by a VoyageReadiness assessment covering certificates, crewing, fitness, maintenance, defects, LSA/FFE, navigation, communications, weather, cargo, passenger controls and emergency information. The demo shows the gate doing its job: the first assessment returns NOT_READY because a critical fire-pump defect makes firefighting equipment unready and defects unacceptable; only after the repair, retest and independent verification does the second assessment return READY and the master approve departure.

What this app is not

Version 0.1 does not replace, and intentionally leaves in their source systems:

AMSA certificate-application and regulatory systems;
specialist navigation, AIS, ECDIS or vessel-monitoring platforms;
payroll and enterprise HR;
a full CMMS, purchasing or inventory system;
medical-records systems;
formal drug and alcohol testing providers.

Those are integrated by reference — through Document, Evidence and the *_uri / *_reference columns — rather than duplicated. The pack's workflows, business rules, dashboards, mobile forms and permissions are process material for a later phase: the seed data is consistent with them but nothing in the running app enforces them.