Frequently asked questions

Asmaliana is an independent, read-only decision-support service for a bounded set of Melaka place facts and single-day itinerary checks. It is not a tourism authority, venue operator, booking agent, safety service, or guarantee that a trip will proceed.

Verified means the current published revision passed the project's review, rights, schema, and freshness gates. It does not mean complete Melaka coverage or live confirmation. The current revision and field-level freshness are shown on the status page.

A value can be unknown when no reviewed source establishes it, when evidence is stale or conflicting, or when rights prevent redistribution. Unknown is not the same as free, open, accessible, safe, or absent. Inspect the field status and attached sources on each place page.

No. Published schedules and ticket rules are evidence snapshots with validity and recheck metadata. They do not confirm current operation, capacity, inventory, queues, closures, or admission for a particular traveller. Time-sensitive decisions still require direct confirmation.

The planner checks one local day, up to eight stops, against published schedule rules, date exceptions, duration evidence, costs, and available route intervals or user-supplied estimates. Missing or conflicting evidence stays visible as needs_verification; the service does not invent travel times or prove a global optimum. See the planner and conflict guide.

Weather is an attributed area forecast for the configured Melaka Tengah coverage, not a venue sensor or safety guarantee. Routing is a dated driving snapshot without live traffic, queue, closure, or turn-by-turn navigation. Provider coverage and validity are shown in the coverage statement.

No. Production exposes six read-only tools. Booking, payment, inquiry, email, affiliate actions, webhooks, A2A, and ARD are disabled. A successful response means the computation ran; it is not a transaction or confirmation.

Every covered place has HTML, Markdown, and JSON representations with the same entity revision. Developers can start at the quickstart, inspect OpenAPI, or connect to the read-only MCP endpoint. Responses include data mode, revision, evidence, limitations, and request identifiers.

Demo records are synthetic fixtures for testing and are clearly labelled and noindexed. Production uses the reviewed verified revision and never falls back to demo data. Always check data_mode and data_version before relying on a result.