Planning method

Itinerary conflicts: separating impossible, uncertain, and merely inconvenient

An itinerary checker is valuable when it explains why a plan fails—or why the available evidence is not strong enough to decide. A single red/green score cannot distinguish a known contradiction from a missing route, an unknown fee, or a soft preference.

Asmaliana evaluates structured stops with deterministic rules and reports conflicts, blocking unknowns, assumptions, checked dimensions, and unchecked dimensions separately.

This guide uses method-only synthetic examples.

Three different outcomes

infeasible

At least one supported hard constraint is contradicted. Examples:

• arrival is after a reviewed last-entry time;
• the requested stay extends past the applicable interval;
• two consecutive stops overlap after a known travel time and buffer;
• the selected sub-service is explicitly paused for the applicable time;
• a known required minimum cost already exceeds a hard budget.

needs_verification

No supported hard contradiction is established, but a material dimension cannot be evaluated. Examples:

• travel time between stops is missing;
• an applicable required fee has no known upper bound;
• schedule evidence conflicts;
• the requested weather date is outside coverage;
• a service status is unknown.

feasible

All declared hard constraints in the evaluated scope pass using the stated evidence and assumptions. This does not guarantee live operations, admission, inventory, weather safety, or trip completion. The result must list unchecked dimensions.

Hard constraints, soft preferences, and unknowns

A hard constraint is a condition the plan must satisfy, such as end time, maximum budget, required facility evidence under a declared policy, or a selected service.

A soft preference helps rank valid candidates but cannot override a hard conflict. For example, preferring an outdoor stop does not make it acceptable after the end time.

A blocking unknown is not a preference penalty. If the system lacks necessary route evidence, it cannot rank the plan as proven feasible simply because other attributes score well.

The evaluation order

A reliable checker generally follows this order:

1. Validate shape, timezone, local-date scope, stop count, stable IDs, and durations.
2. Load one immutable rights-filtered dataset revision.
3. Resolve the selected place and optional service at each stop.
4. Evaluate schedule intervals, exceptions, last entry, and minimum duration.
5. Evaluate service operating/product state separately from place schedule.
6. Evaluate each transition using authorised provider/precomputed/user-supplied travel evidence.
7. Apply the configured buffer.
8. Calculate required cost bounds and currencies.
9. Evaluate declared party constraints and supported facility/certificate evidence.
10. Combine hard conflicts, blocking unknowns, and preference scores.
11. Generate bounded suggested fixes that do not invent facts.

Planning uses the same full validation after its heuristic generates candidates. A heuristic failing to find a plan is not proof that no solution exists.

Time conflicts

Suppose a synthetic stop ends at 11:30 and the next starts at 11:40.

• If reviewed route evidence says 20 minutes plus a 5-minute buffer, the schedule has a known conflict.
• If route evidence is unavailable, the ten-minute gap is not automatically enough; route feasibility is a blocking unknown.
• If the user supplies a 7-minute estimate, it can be evaluated as an explicit assumption, not converted into provider evidence.

The response should identify which timing came from a source, configuration, or user input.

Schedule and service conflicts

A parent place can fit its interval while the requested service is closed or paused. The checker must evaluate the selected service, not silently fall back to a different activity at the same place.

Similarly, a dated exception can turn a normally valid weekly interval into a closure or conflict. Unknown public-holiday behavior stays unknown.

Budget conflicts

• Known minimum greater than the hard budget: infeasible for the cost dimension.
• Known upper bound within budget: the cost dimension can pass, subject to listed exclusions.
• Required unknown amount or currency mismatch: needs_verification.

An unknown cost is never filled with zero to make a plan pass.

Evidence conflicts

If two applicable schedule assertions disagree and no approved resolution exists, the checker should not choose one. It reports a blocking evidence conflict and provides safe source references when permitted.

The same applies to facility and certificate claims. Missing facility evidence is not proof of absence; a merchant self-description is not silently elevated to external certification.

Suggested fixes

A fix should be tied to a detected condition and stay within the system’s authority. Safe examples include:

• shift a stop earlier enough to meet last entry;
• reduce duration only when the new duration remains within a supported/user-approved minimum;
• remove or replace a stop with another covered candidate;
• request/provide a route estimate as an explicit assumption;
• increase the budget only if the user controls that constraint;
• verify a named unknown through an available cited source.

Unsafe suggestions include:

• claiming a venue will make an exception;
• inventing a travel time or fee;
• recommending an unavailable booking/contact tool;
• looping back to the same tool without a changed input or new evidence.

Checked and unchecked dimensions

A readable result might say:

checked: published schedule, requested duration, known route estimates, known required fees
unchecked: live operations, capacity, ticket inventory, booking, unreported costs

This scope is essential to interpreting feasible. The status should appear in text as well as colour so assistive technology and monochrome displays do not lose it.

Structured input, not guessed prose

P0 expects each stop to contain a stable place_id, optional service_id, arrival instant, and duration. Free-form prose can omit timezone, branch, date, and duration. Without an enabled, separately validated parsing feature, the service should ask for structured input instead of pretending it understood every detail.

Practical checklist

• No more than eight stops and one supported local day.
• Every stop has the intended stable place/service ID.
• Arrival instants and durations are explicit.
• Schedule exceptions, last entry, and service state were checked.
• Every transition has reviewed route evidence or a labelled user assumption; missing routes remain unknown.
• Buffers are visible and versioned.
• Unknown costs are not zero and mixed currencies are not blindly summed.
• Hard conflicts outrank preferences.
• A heuristic miss is not called a proof of impossibility.
• Suggested fixes change a controllable input and do not imply an unavailable action.
• Assumptions, sources, data/rule versions, and unchecked dimensions are present.

A good itinerary result is not the one that says yes most often. It is the one that shows exactly what supports yes, what proves no, and what still cannot be known.