Application Overview

Coastal Trading Licence & Voyage Management is an operator-side system for the Australian coastal trading scheme. It carries a shipping operator from the first question — does this movement even need a licence? — through application, consultation, decision, authorised voyages, the voyages themselves, and the statutory notifications and reports, to a defensible evidence trail that each completed voyage stayed inside the licence it was granted.

It is a prototype data and workflow model, not legal advice, and it does not replace the Australian Government Coastal Trading Licensing System (CTLS). Every model that touches the Department carries a ctls_reference or department_reference column — the handle to the real system of record.

The core operating chain

CoastalTradeAssessment / Section12Declaration / Exemption   is a licence needed?
  → LicenceApplication → ProposedVoyageMatter               what is applied for
    → Publication → NoticeInResponse / ThirdPartyComment
       / ApplicantResponse / InformationRequest             the public phase
      → DelegateDecision → Licence → LicenceCondition        the authorisation
        → AuthorisedVoyage  (± VariationApplication)         matters that may run
          → VoyageNotification                               pre-voyage notice
            → Voyage → PortCall / CargoMovement
               / PassengerMovement / VoyageEvent             what happened
              → VoyageReport                                 post-voyage actuals
                → VoyageReconciliation                       the three-way check

Wrapping that spine: WageComplianceAssessment, the compliance stream (ComplianceObligation → ComplianceTask / ComplianceException → CorrectiveAction), and assurance (RegulatoryCorrespondence, Evidence, Audit → AuditFinding, Notification).

The five key concepts

  1. Scope before licence. Not every movement is regulated. A CoastalTradeAssessment records the decision (interstate? commercial? excluded vessel or activity?) and recommends a licence type. Intrastate Section 12 declarations and exemptions are modelled separately so the out-of-scope cases never masquerade as licensed voyages.

  2. Proposed matter vs authorised voyage vs actual voyage — three distinct things. What is asked for (a ProposedVoyageMatter on an application), what is permitted (an AuthorisedVoyage on a licence, with its quantity tolerance and voyages-completed balance), and what happened (a Voyage) are three separate records. Conflating them is exactly the error the model exists to prevent.

  3. The three-way reconciliation is the headline control. A completed voyage is judged not against a single expectation but against three: the authorised voyage (what the licence permits), the voyage notification (what the operator told the Department it would do) and the voyage report (what it actually did). VoyageReconciliation records a boolean per dimension — vessel, route, loading date, quantity-within-tolerance, commodity, notification timeliness, report timeliness — and an overall result. This is where discrepancies surface before closeout.

  4. Consultation is a first-class phase, not a footnote. Temporary and emergency licences are published; a competing Australian operator can lodge a notice in response, third parties can comment, and the applicant must respond. The whole exchange is retained so the delegate's decision is defensible.

  5. Evidence outlives the voyage. Wage compliance (Schedule A for temporary-licence foreign-vessel voyages), correspondence, retained evidence items, audits and findings, and corrective actions form an assurance layer that survives after the voyage is closed — the point of an operator-side system is being able to show compliance later.

What this app deliberately does not do

  • It is not CTLS. No live submission to the Department is performed; the ctls_reference / department_reference columns carry the external handles. Integration must be confirmed with the Department.
  • The pack's state machines and rules are documentation here, not enforcement. workflows.yaml (application / variation / voyage / notification / report), business_rules.yaml, dashboards.yaml, views.yaml, permissions.yaml and integrations.yaml describe intended behaviour. The demo data is consistent with them; nothing in this prototype blocks a transition that violates them.
  • It is not legal advice. Current legislation, regulations, Department instructions and licence-specific conditions must be checked for each real implementation.