Planning method

Unknown costs: why missing prices are not free

The most dangerous shortcut in a travel budget is turning a missing amount into zero. It makes an incomplete plan look affordable and hides exactly the information a traveller still needs.

Asmaliana represents a genuinely free item as an evidenced zero amount. It represents a missing, restricted, conditional, conflicting, or out-of-date amount as an unknown with a reason.

This guide describes the calculation method. Its examples are synthetic and do not state real prices.

Zero and unknown mean different things

Consider two fictional entries:

amount_minor: 0
currency: MYR
resolution_status: known

and:

amount_minor: null
currency: MYR
resolution_status: unknown
unknown_reason: not_published

The first can support a zero-cost calculation if its evidence is reviewed, applicable, and allowed for use. The second contributes an unknown required cost. Replacing null with 0 would invent a claim.

Why a single headline amount is often insufficient

A cost can depend on:

These are rules, not decorations around a number. The planner evaluates the applicable rules for the submitted party and selection. When it cannot establish eligibility, it should preserve a range or unknown instead of choosing the cheapest case.

Minimum, maximum, and uncertainty

A useful itinerary cost has a lower bound and an upper bound, each with an explanation.

Suppose a synthetic itinerary has two required known costs totalling 4,000 minor units and one required unknown charge. The lower bound may be at least 4,000, but the upper bound is unknown. A budget of 5,000 cannot be marked feasible merely because the known subtotal is smaller.

Integer money avoids silent arithmetic errors

Amounts are added as integer minor units plus a currency code. For a two-decimal currency, 12.34 is represented as 1,234 minor units—not a binary floating-point value.

The calculation does not add MYR and another currency as if they were comparable. Currency conversion requires its own authorised, dated source, rounding rule, and validity. Without that, the result reports a currency mismatch or separate subtotals.

Party composition matters

A party is not always number_of_people × one price. The applicable set can depend on each member’s declared category and the evidence behind that category.

The service should:

  1. apply only the conditions actually satisfied by the structured party input;
  2. avoid inferring age, residency, disability, membership, or eligibility from a name or prose;
  3. report which rules were applied;
  4. preserve unknown eligibility as uncertainty;
  5. exclude personal details that are not needed for the calculation.

If the input says only “two people” and the source has distinct eligibility categories, a precise total may be impossible. Asking for the minimum necessary structured category can be an appropriate next action.

Required and optional extras

An offer record needs to distinguish:

An optional upgrade should not inflate the minimum required budget. A mandatory but unknown fee must not disappear from the upper bound.

Evidence and time still apply

A beautifully modelled number can still be unusable when:

The result should expose these states instead of returning a bare total.

Budget assessment

For a hard budget, the safe rule is:

This separates a proven conflict from insufficient evidence. Both are more useful than false precision.

Reading a cost response

Look for:

An API envelope with success=true can contain assessment=needs_verification because the cost calculation executed correctly and discovered a blocking unknown.

Practical checklist

Budget honesty is not about producing the most attractive total. It is about showing which part of the total is supported and which part still needs a decision.