Public documentation

Electronic logbook requirements

This register maps the September 2022 Waka Kotahi NZ Transport Agency electronic-logbook minimum specifications to the current OpenSpaces implementation. It describes what is required and how the evaluation release addresses it. It is not a statement of approval.

Section 3.1

System performance, integrity, and entries

3.1.1 Partial

Requirement. Automatically check system operation and notify the driver, operator, and supplier of faults.

OpenSpaces. Runs startup, periodic, and reconnect checks; persists fault/recovery records and sends configured notifications. Production delivery and independent uptime evidence remain to be completed.

3.1.2 Partial

Requirement. Synchronise records across supported devices and delivery platforms in real time.

OpenSpaces. Uses a canonical server record with duplicate-safe offline replay. Multi-device convergence and conflict scenarios remain in the approval test plan.

3.1.3 Partial

Requirement. Receive software, legislative, and operating-system updates.

OpenSpaces. Uses versioned web assets, a PWA service worker, Android releases, controlled Git branches, staging, rollback backups, and append-only deployment records.

3.1.4-3.1.8 Implemented

Requirement. Protect automatically entered data, retain non-erasable system/settings audits, use New Zealand time, and preserve an unalterable actual timestamp for every entry.

OpenSpaces. Stores event and receipt times separately in UTC, displays Pacific/Auckland time, and preserves original values plus corrections and voids in append-only revision tables protected against update and deletion.

3.1.9 Partial

Requirement. Identify the driver by name and driver licence number.

OpenSpaces. Stores and displays both fields. Licence details remain optional and self-declared in the evaluation release; they will be mandatory for approved operation.

3.1.10 Implemented

Requirement. Give every Cumulative Work Day a unique identifier.

OpenSpaces. Assigns an immutable UUID and readable CWD-XXXX-XXXX-XXXX-XXXX reference, shown in regulated views, PDFs, and Excel output.

3.1.11 Partial

Requirement. Maintain suitable secure external backup.

OpenSpaces. Provides encrypted regulated backup and manifest tooling. Final retained evidence for schedule, off-server storage, restoration, and recovery testing remains required.

3.1.12-3.1.13 Partial

Requirement. Allow employers/operators and self-employed drivers to establish, collect, and maintain required records.

OpenSpaces. Provides driver-owned accounts and read-only Employer Access. Full operator and self-employed workflow evidence is still being assembled.

3.1.14-3.1.16 Partial

Requirement. Authenticate the driver and require deliberate CWD start/end actions, including password/PIN prompts where required.

OpenSpaces. Supports password authentication and device-specific PIN/biometric locking. Start Work and Stop Working are deliberate; approval mode requires fresh online authentication at CWD boundaries. Approved offline authentication requires NZTA confirmation.

3.1.17-3.1.18 Implemented

Requirement. Permit correction of automatically populated location/time before finalisation and permit notes without reception.

OpenSpaces. Lets the driver review and edit populated fields before submission and queues notes and core events locally for synchronisation after reconnect.

3.1.19-3.1.20 Implemented

Requirement. Prevent a new CWD while the previous one is open and lock earlier work/rest entries after the next state.

OpenSpaces. Enforces one open CWD. Originals are locked by later states; any permitted correction appends evidence instead of replacing the original.

3.1.21 Partial

Requirement. Mark changed entries and show the date and time of each change in the entry or associated audit trail.

OpenSpaces. Marks corrected and retrospective entries with *. Enforcement can expand an orange audit history showing original, correction, retrospective, and void evidence with recorded times; Excel includes the complete revision history.

3.1.22 Partial

Requirement. Keep a CWD crossing midnight as one complete record rather than splitting it into calendar days.

OpenSpaces. Provides a complete CWD record, stable reference, totals, and full-CWD PDF page. Calendar-day grids remain as supporting views; NZTA format confirmation is pending.

3.1.23 Partial

Requirement. Permit retrospective prior-day work entries back to the last qualifying 24-hour rest.

OpenSpaces. Supports ordered retrospective insertion within that boundary and records the event time separately from the later submission time. Final correction-policy approval is pending.

Section 3.2

Logbook and work-time information

3.2.1-3.2.4 Implemented

Requirement. Distinguish work/rest and record date, time, and location for every work and rest change using AM/PM or 24-hour time.

OpenSpaces. Records Start/Stop Work and Start/End Break events and renders a continuous work/rest line using 24-hour New Zealand time.

3.2.5-3.2.6 Partial

Requirement. Record every vehicle registration and applicable RUC distance-recorder start/finish readings.

OpenSpaces. Vehicle On/Off records rego and Odo/Hubbo. Final multi-vehicle and start/finish pairing evidence remains required.

3.2.7 Partial

Requirement. Make driver notes permanent and show them against the entry in driver and enforcement records.

OpenSpaces. Notes attach to timestamped entries and appear in logbook and regulated outputs. Final end-to-end immutability evidence is pending.

3.2.8-3.2.10 Partial

Requirement. Accommodate vehicle, employer, TSL, non-vehicle work, secondary employment, and all relevant TSL types.

OpenSpaces. Immutable declarations capture employer, TSL, work type, secondary employment, and vehicle context. The rules engine supports the standard 5.5-hour interval and eligible 7-hour small-passenger short-fare interval, including an immediate audited downgrade for mixed or long-distance work. Complete field evidence for every TSL type remains outstanding.

3.2.11 Implemented

Requirement. Allow the last qualifying 24-hour rest to be entered on first use.

OpenSpaces. Approval mode requires that value before the first approved work period can be established.

3.2.12-3.2.13 Partial

Requirement. Warn after limits while allowing truthful entry, and reconstruct the complete CWP roadside.

OpenSpaces. Keeps warnings visible without blocking genuine entries and reconstructs CWD/CWP records. Full supported-device and offline-roadside evidence remains pending.

3.2.14 Implemented

Requirement. Record notes for AFMS, exemption, agricultural variation, eLog failure, and other applicable conditions.

OpenSpaces. Stores these as structured, immutable event declarations with notes and inherited timestamped context.

Section 3.3

Employer and operator functions

3.3.1-3.3.3 Partial

Requirement. Make required data available to the operator from CWD/CWP commencement, at least every 24 hours, in the same unaltered form available to enforcement.

OpenSpaces. Every event, correction, and void creates employer-availability evidence linked to the same canonical projection hash used for regulated reconstruction. Production monitoring evidence remains to be retained.

3.3.4-3.3.5 Partial

Requirement. Retain records for at least 12 months, retrieve them simply, and record when information was provided.

OpenSpaces. Uses retention controls, restricted deletion, legal holds, and append-only availability/view acknowledgements. Production backup/restore evidence remains pending.

3.3.6-3.3.7 Partial

Requirement. Notify operators after 24 hours without an update, except qualifying rest, and provide timely breach notifications.

OpenSpaces. A scheduled monitor opens and resolves stale-delivery faults with 24-hour-rest suppression. Employer breach-notification workflow and production evidence require completion.

Section 3.4

Driver prompts and statutory warnings

3.4.1 Partial

Requirement. Warn 5 and/or 15 minutes before the applicable 5.5-hour or 7-hour rest deadline.

OpenSpaces. Supports configurable advance warnings for both intervals. Standard work defaults to 5.5 hours; the 7-hour preference activates only for eligible small-passenger short-fare work after a qualifying new CWD and cannot upgrade an active standard day. Production device evidence remains pending.

3.4.2-3.4.3 Implemented

Requirement. Warn before the CWD and 70-hour CWP limits.

OpenSpaces. Calculates the 13-worked-hour/14-elapsed-hour boundary and 70-hour CWP total, selects the earliest statutory deadline, and maintains configurable notifications.

3.4.4-3.4.6 Implemented

Requirement. Warn before resuming without qualifying 30-minute, 10-hour, or 24-hour rest.

OpenSpaces. Identifies non-qualifying short breaks and requires explicit confirmation/reason when starting before mandatory longer-rest requirements are satisfied.

Section 4.1

Driver primary display

4.1.1 Pending approval

Requirement. Display Waka Kotahi approval and the approval date.

OpenSpaces. Will display these only after formal approval. The current release is clearly labelled as an evaluation model.

4.1.2 Implemented

Requirement. State that the logbook is for the sole use of the identified driver.

OpenSpaces. Shows driver/licence identity and the sole-use declaration in the driver details.

4.1.3-4.1.8 Partial

Requirement. Show last 24-hour rest end, active CWP/CWD starts and durations, and whichever statutory deadline occurs first.

OpenSpaces. Calculates and presents these values in the working dashboard and expanded totals/details. Definition and supported-device evidence remain under final verification.

4.1.9 Partial

Requirement. Keep an exceeded warning visible until the driver complies.

OpenSpaces. Uses persistent red hero warnings and alert state. Refresh, offline, restart, and multi-device evidence remains in the test plan.

Section 5.1

Enforcement display and roadside production

5.1.1 Implemented

Requirement. Show all mandatory entries, last 24-hour rest end, work today, and total CWP hours.

OpenSpaces. The read-only enforcement view and PDF include driver identity, licence, CWD/CWP references and totals, declarations, notes, and correction markers.

5.1.2-5.1.3 Partial

Requirement. Populate an activity grid for the complete CWP and reconstruct it chronologically at roadside, including the latest CWD.

OpenSpaces. Provides ordered complete-CWD records, full-period expansion, supporting calendar grids, and a clean corrected timeline. NZTA confirmation of the final grid format and complete offline coverage is pending.

5.1.4 Partial

Requirement. Provide electronic copies of the active CWP at roadside.

OpenSpaces. Online QR access supplies immediate PDF and secure Excel workflows. Cached records can be inspected on the driver's device offline; acceptance of later extraction when connectivity is unavailable requires NZTA confirmation.

5.1.5 Implemented

Requirement. Present a cross-midnight CWD as one complete entry.

OpenSpaces. Complete CWD views and regulated PDF pages retain one stable identity, continuous event sequence, totals, and audit evidence across midnight.

Audit presentation Implemented

Requirement. Make corrections readily identifiable while preserving chain of evidence.

OpenSpaces. The graph shows the current corrected record with *. An officer can expand orange audit history containing original, superseded, retrospective, and voided actions without confusing them with current work/rest events.

Section 6.1

Minimum output data and Excel delivery

6.1.1 Implemented

Requirement. Supply the prescribed driver, vehicle, location, sign-in/out, cumulative-work, note, and change details chronologically.

OpenSpaces. Generates those fields in order and includes complete original/correction/void history with event time, recorded time, values, actor, and reason.

6.1.2 Implemented

Requirement. Provide one Microsoft Excel file no greater than 20 MB.

OpenSpaces. Produces a standards-based .xlsx package and enforces a hard 20 MB limit. Maximum-volume Microsoft Excel evidence remains a release test item.

6.1.3 Implemented

Requirement. Collate full Cumulative Work Periods unless a specific date or period is demanded.

OpenSpaces. Expands selected dates to intersecting complete CWP boundaries and discloses the resulting export range.

6.1.4 Partial

Requirement. Securely transfer bulk data and communicate any password separately.

OpenSpaces. Emails a one-use, 24-hour encrypted-file link and shows the random password only on the enforcement device. Requests, delivery, download, file hash, and enforcement lock are audited. NZTA acceptance of this transfer method is pending.

Responsibility and scope

OpenSpaces supports accurate record keeping, but it does not replace the driver's legal responsibility or professional judgment. Its work-time guidance should be checked against current New Zealand requirements and any conditions applying to the driver or operation.

Optional checklist and incident-reporting modules are outside the electronic-logbook approval scope. They use separate permissions and do not alter, delay, or prevent access to the regulated logbook, offline record, enforcement view, or exports.

Status terms: Implemented means the function exists but still requires submission evidence; Partial means implementation, evidence, or NZTA interpretation remains outstanding; Pending approval means it cannot be completed before approval is granted.

Questions or evaluation feedback can be sent through the Contact option in the public menu.