Skip to main content

Zorunlu Kriterlere Göre Uygun Venue-Space Sonuçlarını Güvenilir Biçimde Gör

1. Amaç​

Kurumsal alıcı, etkinlik gereksinimlerini yapılandırılmış zorunlu kriterler ve tercihler olarak ilettiğinde, EventInn'in gerçekten uygun venue-space eşleşmelerini; doğrulama bekleyen adaylardan ve uygun olmayan adaylardan açık biçimde ayırmasını ister.

Bu use-case'in iş sonucu, kullanıcının yüksek bir skor gördüğü için zorunlu kriteri karşılamayan bir mekânı yanlışlıkla uygun sanmasını önlemektir.

2. Faz ve stratejik bağ​

Bu use-case Faz 1 Market kapsamındadır. Faz 1'in ihtiyaç/arama → shortlist → RFP zincirindeki güvenilir arama ve eşleştirme adımını destekler.

Bu kayıt yalnız kullanıcı sonucunu tanımlar. Retrieval algoritması, veri modeli, ranking uygulaması veya AI sağlayıcısı hakkında teknik karar vermez.

3. Aktörler​

  • Birincil aktör: Kurumsal alıcı / etkinlik planlayıcısı
  • Destekleyici aktör: EventInn arama ve eşleştirme sistemi
  • Bilgi sağlayıcı: Venue ve space kayıtlarının yetkili sahipleri/yöneticileri

4. Tetikleyici​

Kurumsal alıcı, bir etkinlik için venue ve space araması başlatır ve yapılandırılmış gereksinimlerini gönderir.

5. Önkoşullar​

  1. Kullanıcının gereksinimleri yapılandırılmış kriterler olarak mevcuttur.
  2. Her kriterin hedef kapsamı venue veya space olarak belirlenebilir.
  3. Her kriterin zorunlu veya tercih niteliği kaynağıyla birlikte bilinir.
  4. Sistem, bu use-case'e girdi olacak görünür/yetkili aday kümesini sağlamıştır.
  5. En az bir temsilî venue-space veri seti değerlendirme için kullanılabilir durumdadır.

Bu MVP use-case authorization politikasını tanımlamaz; yalnız önceden yetkilendirilmiş aday kümesini girdi kabul eder. Authorization ayrı bir karar ve risk çevrimidir.

6. Ana başarı akışı — Happy Path​

  1. Kurumsal alıcı zorunlu kriterlerini ve tercihlerini gönderir.
  2. Sistem her kriteri venue veya space kapsamına bağlar.
  3. Sistem venue-level zorunlu kriterleri değerlendirir.
  4. Venue-level değerlendirmeyi geçen her venue için bağlı space kayıtları değerlendirilir.
  5. Her kriter için met, unmet veya unknown sonucu ve gerekçesi kaydedilir.
  6. En az bir uygun space bulunan venue eligible olarak sınıflandırılır.
  7. Eligible venue için yalnız eligible space'ler arasından best_matched_space belirlenir.
  8. Eligible sonuçlar, zorunlu uygunluğu değiştirmeyen soft-fit ölçütleriyle deterministik olarak sıralanır.
  9. Kullanıcı her venue için eşleşen space'i, uygunluk durumunu ve kriter gerekçelerini görür.

7. Alternatif akış — Bilgi eksikliği​

  1. Bir veya daha fazla zorunlu kriter için güvenilir veri bulunamaz.
  2. Sistem unknown sonucunu olumlu eşleşme olarak kabul etmez.
  3. İlgili politika engelleme gerektirmiyorsa aday needs_info olarak sınıflandırılır.
  4. needs_info adaylar eligible sonuçların altında ayrı bölümde gösterilir.
  5. Kullanıcı hangi bilgilerin eksik olduğunu açıkça görür.
  6. needs_info aday otomatik shortlist veya sourcing handoff işlemine alınmaz.

8. İstisna akışı — Zorunlu kriter ihlali​

  1. Venue veya space zorunlu bir kriteri açıkça karşılamaz.
  2. Aday ineligible olarak sınıflandırılır.
  3. Soft-fit skoru, sponsorluk veya AI önerisi bu sonucu değiştiremez.
  4. Ineligible aday kullanıcı sonuç listesine, result count'a veya best-match seçimine girmez.

9. Abuse / güvenlik akışı​

  1. Bir AI veya başka bir bileşen, kullanıcı tarafından açıkça zorunlu belirtilmiş bir kriteri soft tercihe çevirmeye çalışır.
  2. Sistem kriterin provenance bilgisini kontrol eder.
  3. Yetkisiz hardness değişikliği reddedilir ve iz bırakır.
  4. Nihai eligibility sınıflandırması deterministik kurallarla üretilir.

10. Başarı sonrası durum​

  • Kullanıcıya sunulan her venue sonucu eligible veya needs_info durumundadır.
  • Ineligible adaylar kullanıcı sonuçlarından çıkarılmıştır.
  • Her görünen aday için kriter bazlı değerlendirme ve gerekçe mevcuttur.
  • Her eligible venue için en az bir eligible space bulunur.
  • Soft ranking, eligibility sonucunu değiştirmemiştir.

11. Kapsam içi​

  • Yapılandırılmış kriterler
  • Hard ve soft ayrımı
  • Venue-level ve space-level değerlendirme
  • met | unmet | unknown
  • eligible | needs_info | ineligible
  • Best matched space
  • Missing-information görünürlüğü
  • Deterministik gerekçe/reason-code üretimi
  • Eligible-first sonuç sırası

12. Kapsam dışı​

  • Natural-language veya LLM tabanlı intent parsing
  • Authorization/visibility politikasının kendisi
  • Canlı availability
  • Geo ve trust ranking
  • Editable chips
  • Kalıcı shortlist/comparison
  • RFQ, proposal veya sourcing workflow
  • Ürün kodu, migration, staging ve production deployment

13. Kabul kriterleri​

  • Hard unmet aday hiçbir durumda eligible olamaz.
  • Unknown değer met olarak yorumlanamaz.
  • Eligible sonuçlar needs-info sonuçlardan önce gelir.
  • Ineligible aday kullanıcı sonuçlarında görünmez.
  • En az bir eligible space bulunmayan venue eligible olamaz.
  • AI inference tek başına hard constraint oluşturamaz.
  • Her kriter sonucu kaynak, kanıt ve deterministik reason-code taşır.
  • Aynı canonical input, aynı dataset snapshot/version, aynı rule-policy version ve aynı tie-break sözleşmesi aynı görünür sonuç sırasını üretir.

14. Bağlı business rule'lar​

  • CAN-REQ-RULE-001 — Hard ihlal telafi edilemez.
  • CAN-REQ-RULE-002 — Unknown olumlu eşleşme değildir.
  • CAN-REQ-RULE-003 — Sonuç bölümlendirme ve görünürlük sırası.
  • CAN-REQ-RULE-004 — Hardness provenance ve AI sınırı.
  • CAN-REQ-RULE-005 — Venue uygunluğu space uygunluğundan türetilir.
  • CAN-REQ-RULE-006 — Her hard kriter açık unknown policy taşır.

15. Açık karar sorusu​

Bu use-case kabul edilirse aşağıdaki teknik karar için ayrı Canon ADR değerlendirilir:

Zorunlu uygunluk, soft ranking'den önce çalışan deterministik ve telafi edilemez bir eligibility gate ile mi uygulanmalıdır?

Bu kayıt ADR seçeneğini peşinen kabul etmez.

CAN-REQ-UC-001 · UC-P1-MATCH-001 · requirements/normative · governance_status: draft · Canon Decision Cycle MVP-1.