Planning method

Evidence types: reading facts without a single “verified” badge

A single green “verified” label hides several independent questions:

• Who made the claim?
• Did someone review it?
• Is it current for the requested date?
• Do sources agree?
• May the value be displayed, derived, cached, and redistributed?

Asmaliana keeps those dimensions separate so a user or agent can decide what the evidence actually supports.

Evidence kind

evidence_kind describes how a claim originated.

official_published

The identified responsible body or first-party publisher released the information. This label does not automatically mean the claim is current, reviewed by Asmaliana, independently corroborated, or licensed for API redistribution.

merchant_reported

An identified merchant/operator supplied the claim. It may be the best source for some operational details, but it is still distinct from an official external certificate or independent observation.

independently_observed

An observation was made under a documented method at a recorded time. Observations age and may cover only what was visible then. They do not automatically establish a continuing schedule or policy.

derived

The value was calculated from other assertions under a named rule version. A derived result should list its input assertion IDs. It cannot be stronger than missing, conflicting, restricted, or stale inputs allow.

demo

The value is synthetic and exists only for demonstration/testing. It must be visibly labelled, isolated from verified data, excluded from production indexing, and never used for real travel decisions.

Review status

review_status records Asmaliana’s decision process:

• pending_review: imported candidate material, not approved for publication;
• reviewed: a responsible reviewer evaluated the claim and its evidence for the declared scope;
• rejected: it failed the review or should not be used.

Review status does not replace source kind, rights, validity, or freshness. A reviewed claim can later become stale or lose redistribution permission.

Resolution status

resolution_status describes the value outcome:

• known: a value can be stated under the policy;
• unknown: evidence does not establish a value;
• conflicting: applicable evidence disagrees and no approved resolution exists;
• restricted: a value may exist, but it cannot be exposed on this surface.

Restricted is not a synonym for unknown. It tells the client that policy prevents disclosure without leaking the value itself.

Freshness status

freshness_status is evaluated for a field and request time:

• fresh: within the reviewed recheck/applicability policy;
• stale: beyond that policy or an explicit stale condition;
• unknown: the times/policy are insufficient to decide.

Schedules, prices, facility evidence, and certificates can use different recheck policies. A source fetched today can still contain a fact last verified long ago.

The important timestamps

• published_at: when the source or dataset published the material.
• retrieved_at: when Asmaliana fetched/received it.
• observed_at: when an observation occurred.
• checked_at: when a reviewer actually verified the assertion.
• valid_from / valid_to: business applicability.
• recheck_due_at: when the field should be reviewed again.

Changing one must not silently change another. In particular, a re-fetch can update retrieved_at and content hash without updating checked_at.

Sources and source groups

Each assertion links to sources. source_group_id identifies a common original provenance. Ten sites repeating one notice are not ten independent confirmations.

For cross-checking, inspect both the count of sources and the count/nature of independent source groups. Also check whether each source applies to the same branch, service, date, and field.

Rights are an evidence boundary

A publicly accessible page is not automatically reusable. Asmaliana records separate permissions for:

• display;
• quotation;
• derivation;
• caching;
• API redistribution;
• commercial use.

Rights can also expire or be withdrawn. When a requested surface is not permitted, the common public projection withholds the value rather than revealing it in HTML while hiding it in JSON.

Conflicts are data, not an import error to hide

Two applicable assertions can disagree. The safe choices are:

1. resolve the conflict through a documented review using stronger/applicable evidence; or
2. publish a conflicting state with safe source context.

Choosing the last imported record, the most convenient value, or an uncalibrated confidence score hides the disagreement. A source-group-aware conflict can also reveal apparent corroboration that is merely repetition.

Derived facts

Suppose a visit-window result is derived from an opening interval, last-entry rule, requested duration, and selected service state. The result should expose:

• rule_version;
• input_assertion_ids;
• data version;
• assumptions;
• checked and unchecked dimensions.

If the service state is unknown, arithmetic on the opening interval can still run, but the overall assessment may remain needs_verification.

A reading pattern for people and agents

For each material field:

1. Identify the value or explicit unknown/restricted/conflicting state.
2. Check evidence kind; do not convert “official” into “current.”
3. Check review status.
4. Check validity and freshness for the decision date.
5. Inspect source groups and conflict resolution.
6. Confirm the selected entity/branch/service.
7. Confirm rights permit this representation.
8. Note data, entity, schema, and rule versions.

Then look at the operation-level assumptions and unchecked dimensions. A strong fact about one field does not prove the whole itinerary.

Practical examples of careful language

Prefer:

• “The reviewed published schedule fits this arrival, subject to unchecked live operations.”
• “The fee is unknown in the current public dataset; it was not treated as zero.”
• “Two applicable sources conflict, so no opening interval was selected.”
• “The underlying value is restricted for API redistribution.”
• “This result is derived from assertions A and B under rule version R.”

Avoid:

• “Verified” with no dimensions.
• “Official, therefore guaranteed.”
• “Recently fetched, therefore current.”
• “No evidence of a facility, therefore absent.”
• “Multiple websites agree” when they repeat the same origin.

Evidence-aware design is less about adding badges and more about keeping distinct claims distinct.