ADR-0013: OfferLineage — крос-річна ідентичність програми як ключ рекомендацій

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

Контекст

offers.id — ідентифікатор із держреєстру, унікальний лише в межах року: та сама програма щороку з’являється новим рядком. Co-application матриця FBT рахується з реальних кошиків заяв минулої кампанії — якби артефакти кеялись (offer_id, year), після щорічного ре-імпорту вони б «осиротіли», а editorial-піни вмирали б щосезону (відкрите питання §13.2 спеки 2026-06-06).

Рішення

OfferLineage — першокласна сутність read-model recsys: канонічна ідентичність програми крізь роки. Всі item-item артефакти (ItemItemEdge) і «вічні» editorial-правила кеються lineage; serving резолвить офер поточного року → lineage → рекомендації → назад в офери поточного року (без рядка цього року — випадають). Editorial дворівневий: разовий на (offer_id, year), постійний на lineage.

Наслідки

• + FBT/similar переживають щорічний ре-імпорт; «пін цієї програми назавжди» можливий.
• − Потрібне джерело lineage-мапінгу, і його поки нема: очікувана 24_to_25_offer_connection на проді не існує (перевірено 2026-07-12). Fallback-ключ (university_id, speciality_code) + мапінг abitly-edu-programs; вирішити до появи рядків наступної кампанії.
• Пом’якшення для сезону-2026: заявники 2025 висять на тих самих year=2025 рядках, що обслуговують живий сезон → FBT цього сезону працює без lineage-проєкції.

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