ADR-0012: Рекомендаційне ядро — еволюція abitly-recsys, не новий сервіс

Статус: accepted · 2026-07-12 · власник @Vladbandurin

Контекст

Потрібне рекомендаційне ядро на 5 сценаріїв: ranking з business rules, схожі офери, персональні рекомендації оферів/ЗВО, FBT («вступають сюди — також вступають сюди»), next basket до priority-списку. Водночас abitly-recsys (ranking & curation control plane, spec 2026-06-06) уже збудований до Phase 0/1: Decision API /v1/rank → впорядковані ID, final = base_score ⊕ editorial, власний Postgres + Valkey, fail-open SDK, admin-консоль; реєстр поверхонь заздалегідь декларує university.offers, search.offers та ін. Стара спека відклала per-user ML як «не-мету v1», але зарезервувала шлях: «ML-скорер — окремий процес за тим самим /v1/rank».

Рішення

Рекомендаційне ядро = еволюція abitly-recsys. Нові сценарії заходять як нові surfaces у реєстрі (offer.similar, offer.fbt, priorities.next, user.recommendations) + offline compute шар (ADR-0014); контракт /v1/rank, editorial-механізм, read-model і fail-open не змінюються.

Відхилена альтернатива

Окремий «recommendation engine» поруч із recsys: дублює read-model оферів, кеш, SDK і fail-open; «ranking with business rules» довелося б перевинаходити (він уже є — editorial + RankingPolicy); подвійна інфраструктура на команду з ~1 людини.

Наслідки

• + Один контракт для всіх поверхонь; editorial людини накладається і на ML-видачі.
• + Roadmap Phases 2–5 старої спеки переглянуто, її §13 закрито (вироки — у spec).
• − abitly-recsys перестає бути «лише curation» — зростає відповідальність сервісу.

Деталі — spec docs/superpowers/specs/2026-07-12-recommendation-core-design.md (репо abitly-mc).