VESSEL INSPECTION CHECKLIST (VIC)
=================================

Hosting and integration brief for IT · Steinweg Oman · September 2026

What it is. The vessel inspection checklist that supervisors complete before cargo operations start — today an Excel workbook, printed and signed. This replaces it with a web application used on a Zebra handheld at the berth. Same questions, same revision, in English and Arabic.

What we are asking for. Somewhere inside the company environment to run it, and a decision on how people sign in.

WHAT IT NEEDS TO RUN
====================
  - Application
  - Node.js 22 web application (Next.js). Ships as a Linux container image, ~200 MB. Stateless — it can be restarted or scaled without losing anything.
  - Database
  - PostgreSQL today. The data layer is Prisma, so Azure SQL / SQL Server is a configuration change rather than a rewrite — we would want to test it, not assume it. Roughly 400 rows per completed inspection; a year of work is a small database.
  - File storage
  - Photos taken at the berth. Azure Blob Storage, or a mounted share. Configured by connection string; nothing is written to the application server itself.
  - Outbound mail
  - SMTP relay, to send the signed inspection to the agent and the duty manager. Optional — if mail is unavailable the app still works, it just does not notify.
  - Network
  - HTTPS only. Reachable from the quay — handhelds are on the yard wireless, and the app keeps working offline and syncs when signal returns, so intermittent coverage is expected rather than a problem.
  - Backup
  - Database and blob container on the standard company schedule. A signed inspection is a record we may need to produce months later.

TWO WAYS TO HOST IT
===================
  - Option
  - What it involves
  - A — Azure App Service for Containersrecommended
  - Push the container image to Azure Container Registry, run it on App Service, with Azure Database for PostgreSQL flexible server. Nothing to patch, TLS and the certificate are handled, and it is the shortest path from where the app already is. Entra ID sign-in is built into the platform.
  - B — Windows Server VM
  - If containers are not wanted: the app runs as a Node.js service behind IIS as a reverse proxy, against SQL Server. More moving parts to maintain, and it needs the database work described above tested first.

Either way the application itself does not change. What changes is a handful of environment settings — database connection, storage, mail, sign-in.

SIGN-IN
=======

Built with two paths already in place:
  - Entra ID (preferred). People sign in with their company account. Needs an app registration, a client ID and secret, and the redirect URL. No passwords stored by us at all.
  - Local accounts. What the draft uses now. Fine for a pilot, not what we want in production.

Each inspection records who signed it and when. The ship's representative has no company account, so their name is typed and stored explicitly as a name given to the inspector — never mixed up with an authenticated signature.

DATA
====
  - No personal data beyond the names of the inspector and the ship's representative.
  - Nothing leaves the company environment. There are no third-party services and no analytics.
  - A signed inspection is immutable — the application refuses to alter answers once a name is on it, and every change is recorded in an audit table.

WHERE IT STANDS
===============
  - Working and in use for testing: the checklist (all 325 questions, both languages), offline working, review and sign-off, and the signed record.
  - Still to build: photos against a vessel, the PDF, and the automatic emails. These depend on the storage and SMTP decisions above.
  - Currently running on a private server for evaluation only. Nothing operational depends on it.

What we need from IT to move forward
  - Which hosting option — A or B.
  - Database: Azure Database for PostgreSQL, or Azure SQL / SQL Server.
  - An Entra ID app registration, or confirmation that local accounts are acceptable for the pilot.
  - Blob storage container, or a share, for photos.
  - SMTP relay details and a sending address.
  - A hostname and certificate, and confirmation the yard wireless can reach it.

Leon Steer · Steinweg Oman · The source code, the database schema and the deployment files are ready to hand over on request.