Extended search space

Extended search space means that the matching algorithm can keep exploring additional planning-list batches when the first batch does not produce a valid solution. This happens inside one matching run. It is not a second ride request, and it is not a fixed sequence of neat time windows.

What the passenger finally sees depends on two layers:

• the search logic, which decides which candidates and time-shifted variants are evaluated
• the offer logic, which decides which surviving solutions are filtered, merged, and delivered

flowchart TD
    A[Ride request] --> B[Round 1]
    B --> C{Valid solution in this round?}
    C -- No --> D{More batches left and max rounds not reached?}
    D -- Yes --> E[Next round with later batches]
    E --> C
    D -- No --> F[No offer]
    C -- Yes --> G[Post-matching filters]
    G --> H[Offer assembly]
    H --> I[Passenger sees final offer]

Behavior

• ioki Platform generates candidate planning lists once and orders them by their estimated temporal distance to the requested time.
• The first round evaluates the candidates that are most likely to stay closest to the request.
• Another round starts only if no valid planning list survives the current round, more batches are still available, and Matching max rounds has not been reached.
• Matching target batch size per round and Matching min batch size per round control how many candidates are processed together. Very small trailing batches can be merged into the previous round.
• Matching fingerprint subsampling steps and Matching fingerprint subsampling size create additional time-shifted variants around the same structural insertion before scoring starts.

Because this search is progressive, one request can use the whole search space in the first round, while another request with the same settings can spread the work across several rounds. Extended search space should therefore be understood as a progressive expansion, not as predefined windows such as -15/+15, then -30/+30, then -45/+45.

The related settings are configured in Matching for the planning list builder strategy and in Matching parameters for the round, batch, and subsampling settings.

Offer behavior

If a round produces valid solutions, matching is still not finished. ioki Platform first applies post-matching filters such as prohibit parallel rides and the filter for overly similar multiple booking solutions offers. Only the remaining solutions are assembled into the passenger-facing result.

DRT-only setups

When multiple booking solutions is not active, the standard offer flow keeps one best DRT or intermodal solution. In this setup, extended search space only decides whether matching keeps looking for more distant DRT candidates before ending without an offer.

PT-prioritized setups

With public transport alternatives active, two related mechanisms—both applied in the prohibit parallel rides step—can suppress on-demand (DRT) solutions in favor of public transport:

• Prohibit parallel rides. When the product enables prohibit parallel rides, the configured PPR adapter can behave in three different ways. It can leave DRT untouched, it can use a time-window rule (a DRT solution is prohibited when an acceptable PTA departs within a configured window of the ride’s reference time), or it can use a scoring rule (a DRT solution is prohibited when its penalty score is worse than the best PTA’s).
• Intermodal suppresses DRT. When the product enables intermodal solutions suppress DRT solutions, the presence of any intermodal solution (a DRT leg combined with a public transport feeder) removes every pure DRT-only solution. This applies regardless of whether the prohibit-parallel-rides feature itself is active.

In both cases, extended search can still surface DRT candidates during the round-based search, but they can be dropped afterward once a preferred public transport or intermodal option exists.

DRT and PT comparison setups

If multiple booking solutions is active together with public transport alternatives, ioki Platform can assemble separate lists for DRT, intermodal, and PT-only solutions. All three lists are limited before merge. DRT solutions use the DRT ordering, while intermodal and PT-only solutions currently share the intermodal ordering path. The lists are then merged in the configured order, and the merged result can be sorted and limited again for final delivery. In this setup, extended search mainly influences which DRT or intermodal candidates survive long enough to enter that final assembly step.

Setup overview

Setup	What extended search changes	What decides the final offer
DRT only	Whether matching continues into later batches to find a valid DRT candidate	The single best surviving DRT or intermodal solution
PT prioritized	Whether DRT candidates are found before matching stops	Prohibit parallel rides suppresses DRT when a preferred end-to-end PTA exists; the intermodal-suppress option removes DRT when an intermodal solution exists
DRT and PT comparison	Which DRT or intermodal candidates reach the offer builder	Multiple booking solution limits, merge order, and final ordering

The current backend behavior expands the search automatically inside one ride search. It does not rely on the passenger client to start a second matching run manually. When no ride can be offered, the passenger is told how wide this search was; see matching progress and summary.