Personalization & Recommendation Platform

Hospitality · 2020-Present

PublicRepresentative · synthetic data
signalsbehaviourcandidatesgenerationblendCF + facilityrulesbusiness filtermin-scorethresholdre-rankconfidencediversity≤2 / regiontop-Nslotsexplainoptionalmetered · LLMdeterministic · $0
Live diagram - the deterministic ranking spine runs at $0; only the optional explanation is a metered LLM call.
signals$0candidates$0blend$0rules$0min-score$0re-rank$0diversity$0top-N$0$explainmeteredCOST LEVER · explain on demand
Live diagram - the entire ranking is $0; the lone metered explanation is opt-in and on-demand, never on the critical path.
ASPECTCLOUD · capable readOSS · recorded"Why this?" narrativefluent, specificterser, still groundedSignal weighting proseweaves the blendlists top signalsCold-start explanationgracefulmore genericA rare 6-signal mixnarratednot captured - routed to a human
Live diagram - Cloud (claude-haiku-4-5) vs recorded OSS (Qwen3-8B) on the explanation only; the deterministic ranking is identical in both modes.

The deterministic spine

One hybrid recommender drives three triggers. The spine is fully deterministic: signals → candidate generation → a hybrid blend (collaborative-filtering co-occurrence + facility similarity + behaviour affinity + review quality + freshness + loyalty) → business-rule filter → minimum-score threshold → re-rank → per-region diversity → top-N. Every stage runs at $0 in both Cloud and OSS modes, and the weights, rules and thresholds are all owner-configurable and audited.

Because the ranking is deterministic, it is fully explainable: the "Why this?" chip on each pick is generated from the same trace the inspector shows, not from a model's after-the-fact rationalisation.

The one metered stage, and the cost lever

Only one stage is ever metered: the natural-language explanation that narrates a set of picks in plain language. The ranking itself never depends on it - the deterministic chips carry the specifics - so the recommendation quality is identical whether or not the explanation runs.

That independence is the cost lever. The explanation is opt-in and on-demand: it only runs when a guest or operator asks "how these are picked," it is cost-capped, and it fails closed to the $0 OSS path at the budget cap. The expensive call is therefore the exception, not the rule, and it is never on the critical path of serving a recommendation.

Dual approach - cloud vs on-prem OSS

The single metered explanation runs one of two ways. Cloud uses a hosted model (claude-haiku-4-5), cost-capped and fail-closed. OSS uses a self-hosted open model (Qwen3-8B) recorded on local M4 hardware and replayed at $0.

The honest finding, shown as recorded divergences in the inspector: the cloud model writes a more fluent, specific "why this" that weaves several signals together, while the smaller open model is terser and tends to list the top signals plainly - both grounded in the same deterministic trace. Because the explanation is cosmetic to the ranking, the recommendations are byte-identical in both modes. One divergence pair is shown as "not captured" rather than inventing an OSS explanation.

Out of scope (the real system)

Several production capabilities are deliberately excluded and represented honestly. Other modes at full scale - email at hundreds of thousands of recipients, real-time scoring infrastructure - are stood in for by a simulated campaign builder plus live on-site rails on a downscaled catalog. Real email, booking and payment integrations are simulated and labelled. Model retraining and online learning are represented by configurable weights and the business-rule overlay rather than live learning, and the catalog and language depth are downscaled to the shared 500-row synthetic set.