Hotel Recommendation Engine · Documentation
Architecture
Hotel Recommendation Engine's pipeline, its owned data, the events it emits/consumes, and what is out of scope.
← Hotel Recommendation EngineThe ranking pipeline
`rankProperties` is deterministic: per-property and per-region affinity from the behaviour log, plus normalised rating and popularity, plus an interest→facility bonus, summed into a score. It sorts descending, then walks the sorted list applying a 2-per-region cap until it has 6, attaching reasons as it goes (and a cold-start reason when there are no behaviour signals). `similarRanked` produces the detail-page "more like this" rail from city/price/shared-facility proximity.
Owned data + the coupling spine
The app reads shared-core `behavior_event`, `guest_profile`, `property`, and `booking`, and writes `demo_eco_recommendation` — the explainable output the guest saw — through the one typed C1 adapter. It consumes the host's behaviour/view events and feeds #31 and #11. The data invariant holds: owner writes are canonical; a viewer's recommendation rows are credential-scoped, ephemeral, and reset-clearing.
Metered AI, honesty inspector-only
Ranking is $0 in both modes — it is pure arithmetic. The one metered stage is `explain-ranking`, the natural-language "why these" narrative, run dual-mode: Cloud `claude-haiku-4-5`, cost-capped and fail-closed; OSS recorded as `qwen3:8b (recorded · M4)` at $0. It writes a `cost_ledger` row; the trace records gather-signals → blend+diversify (deterministic) → explain (metered). All cost/mode/trace is inspector-only.
Out of scope (simplified + labelled)
No learned model, no real user data, no external personalisation service — the ranker is a transparent deterministic blend over synthetic behaviour. Default weights are owner-tunable. No real imagery, no PII, no production prompts appear anywhere.