Pauses

A pause is part of a vehicle planning. In contrast to a deactivation, it’s always planned and has requested and calculated start and end times. During the time span of a pause, no rides are matched to the vehicle planning. For ad hoc booking, this means vehicles in active pauses aren’t considered for the ride request.

The start and end times of a pause are calculated points and don’t have a negotiable time window. A pause is not a movable slot that the matching algorithm optimizes into. It shifts in time for two reasons: real delays, and rides matched into the vehicle planning before Pause Beginning. When work is added before the pause, the preceding tasks finish later, so the pause start moves later with them. The pause starts when the driver accepts the Pause Beginning task.

Preserve duration

Preserve duration enforces the planned pause duration as a minimum. It’s true by default for pauses created together with the vehicle planning.

If Preserve duration is active, the actual pause lasts at least as long as the planned pause. If the driver checks Pause Beginning after the planned start time, the pause end time shifts into the future to maintain the duration. If the driver checks Pause Beginning before the planned start time, the planned end time stays fixed, so the pause is extended.

A pause from 12:00 to 13:00 is created with Preserve duration active.

• Scenario A: The driver checks Pause Beginning at 12:15. The end time shifts to 13:15 to preserve a one-hour duration.
• Scenario B: The driver checks Pause Beginning at 11:45. The end time stays fixed at 13:00.

In both scenarios, the minimum duration of one hour is preserved.

If Preserve duration isn’t active, the pause ends at the planned end time regardless of when the driver checks Pause Beginning. For example, a 12:00–13:00 pause where the driver checks Pause Beginning at 12:15 still ends at 13:00, reducing the duration to 45 minutes.

Preserve duration only enforces a minimum duration. It doesn’t make pauses flexible and doesn’t let drivers reschedule pauses dynamically.

Placement

If a place is assigned to a pause, the calculated time the driver needs to arrive there is taken into account. If no place is assigned, the location of whatever is rostered into the vehicle planning before the Pause Beginning task is used during recalculation.

That means if a new ride matches into the vehicle planning before the Pause Beginning task, the pause floats to the location of that preceding task when the vehicle planning is recalculated. If the vehicle planning hasn’t started yet and no ride-related task is planned, the pause settles on the Shift Beginning task’s location, which always has to be specified. If the current time has passed the planned start time and the vehicle is sending position updates, the vehicle’s current position is used as the pause location.

The pause location also changes if the driver moves during a pause. The matching algorithm updates this and doesn’t expect the driver to return to where the pause started.

Pauses during matching

A pause is a protected block, not a movable slot that the matching algorithm optimizes into. ioki Platform represents each pause with two tasks: Pause Beginning and the corresponding pause end. During matching, ioki Platform never inserts a ride inside a pause. It never places a pickup directly after Pause Beginning, never places a drop-off directly before the pause end, and never lets a ride span across a pause. These rules are enforced as pre-routing rejections. See the codes pickup_inside_pause_task_tuple, dropoff_inside_pause_task_tuple, and ride_spans_a_pause in the matching algorithm.

As a result, a pause is never skipped, split, or shortened by matching. It can only move in time.

The pause moves later when a ride is matched before it. ioki Platform recomputes the calculated pause start whenever the task list changes. The start becomes the later of the desired start time and the earliest time the driver can reach the pause after finishing every task that precedes it. So when a ride is matched before Pause Beginning, the preceding work finishes later and the pause start moves forward with it. This is the same mechanism that lets the pause location float, described in the Placement section. With Preserve duration active, which is the default, the full duration is kept, so the whole pause block slides later as a unit.

A pause from 12:00 to 13:00 is created with Preserve duration active. A new ride is then matched into the vehicle planning before Pause Beginning. The extra pickup and drop-off make the preceding work finish at 12:20, so the pause start moves to 12:20 and the pause end moves to 13:20. The one-hour duration is preserved and the pause still happens. The pause is postponed, not skipped or shortened.

Postponement is expected behavior, not a fault. The pause still happens at its required duration.

Shift End always stays the last task. ioki Platform never inserts a ride after the end-of-shift task, so Shift End remains at the end of the task list regardless of any line settings.

Whether Shift End is also a timing boundary depends on the line’s Skip time window check setting:

• When Skip time window check is off, ioki Platform keeps the whole planning—the pause and every task after it—within the vehicle planning’s end time. A ride that cannot fit before Shift End is rejected during matching. Nothing reserves a fixed gap between the pause and Shift End, so a pause can slide toward the end of the shift, as long as the pause and all remaining tasks still complete before Shift End.
• When Skip time window check is on, matching does not enforce the shift-end timing. It can offer a plan whose calculated timeline finishes after Shift End, and a pause that slid later can end up past Shift End. Shift End still stays the last task, but the plan is no longer guaranteed to complete before it.