Chain of Responsibility (CoR) Compliance Framework

Introduce a Chain of Responsibility (CoR) compliance framework into ICOS TMS to support customers in New Zealand and Australia with meeting their legal obligations under Heavy Vehicle National Law (Australia) and Land Transport / WorkSafe regulations (New Zealand).

CoR requires every party in the transport supply chain—not just the driver—to ensure safe and compliant transport operations. This idea proposes creating system-level controls and workflows that help prevent, detect, and record non-compliant actions, and provide transparent audit evidence.

ICOS TMS should function as a core tool for:

• Preventing unsafe scheduling

• Ensuring vehicle and driver compliance

• Verifying load and weight rules

• Supporting approved routes

• Capturing key CoR declarations

• Providing audit trails for investigations

Prototype screen

Problem / Opportunity

Customers face increasing compliance pressure, and manual processes create risk.
Current challenges include:

• No system guidance that prevents overloading or assigning unsafe loads

• Limited route validation for weight-based or restricted areas

• Fatigue risks when scheduling drivers manually

• Hard to prove CoR due diligence during audits

• No central audit trail connecting bookings, drivers, and vehicles

There is an opportunity for ICOS TMS to become the compliance backbone for transport operators, reducing risk and improving operator confidence.

What This Idea Proposes

Create a CoR capability framework in ICOS TMS to support compliance across these areas:

1. Load & Weight Compliance

• Vehicle GVM / GCM stored and enforced

• Alerts for overweight jobs

• Prevent dispatch when load exceeds vehicle capacity

• Record weight declarations from customers

2. Driver Fatigue & Scheduling

• Driver availability windows

• Hours-of-service checks

• Warning if a delivery plan is not physically achievable

• Fatigue-aware dispatching rules

3. Vehicle Safety & Maintenance

• Maintenance status checks before booking assignment

• Automated blocks if WOF/COF/Service is overdue

• Ability to attach inspection results (Carjam, internal checks)

4. Approved / Permitted Route Support

• Weight-restricted roads

• PBS / HPMV route compliance

• Real-time deviation alerts

• Ability for managers to approve exceptions

5. CoR Data Capture

• Ability to attach:

  • load declarations

  • customer-provided weights

  • loader confirmation

  • driver pre-trip checks

• Digital signatures or confirmation actions

6. Auditing & Record Keeping

• Timeline linking booking → vehicle → driver → route → decisions

• Who assigned what, when, with what information

• Evidence logs exportable for investigations

Value Proposition

Implementing CoR in ICOS TMS will:

• Reduce customer risk and legal exposure

• Differentiate ICOS TMS from competitors

• Improve scheduling accuracy and safety

• Support onboarding of large enterprise fleets

• Build trust with customers during the ICOSLIVE → TMS transition

Acceptance Criteria / High-Level Requirements

• Alerts and blocks are configurable per customer

• All CoR checks are visible during booking creation and dispatch

• Ability to run a “CoR readiness check” on a job

• Audit logs automatically generated

• Routes validated against road restrictions

• Driver and vehicle compliance visibly surfaced before dispatch

Non-Functional Considerations

• Must not slow down booking flow

• All rules must be configurable

• Works with both container and freight workflows

• Supports NZ and AU compliance variations

Questions to Validate

1. Do customers expect mandatory blocking or warnings only?

2. Do we support both self-declaration and calculated weights?

3. What fatigue rules do NZ operators want included?

4. Should CoR be surfaced in the driver app as well?

5. How much audit detail is required for legal defence?