Our optimiser found a feasible fleet for moving 4.58 million tonnes of cargo. A second program found that our totals were off by S$256,000.

We were hours from submitting.

Before the optimiser could choose anything, I cleaned 13,000+ AIS records from 108 vessels and counted only real transit and manoeuvring time. The final model chose 22 ships to move 4.58 million tonnes for S$20.04 million.

Feasible was not the same as verified

The model selected 22 vessels and satisfied the route constraints. That was enough to produce a polished chart and a confident answer.

It was not enough to trust the answer.

I rebuilt the total three ways: from route costs, from the selected vessels and from the report output. The numbers should have matched. They did not.

Floatware verification report showing 16 checks and one submission mismatch
Independent totals exposed a S$256,000 mismatch that the optimiser could not catch by itself.

The reconciliation led to stale inputs and report logic that had drifted from the model. The same release gate caught a UTF-8 encoding bug in the submission CSV before it left our hands.

The verifier stayed independent

We wrote 16 checks across data, model constraints, finance and the final report. The important part was separation. A test that repeats the optimiser's own assumptions can reproduce the same mistake and still pass.

Floatware 2nd Runner-Up certificate from the NUS Maritime Hackathon
The verified model placed 2nd Runner-Up from 176 teams.

The final model found that vessel ownership accounted for 76.5% of total cost, far more than fuel. Raising the minimum safety score from 3 to 4 increased cost by 5.1%, but cut CO2 by 3.9%. The safer ships also ran cleaner fuels, so the safety rule changed the emissions result.

That changed the fleet strategy and helped us finish 2nd Runner-Up from 176 teams.

The result mattered. The more reusable lesson was that a fast optimiser needs a boring, independent verifier beside it.