EVENTINN ÜST STRATEJİ DOKTRİNİ

Etkinlik Üretiminin Karar Motoru, Contextual Management ve Control-Plane-Driven SaaS

Normatif seviye: Üst strateji / ürün, marketplace, SaaS ve işletim mimarisi yönü. Karar sahibi: Human CEO. Bu kayıt yön, stratejik invariant ve sapma yasakları taşır. Fiziksel tablo, kolon, API, class, component, exact state-machine veya implementation schema belirlemez. Somut capability'ler Scenario → UC → Rule/Policy → gerekirse ADR → Feature Train → Code → Verify zincirinde doğar. Statü: ACCEPTED (Human-CEO exact-SHA, 2026-07-15; künye source fef3c76 / blob 1f6b4b8; decision "KABUL EDİYORUM"). accepted ≠ effective (yürürlük ayrı kapı). Bu kayıt, CEO same-id in-place direktifiyle (14 Tem) authoritative canon-path'te REVISION CANDIDATE (proposed) olarak duruyordu; Human-CEO exact-SHA kabulüyle (@2ab4dba, 2026-07-15) proposed→accepted geçti (accept ≠ materialize ≠ effective). Önceki accepted-içerik immutable-anchor'da korunur (commit 47b6a2c / blob e9ca83f).

§0. REVISION COVERAGE MAP — NON-NORMATIVE REVISION EVIDENCE (nothing-lost kanıtı + traceability; doktrinel-hüküm DEĞİL — bu-revizyonun kapsam-koruma kanıtıdır)

Bu revizyon SUPERSET'tir: eski accepted doktrinin TAM normatif-kapsamı korunur + yeni vizyon eklenir; sessiz-kapsam-kaybı veya sessiz-sıra-değişikliği yoktur (§38 Silent Scope/Sequence Change yasağı). Bölüm-numaraları yeniden düzenlendiği için eski→yeni eşleme (P1-1 traceability):

Eski §	Konu	Yeni §	Durum
§1	Doktrinel Tez	§1	korundu + genişletildi
§2	İşletim Doktrini	§2	korundu + genişletildi
§3	Üç Intake	§3	korundu
§4	Decision Context	§4	korundu (+PEAK ATTENDANCE)
§5	Requirement Graph	§5	korundu
§6	Fact/Inference/Unknown	§6	korundu + genişletildi
§7	Adaptive Sub-Brief	§7	korundu
§8	Yaşayan Brief'ler	§8	korundu
§9	Venue/Space Öncelik	§9	korundu (ilk-marketplace-domain)
§10	Marketplace Action + PHASES-SEAM	§10	korundu (booking-lifecycle restore)
§11	Discovery	§11	korundu
§12	Discovery Core/Curation	§12	korundu
§13	Control Plane	§13 (+§14/§15/§19)	korundu + genişletildi
§14	Public/App Modülerlik	§20	korundu
§15	Modül Taksonomisi	§22	korundu
§16	Tier≠Otorite	§23	korundu
§17	Entitlement-Ready	§24	korundu
§18	Access Decision Contract	§25	korundu
§19	Erişim Eksenleri	§26	korundu (+visibility-states)
§20	Hibrit Yetki	§27	korundu
§21	User-360 Cockpit	§16	korundu + genelleştirildi (admin-first restore)
§22	Module Contract Ratchet	§28	korundu
§23	AI Konumu	§33	korundu + genişletildi
§24	Sistem Haritası	§35	korundu + güncellendi
§25	Veri Döngüsü	§36	korundu
§26	Geliştirme Sırası	§37	korundu (SEQUENCE-INVARIANT)
§27	Yasaklı Sapmalar	§38	korundu (13/13 + yeni)
§28	Ürün İlkeleri	§39	korundu (25→40)
§29	Nihai Hüküm	§40	korundu + genişletildi
Canon Kabul Sınırı	—	Canon Kabul Sınırı	korundu + genişletildi

YENİ bölümler (eski-karşılığı yok): §14 Contextual Management Surfaces · §15 One Management Grammar · §17 Operational Decision Surface+Loop · §18 Canonical≠Primary-Nav · §19 İki-Eksen · §21 Bounded-Configurability · §29 Cockpit-Foundation-Bounded · §30 Truth-Health/Freshness · §31 Observability · §32 Mutation-Safety · §34 Audit≠Verified-Truth.

Downstream §-ref senkron (yeni accepted-revision'ın AYRI materialization-operasyonunda zorunlu; kabul-event'in kendisi değil — P1-1): CAN-REQ-UCG-012 + CAN-DEC-ADR-006 provenance/related'ında "Doktrin §13/§21" referansları var → eski §21 (User-360) artık §16; §13 (Control Plane) §13 (korundu). Materialization-operasyonunda bu downstream referanslar senkronlanmalı. Uzun-vade önerisi: bölümlere stabil semantic-anchor (DOC-CONTROL-PLANE, DOC-USER360, DOC-MODULE-CONTRACT …) verip downstream CAN-STR-DOCTRINE-001#DOC-USER360 ile referans vermek (numara-kırılganlığını kalıcı çözer). Stabil semantic-anchor'lar bu revizyonda REZERVE edildi (reserved logical reference identifiers) — ilgili başlıklarda 〔anchor: DOC-*〕. Downstream kayıtlar bu semantic-ID'yi TAŞIYABİLİR; ancak URL/Markdown anchor çözümleme-mekanizması materialization/tooling'de doğrulanmadan link-resolvable oldukları VARSAYILMAZ (fake-capability yok) — render/link davranışı ayrıca doğrulanır.

1. DOKTRİNEL TEZ

EventInn, etkinlik üretiminin karar motorudur.

EventInn'in amacı kullanıcıya yalnız mekan, tedarikçi, liste, arama sonucu, rezervasyon ekranı, SaaS aboneliği, AI cevabı veya bir admin paneli sunmak değildir.

EventInn'in temel görevi:

Ham bir etkinlik fikrini, minimum bir kullanıcı niyetini veya profesyonel bir müşteri brief'ini; yapılandırılmış gereksinimlere, karar bağlamına, güvenilir kanıtlara, görünür bilinmeyenlere, karşılaştırılabilir seçeneklere, doğru sonraki aksiyona ve güvenilir marketplace sonuçlarına dönüştürmektir.

EventInn:

• yalnız bir venue listing sitesi değildir,
• yalnız booking sistemi değildir,
• yalnız etkinlik yönetim yazılımı değildir,
• yalnız CMS değildir,
• yalnız AI search ürünü değildir,
• yalnız SaaS abonelik sistemi değildir,
• yalnız bir admin paneli değildir.

EventInn'in asıl stratejik varlığı:

Etkinlik ihtiyacını güvenilir karara ve marketplace aksiyonuna dönüştüren karar altyapısı; bu kararların, operasyonların ve gerçek sonuçların ürettiği nitelikli birikimli veri döngüsüdür.

Ana stratejik zincir:

INTENT / MASTER BRIEF → DECISION CONTEXT → STRUCTURED REQUIREMENTS → REQUIREMENT & DEPENDENCY MODEL → DISCOVERY → CANDIDATES → FIT + EVIDENCE → UNKNOWNS → COMPARE → SHORTLIST → NEXT SAFE ACTION → RFI / RFP / PROPOSAL / MARKETPLACE ACTION → DECISION / OUTCOME → REAL USAGE & QUALIFIED OUTCOME DATA → BETTER EVIDENCE → BETTER REQUIREMENT RELATIONSHIPS → BETTER DECISION ENGINE

Bütün ürün, marketplace, SaaS, admin, AI, kullanıcı yönetimi, entitlement, görünürlük ve yönetim yüzeyi kararları bu büyük sisteme hizmet eder.

2. EVENTINN'İN TEMEL İŞLETİM DOKTRİNİ

EventInn tam bir SaaS sistemi olacaktır. Web, uygulama ve yönetim sistemleri modüler olacaktır. Mevcut bir capability'nin normal işletimi developer müdahalesine bağımlı olmayacaktır.

Temel işletim ilkesi:

KOD İNŞA EDER. CONTROL PLANE YÖNETİR.

Tamamlayıcı ilkeler:

• In-Context yüzey, bir şeyi mümkün olduğunda yaşadığı yerde düzenler.
• Entitlement, ticari erişim otoritesidir.
• Access, role veya tier'a indirgenemez.
• AI önerir, ayrıştırır ve yapılandırır; sessizce gerçek veya yetki üretmez.
• Yetkili insan gerekli yerde onaylar.
• Decision Engine kullanıcıyı doğru karara ve doğru marketplace aksiyonuna taşır.
• Control Plane, platformun işletilebilirlik katmanıdır.

KOD İNŞA EDER → CONTROL PLANE YÖNETİR → CONTEXTUAL MANAGEMENT SURFACES YETKİLİ AKTÖRE DOĞRU YÖNETİM DENEYİMİNİ SUNAR → IN-CONTEXT YÜZEY BİR ŞEYİ YAŞADIĞI YERDE DÜZENLER → ENTITLEMENT TİCARİ ERİŞİMİ BELİRLER → AI ÖNERİR/AYRIŞTIRIR/YAPILANDIRIR → YETKİLİ İNSAN GEREKTİĞİNDE ONAYLAR → KULLANIM, KARAR VE NİTELİKLİ SONUÇ VERİSİ SİSTEMİ BESLER

Normal SaaS operasyonunun yürütülmesi için sürekli kod, SQL, dosya değişikliği veya deploy gerekiyorsa bu varsayılan olarak bir Control Plane veya ürün capability boşluğu olarak değerlendirilir. Developer'ın temel görevi mevcut operasyonu tekrar tekrar elle yürütmek değil, yeni capability inşa etmektir.

3. TEK DECISION ENGINE, ÜÇ KARAR GİRİŞ BİÇİMİ

EventInn üç ayrı karar ürünü oluşturmaz. Tek bir Decision Engine vardır; kullanıcı bu motora üç farklı biçimde girebilir.

MODE 1 — FAST INTENT. Kullanıcı temel ihtiyacını bilir (örn. İstanbul · 200 kişi · Gala · Mart). MINIMUM INTENT → MINIMUM DECISION CONTEXT → DISCOVERY → DECISION GAP → RIGHT QUESTION → BETTER RESULTS. Kullanıcı bütün brief'i doldurmak zorunda değildir. Kullanıcı bildiği kadarını söyler; EventInn karar boşluğunu bulur ve yalnız doğru anda doğru soruyu sorar — bu yaklaşım PROGRESSIVE DECISIONING'dir. Zorunlu uzun-form modeli varsayılan yaklaşım DEĞİLDİR (UZUN FORM → BÜTÜN SORULARI CEVAPLA → SONRA SONUÇ yasaktır).

MODE 2 — GUIDED INTENT. Kullanıcının ihtiyacı vardır ama henüz karar-verilebilir yapıda değildir. OBJECTIVE → AUDIENCE → FORMAT OPTIONS → KNOWN CONSTRAINTS → ADAPTIVE QUESTIONS → DECISION CONTEXT → DISCOVERY. Sistem gereksiz danışmanlık süreci açmaz; yalnız kararı ilerletmek için gerekeni sorar.

MODE 3 — BRIEF INTELLIGENCE / FROM BRIEF TO DECISION. Kullanıcının elinde profesyonel girdi vardır (email, PDF, DOCX, XLSX, technical spec/rider, program draft, brand requirements, client notes, venue specification). Bir profesyonelin brief'i anlaması ile brief'in Decision Engine tarafından kullanılabilecek decision-ready yapıda olması aynı şey değildir. Akış: MASTER BRIEF → UNDERSTAND → EXTRACT → SEPARATE → STRUCTURE → IDENTIFY CONFLICTS → IDENTIFY UNKNOWNS → IDENTIFY DEPENDENCIES → CREATE/ENRICH DECISION CONTEXT → BUILD REQUIREMENT MODEL → CREATE REQUIRED SUB-BRIEFS → START DECISION FLOWS IN CORRECT ORDER. Görev: gelen ana brief'i karar-verilebilir ve uygulanabilir bir modele dönüştürmektir.

4. ÜÇ GİRİŞ, TEK DECISION CONTEXT

Fast / Guided / Brief Intelligence birbirinden bağımsız ürünler değildir; üçü de tek Decision Context modeline akar.

FAST INTENT ───────────────┐
GUIDED INTENT ─────────────┼──→ DECISION CONTEXT
MASTER BRIEF / BRIEF AI ───┘

Decision Context etkinlik kararının uzun-yaşayan omurgasıdır. Geçici form değildir, yalnız search query değildir, bütün sistemi içine alan god-object değildir. Kavramsal olarak taşıyabilir:

IDENTITY · CORE EVENT FACTS · CURRENT DECISION STATE · OBJECTIVE · FORMAT/TYPE · LOCATION SCOPE · DATE WINDOW · FLEXIBILITY · ATTENDANCE RANGE · PEAK ATTENDANCE · CURRENT DECISION GAPS

Not (semantic): ATTENDANCE RANGE (toplam beklenen katılım) ile PEAK ATTENDANCE (aynı anda mekânda bulunacak maksimum) aynı şey değildir; ayrım korunur.

Geniş gereksinimler Requirements katmanında, evidence kendi kanıt yapısında, recommendation/actions kendi katmanlarında, marketplace artefact'ları kendi yaşam döngülerinde yaşar.

DECISION CONTEXT ≠ REQUIREMENT GOD OBJECT ≠ EVIDENCE STORE ≠ RFP ≠ PROPOSAL ≠ PROJECT GOD OBJECT

5. REQUIREMENT VE DEPENDENCY DOKTRİNİ

EventInn brief'i yalnız alanlara bölmez; mümkün olan yerde gereksinimler arasındaki karar ve bağımlılık ilişkilerini modellemelidir. Kavramsal capability: REQUIREMENT GRAPH / DEPENDENCY MODEL.

LIVE BAND → STAGE REQUIREMENT → STAGE SIZE → ROOM DIMENSION FIT
LED WALL → RIGGING / GROUND SUPPORT → CEILING HEIGHT → LOAD CAPACITY → VENUE FIT
800 PERSON DINNER → BANQUET CAPACITY → KITCHEN / CATERING MODEL → SERVICE FLOW

Gerçek karar zekası yalnız "LED wall istendi" demek değil; "bu gereksinimin venue-fit değerlendirmesinde hangi evidence ve dependency'lere ihtiyaç yarattığını" anlayabilmektir. EventInn'in stratejik ayrıştırıcısı yalnız AI Search değil; DECISION CONTEXT + STRUCTURED REQUIREMENTS + DEPENDENCY MODEL + FIT + EVIDENCE + UNKNOWNS + NEXT ACTION bütünüdür.

6. GERÇEK, ÇIKARIM, ÖNERİ VE AKSİYON BİRBİRİNE KARIŞTIRILAMAZ

Temel epistemik ayrımlar:

SOURCE FACT ≠ SYSTEM INFERENCE ≠ CONFIRMED REQUIREMENT ≠ RECOMMENDATION ≠ ACTION

Örn. kaynak "Premium gala experience" → AI bunu FACT olarak "Catering = plated dinner" YAZAMAZ; SYSTEM INFERENCE: formal seated service may be relevant + EPISTEMIC STATE: NEEDS_CONFIRMATION. Unknown geçerli bir karar durumudur. Epistemik durumlar: VERIFIED · SOURCE-KNOWN · LAST-UPDATED · UNKNOWN · NEEDS-CONFIRMATION · CONFLICTING-DATA.

AI'nın görevi bilinmeyeni gizlemek değil; bilinmeyeni görünür kılmak, karar etkisini anlamak ve doğru zamanda doğru doğrulama/sonraki-aksiyonu önermektir. Stratejik invariant:

AI INFERENCE ≠ VERIFIED FACT · RECOMMENDATION ≠ MUTATION · AI-GENERATED CONTENT ≠ HUMAN CONFIRMATION

7. ADAPTIVE SUB-BRIEF SİSTEMİ

Bir Master Brief gerektiğinde alt karar/procurement brief'lerine ayrıştırılabilir (Venue · Space · AV · Production · Catering · Accommodation · Transportation · Security · Decoration · Entertainment · Staffing). Ancak bütün brief türleri her etkinlik için otomatik oluşturulmaz. BRIEF DECOMPOSITION ADAPTIVE OLMALIDIR — ihtiyaç DECISION CONTEXT + REQUIREMENT/DEPENDENCY MODEL + EVENT COMPLEXITY + REAL DECISION OR PROCUREMENT NEED üzerinden belirlenir. AI kafasına göre belge üretmez; yalnız gerçek karar/procurement ihtiyacına hizmet eden karar varlığı doğar.

8. ALT BRIEF'LER YAŞAYAN KARAR VARLIKLARIDIR

Alt brief'ler tek sefer oluşturulup dondurulan statik belgeler değildir. PRELIMINARY REQUIREMENT + NEW EVIDENCE + NEW CONSTRAINT + DECISION = MORE MATURE DECISION ASSET. Yaşam döngüsü ilerleyebilir: IDENTIFIED → PRELIMINARY → NEEDS-EVIDENCE → READY-FOR-RFI → READY-FOR-PROCUREMENT → MARKETPLACE-ACTIVE → DECIDED. Exact state sözlüğü ilgili capability tasarımında belirlenir. Temel invariant: karar henüz olgunlaşmamışsa sistem onu hazır/doğrulanmış brief gibi göstermez.

9. VENUE / SPACE KARAR ÖNCELİĞİ VE BAĞIMLILIK SIRASI

EventInn'in ilk marketplace karar alanı Venue / Space Discovery'dir. Bunun nedeni yalnız MVP sırası değildir: Venue ve Space kararları birçok tedarik gereksinimini önemli ölçüde değiştirir.

MASTER BRIEF → VENUE / SPACE REQUIREMENTS → VENUE / SPACE DECISION → NEW EVIDENCE & CONSTRAINTS → DECISION CONTEXT RE-EVALUATION → SUB-BRIEF MATURATION → SUPPLIER DISCOVERY / PROCUREMENT

İki hüküm birlikte korunur:

• PRODUCT SEQUENCING: Venue / Space = ilk marketplace karar-alanı.
• DECISION LOGIC: Requirement Graph belirli bir etkinlik için farklı bir bağımlılık sırası gösteriyorsa Decision Engine gerçek bağımlılığı izler.

Doktrinel ilke: Karar sırası ekran sırasına göre değil, dependency graph'a göre belirlenir (venue/space önceliği bunu ihlal etmez; çoğu etkinlikte doğal sıradır).

10. DECISION-TO-MARKETPLACE ACTION

Decision Engine yalnız analiz yapan danışman olarak kalamaz; karar marketplace aksiyonuna ulaşmalıdır.

DECISION CONTEXT → DISCOVERY → CANDIDATES → FIT + EVIDENCE → UNKNOWNS → COMPARE → SHORTLIST → NEXT ACTION → RFI → RFP → PROPOSAL → COMPARE → DECISION

RFI öncelikle unknown kapatır. RFP decision-ready + procurement-ready ihtiyacı pazara taşır (serbest-metin "fiyat gönder" değil; Master Brief + Requirement Graph ile izlenebilir). Proposal yapılandırılmış ihtiyaca verilen piyasa cevabıdır. Compare yalnız fiyat karşılaştırması değildir. İzlenebilirlik: MASTER BRIEF → REQUIREMENT → SUB-BRIEF → RFP REQUIREMENT → SUPPLIER RESPONSE → EVIDENCE → FIT → DECISION.

PHASES SEAM (korunur — CAN-STR-PHASES-001). Bu doktrindeki RFI → RFP → Proposal → Compare zinciri, Decision Engine'in marketplace aksiyonuna bağlandığı decision/procurement seam'ini tanımlar; CAN-STR-PHASES-001 Faz-1 ekonomik döngü ve çıkış kriterlerini daraltmaz veya supersede etmez. EventInn DECISION noktasında biten bir ürün DEĞİLDİR; karar-sonrası ekonomik yaşam-döngüsü PHASES-001 altında korunur:

DECISION → INSPECTION / VALIDATION → NEGOTIATION → HOLD / OPTION → CONTRACT → DEPOSIT / COMMERCIAL COMMITMENT → CONFIRMED BOOKING → CHANGE / CANCELLATION → EVENT DELIVERY → POST-EVENT OUTCOME

Bu yön bugün-kodlama emri değildir; geleceğin stratejik ekonomik-döngü yönünü yanlışlıkla kesmeme güvencesidir.

11. DISCOVERY DOKTRİNİ

Discovery generic search değildir. Ana vaat: "Benim etkinlik ihtiyacıma göre hangi seçenekler aday, neden aday, neyi biliyoruz, neyi bilmiyoruz ve şimdi ne yapmalıyım?" Sonuç: DECISION CONTEXT → CANDIDATES → CRITERION FIT → EVIDENCE → UNKNOWNS → DETAIL → SHORTLIST → NEXT ACTION. Fast / Guided / Brief Intelligence akışları aynı Decision Engine'e bağlanır.

12. DISCOVERY CORE VE DATA QUALITY AYRIMI

Müşteri karar deneyimi ile marketplace veri kalitesi aynı ürün sonucu değildir. DISCOVERY CORE: INTAKE · DECISION CONTEXT · CANDIDATES · FIT · EVIDENCE · UNKNOWNS · DETAIL · SHORTLIST · NEXT ACTION. DISCOVERY CURATION / DATA QUALITY: REVIEW · CORRECT · VERIFY · APPROVE · PUBLISH · OWNER CONFIRMATION. Gerçekten iki ayrı ürün sonucu varsa ayrı Feature Train olabilir. PR bir governance fazı değildir; mikro-parçalanma (Faz-1a/1b/p2c/wave-4 türü) varsayılan yöntem değildir (CAN-GOV-DELIVERY-001).

13. CONTROL PLANE DOKTRİNİ 〔anchor: DOC-CONTROL-PLANE〕

EventInn Control Plane tek bir admin ekranından veya yalnız Filament'ten ibaret değildir. Control Plane: platformun var olan capability'lerini güvenli, yetkili ve developer bağımlılığı olmadan işletmesini sağlayan yönetim katmanıdır. Başlıca yönetim biçimleri:

CORE PLATFORM ADMIN  +  CONTEXTUAL MANAGEMENT SURFACES  +  IN-CONTEXT MANAGEMENT

Revision-notu: Mevcut accepted doktrin Control Plane'i Core Admin + In-Context olarak tanımlıyordu. Bu revizyon mevcut Control-Plane yönünü daraltmadan veya tersine-çevirmeden kavramsal genişletir (içerik: preserve+expand; revision-governance: exact-SHA karariyla yeni-revision ACCEPTED olur; current-authoritative-revision ancak AYRI materialization-operasyonu tamamlaninca degisir): Contextual Management Surfaces, platform-operatör dışındaki tenant/workspace/personal yönetim-bağlamlarını tanımlar (§14-§15-§19).

CORE PLATFORM ADMIN platform-seviyesinde yönetir:

system structure · users · roles · memberships · tenants / organizations · plans · subscriptions · entitlements · configuration · module visibility · moderation · security operations · system state · AI provider configuration · bulk operations · operational queues · approved operational parameters

IN-CONTEXT MANAGEMENT bir şeyin yaşadığı ürün yüzeyinde yönetimi sağlar: venue presentation · space presentation · content correction · photos · AI-filled field review · verification · owner confirmation.

Doktrinel ayrım: Filament/Core-Admin = yapı, toplu-işlem, config. In-Context = içerik, sunum, doğrulama, yerinde küratörlük. Temel invariant: bir alanın iki bağımsız ve paralel authoritative yazım yüzeyi bulunamaz — her alanın tek yazım yüzeyi vardır (adr_069 §3.2 ile uyumlu).

14. CONTEXTUAL MANAGEMENT SURFACES DOKTRİNİ 〔anchor: DOC-CONTEXTUAL-MANAGEMENT〕

EventInn'de yönetim yalnız platform super-admin'e ait tek bir admin paneli değildir. Platform operatörü, tenant yöneticisi, workspace yöneticisi/yetkili-üyesi ve bireysel kullanıcı; farklı kapsam ve yetkilerle kendi yönetim bağlamlarına sahip olabilir. Kavramsal süreklilik:

PLATFORM OPERATOR → TENANT ADMIN → WORKSPACE MANAGER / SCOPED MEMBER → PERSONAL USER

Bu süreklilik aynı admin panelinin giderek daha fazla menüsü gizlenmiş kopyaları DEĞİLDİR: LOWER-AUTHORITY MANAGEMENT SURFACE ≠ SUPER-ADMIN UI MINUS HIDDEN MENUS. Her yönetim deneyimi kavramsal olarak ACTOR + ACTIVE CONTEXT + CAPABILITY + SUBJECT + RESOURCE / WORKFLOW STATE üzerinden oluşur. Uzun vadeli model:

ONE DOMAIN TRUTH + ONE ACCESS LANGUAGE + ONE MANAGEMENT GRAMMAR + MULTIPLE CONTEXTUAL SURFACES + MULTIPLE ENTITY COCKPITS

Aynı user principal farklı bağlamlarda farklı-ama-tutarlı projeksiyonlarla görülebilir: PLATFORM: User as platform principal · TENANT: User @ Tenant · WORKSPACE: User @ Workspace · PERSONAL: My Account / My Personal Workspace. Korunan invariant: PERSONAL WORKSPACE ≠ TENANT.

15. TEK YÖNETİM GRAMERİ, TEK UI DEMEK DEĞİLDİR

Platform operator, tenant admin, workspace manager ve personal user aynı fiziksel arayüzü kullanmak zorunda değildir. Ortak olması hedeflenen (semantic): domain truth · actor/context/capability semantics · authorization discipline · security ceilings · safe mutation discipline · audit expectations · appropriate projection semantics. Ortak olmak zorunda olmayan (presentation): shell · navigation · layout · component tree · interaction model · information density.

Doktrinel ilke: SHARED SEMANTICS ≠ SHARED PRESENTATION. Universal cross-framework page engine zorunlu değildir; her yüzey kendi aktörünün görevine ve kullanım bağlamına göre tasarlanabilir.

16. ENTITY CONTROL COCKPIT DOKTRİNİ 〔anchor: DOC-ENTITY-COCKPIT / DOC-USER360〕

Uzun-yaşayan ve çok-domainli bir entity'nin yönetimi yalnız basit CRUD formuna indirgenemez. Cockpit: bir entity hakkındaki dağıtık gerçekleri, ilişkileri, durumları, dikkat-noktalarını ve yetkili-aksiyonları anlamlı bir yönetim kompozisyonunda birleştiren operational decision surface'tir. Adaylar: USER · TENANT/ORGANIZATION · VENUE · SUPPLIER · SPACE (karmaşıklık haklı çıkarırsa). Her resource cockpit olmak zorunda değildir (TAG · CITY · SIMPLE LOOKUP normal resource kalır). COCKPIT ≠ GOD FORM — cockpit bütün verinin yeni source-of-truth'u değildir; COMPOSES · EXPLAINS · CONNECTS · PRIORITIZES · LAUNCHES SAFE ACTIONS. Domain truth ve canonical mutation yolları korunur.

Human-CEO ilkesi (korunur — admin-first management): Bir kullanıcıya ilişkin bugün mevcut ve gelecekte doğacak yönetilebilir/görülebilir özellikler, uygun yetki ve bağlam sınırları içinde User-360 Control Cockpit'ten görünür, yönetilebilir veya doğru canonical yönetim yüzeyine ulaşılabilir olmalıdır. Yani "her şey aynı kartta doğrudan edit edilir" değil:

VISIBLE  OR  MANAGEABLE  OR  REACHABLE THROUGH CANONICAL ACTION / DEEP-LINK

User-360 = Entity Control Cockpit deseninin İLK REFERANS UYGULAMASIDIR. Yüksek-seviye referans blueprint (User-360 v1.3 = ilk-referans için FROZEN feature-spec; CAN-REQ-UCG-012 [accepted @2026-07-15] genel-UC + CAN-DEC-ADR-006 [accepted @2026-07-15] mimari-governance kayıtları — her biri kendi bağımsız lifecycle-statüsüne tabi (accepted ≠ effective ≠ impl-authority); çifte source-of-truth üretilmez):

Identity & Lifecycle · Platform Role · Workspace/Tenant Memberships · Plan/Subscription · Effective Entitlements · Effective Access—WHY? · Security/Sessions · Privileged Actions · Audit Trail

WHY? / effective-access / effective-visibility alanları resolver-ready slot olarak doğar; açıklama-motoru yokken yapay biçimde doldurulmaz (§6 epistemik-ayrımlar + §25 Access Decision Contract + §38 Fake Cockpit Intelligence yasağı).

17. OPERATIONAL DECISION SURFACE VE OPERATIONAL DECISION LOOP

Cockpit'in amacı yalnız daha fazla bilgiyi aynı ekrana koymak değildir. Bilgi yoğunluğu ≠ operasyonel değer. İyi bir cockpit, uygun olduğu ölçüde şu soruları cevaplar: WHAT IS TRUE? · WHAT NEEDS ATTENTION? · WHAT CHANGED? · WHAT IS UNKNOWN? · WHAT CAN I SAFELY DO NEXT? Kavramsal operasyon döngüsü:

ENTITY TRUTH → CONTEXT & RELATIONSHIPS → STATE / HEALTH / EXCEPTIONS → UNKNOWNS / ATTENTION NEEDS → PRIORITY → SAFE NEXT ACTION → AUTHORIZED MUTATION → AUDIT / OUTCOME → UPDATED ENTITY TRUTH

Bu, müşteri-tarafı Decision Engine'in kopyası değildir: müşteri-tarafı etkinlik-kararını yapılandırır; cockpit ise insan-operatörün/yetkili-aktörün platform-gerçeğini anlamasını ve güvenli-yönetim-kararı almasını destekler.

18. CANONICAL RESOURCE ≠ PRIMARY NAVIGATION ITEM

Bir resource'un canonical management primitive olarak var olması, ana-menüde doğrudan görünmesi gerektiği anlamına gelmez. Primary navigation kullanıcı-görevlerine göre küratörlenir:

CONTROL CENTERS → DOMAIN / OPERATIONAL WORK AREAS → ENTITY COCKPITS → gerektiğinde SPECIALIST / CANONICAL PRIMITIVE

Düşük-seviye resource'lar deep-link / specialist-surface / secondary-navigation / internal-primitive olarak yaşayabilir. Mevcut resource karmaşası cockpit katmanının ALTINDA aynen sürdürülemez. MENU VISIBILITY ≠ AUTHORIZATION — menü/buton gizlemek güvenlik-kararı yerine geçmez (server-side-authz zorunlu).

19. MANAGEMENT SURFACE VE ENTITY COCKPIT İKİ AYRI EKSENDİR

EventInn'in yönetim modeli iki boyutludur. ACTOR / MANAGEMENT SURFACE: PLATFORM OPERATOR · TENANT ADMIN · WORKSPACE MANAGER · PERSONAL USER. ENTITY / COCKPIT: USER · TENANT · VENUE · SUPPLIER · SPACE. Gerçek deneyim:

ACTOR SURFACE × ACTIVE CONTEXT × ENTITY COCKPIT × AVAILABLE CAPABILITIES × RESOURCE / WORKFLOW STATE

üzerinden oluşur. Bu nedenle "her role için ayrı panel yazmak" ile "aynı panelden menü saklamak" EventInn'in uzun-vadeli yönetim modeli DEĞİLDİR.

20. PUBLIC VE STATEFUL APP MODÜLERLİĞİ AYNI ŞEY DEĞİLDİR

PUBLIC CONTENT SURFACE: DB-COMPOSED · PANEL-COMPOSABLE olabilir (home, landing, SEO, category, campaign — WordPress-benzeri composition). PRODUCT / MANAGEMENT WORKFLOW SURFACE: CODE-ORCHESTRATED · MODULE-REGISTERED · PANEL-CONFIGURABLE · AUTHORIZATION-AWARE · ENTITLEMENT-READY olmalıdır (Decision Context, Discovery, Compare, Shortlist, RFI/RFP/Proposal, User Management, Supplier Workspace, cockpit'ler). Stateful ürün/yönetim workflow'ları unrestricted drag-and-drop page builder'a dönüştürülemez. Hüküm: PUBLIC FULL-COMPOSABLE; STATEFUL APP CODE-ORCHESTRATED + MODULE-REGISTERED. App capability'si kayıtlı · görünürlük-yönetimli · konfigüre-edilebilir · permission-namespace · entitlement-ready · audit-edilebilir · ölçülebilir doğar.

21. BOUNDED CONFIGURABILITY

Panelden yönetilebilirlik, kodun güvenlik ve semantic sınırlarının runtime'da keyfi değiştirilmesi anlamına gelmez:

CODE = CAPABILITY + SECURITY CEILING
CONTROL PLANE = PERMITTED CONFIGURATION
IN-CONTEXT MANAGEMENT = PERMITTED CONTENT / PRESENTATION MANAGEMENT

Control Plane: code-security-ceiling'i gevşetemez · tenant-isolation'ı kaldıramaz · authoritative-ownership'i keyfi değiştiremez · unrestricted universal page-builder'a dönüşemez.

22. MODÜL TAKSONOMİSİ

Aşağıdaki kavramlar aynı değildir: ROLE ≠ TIER ≠ ENTITLEMENT ≠ FEATURE ≠ MODULE ≠ MENU ≠ PERMISSION. Beş temel modül sınıfı: Content Module (hero, featured, trust-strip, CTA) · Product Capability Module (venue_discovery, decision_compare, shortlist, rfp, supplier_inbox) · Commercial Module (ADVANCED_DISCOVERY, RFP_MODULE, TEAM_COLLABORATION, ADVANCED_ANALYTICS) · Operational Module (user management, venue review queue, module visibility, plans, subscriptions, AI provider config) · Policy/Permission Capability (venue.description.edit, user.role.assign, rfp.send). Kavram-kaybına yol açan mega-model kurulamaz.

23. TIER OTORİTE DEĞİLDİR

TIER = TİCARİ ETİKET / PROJEKSİYON · ENTITLEMENT = TİCARİ ERİŞİM OTORİTESİ. Gerçek SaaS ticareti bileşik erişim üretir:

PLAN + PLAN FEATURES/LIMITS + SUBSCRIPTION + ADD-ONS + TRIALS + MANUAL GRANTS − REVOCATIONS = EFFECTIVE ENTITLEMENTS

tenant.tier bir label/projection olabilir; erişim source-of-truth'u olamaz.

24. ENTITLEMENT-READY, ENTITLEMENT ENGINE DEMEK DEĞİLDİR

Yeni capability'ler entitlement-ready doğmalıdır (discovery.basic, discovery.advanced_filters, decision.fit_evidence, shortlist.create). Ancak her feature-train içinde plan-UI / purchase / quota-engine / payment-integration / full-entitlement-resolver YAZILMAZ. ENTITLEMENT-READY ≠ ENTITLEMENT ENGINE IMPLEMENTATION. Gerçek entitlement sistemi kendi scope + Feature-Train'iyle doğar.

25. ACCESS DECISION CONTRACT 〔anchor: DOC-ACCESS-CONTRACT〕

EventInn uzun vadede ortak bir erişim karar dili kullanmalıdır: can(actor, capability, subject, context). Olası sonuç sınıfları ilgili tasarımda gelişebilir: ALLOWED · DENIED · HIDDEN · READ_ONLY · UPSELL · NEEDS_CONFIRMATION · BLOCKED_BY_STATE. Ancak: ORTAK CONTRACT ≠ BIG-BANG ACCESS KERNEL. Temel uygulama ilkesi: SÖZLEŞME ÖNDEN DONAR; MOTOR GERÇEK İHTİYAÇLA BÜYÜR (user.* → discovery.* → rfp.* → supplier.* gerçek-capability geldikçe). BIG-BANG KERNEL İNŞASI YASAKTIR. Tek motor = tek mega-tablo değil; ortak karar sözleşmesi.

26. ERİŞİM KARARI AYRI EKSENLERDEN OLUŞUR

ROLE / MEMBERSHIP · POLICY · ENTITLEMENT · VISIBILITY · RESOURCE / WORKFLOW STATE · CONTEXT birbirinden farklıdır. Kavramsal formül:

EFFECTIVE ACCESS = CODE SECURITY CEILING ∩ CONTEXT MEMBERSHIP ∩ ROLE / CAPABILITY GRANT ∩ ENTITLEMENT ∩ VISIBILITY ∩ RESOURCE / WORKFLOW STATE

VISIBILITY yalnız boolean visible/not-visible değildir. Örnek presentation-states: SHOW / HIDE / LOCK / BLUR / READ_ONLY / UPSELL / INHERIT — exact vocabulary ilgili capability kararında belirlenir.

Bu eksenler tek role/tier/mega-tabloya indirgenerek kavram-kaybına uğratılamaz.

27. HİBRİT YETKİ MODELİ

Güvenlik-tavanı kodda kalır; operasyonel/evrilebilir grants Control Plane'ce yönetilebilir. CODE SECURITY CEILING (panel-gevşetemez): tenant isolation · self-demote prohibition · last-super-admin protection · owner boundary · legal hold · irreversible action controls · re-auth · privileged assignment ceiling. ADMIN-MANAGED GRANTS (operasyonel): venue.description.edit · venue.photos.manage · user.locale.edit · user.phone.edit · space.capacity.propose. Formül: EFFECTIVE PERMISSION = CODE CEILING ∩ ADMIN-CONFIGURED GRANT ∩ RESOURCE CONTEXT. Panel grant verse bile code-ceiling RED ise sonuç DENIED. Super Admin dahi güvenlik ve governance sınırlarının dışında değildir.

28. MODULE CONTRACT VE COCKPIT CONTRACT BİRBİRİNİN YERİNE GEÇMEZ 〔anchor: DOC-MODULE-CONTRACT〕

Yeni gerçek capability için uygulanabilir olduğu ölçüde Module Contract zorunludur (module_key · capability_key · surface · configuration_schema · entitlement_key · permission_namespace · visibility_policy · audit_events · metrics · lifecycle_status). Cockpit Definition = bir entity/capability'nin yönetim-kompozisyonunda nasıl temsil edildiği. COCKPIT DEFINITION ≠ MODULE CONTRACT — Cockpit Definition bütün permission/entitlement/visibility/metrics/lifecycle kavramlarını yutan mega-contract'a dönüşemez. Ratchet: yeni capability → Module Contract zorunlu; mevcut capability → dokunuldukça uyumlanır. Retro big-bang yeniden-yazım programı varsayılan değildir.

29. COCKPIT FOUNDATION BOUNDED OLMALIDIR

Birden fazla cockpit tüketicisi bilindiği için ortak semantic foundation baştan tasarlanabilir. Ancak FOUNDATION UPFRONT ≠ EVERYTHING UPFRONT. Ortak foundation: semantic contracts · composition boundaries · context & authority · safe action discipline · projection principles · navigation principles tanımlayabilir. Fakat: bütün cockpit'ler şimdi yazılmaz · bütün section-tipleri şimdi genelleştirilmez · universal mega-framework kurulmaz · bütün UI-framework'leri tek rendering-engine'e zorlanmaz. Omurga baştan doğru; kaslar gerçek ihtiyaçla büyür.

30. TRUTH HEALTH, FRESHNESS VE PARTIAL FAILURE

Çok-kaynaklı yönetim yüzeylerinde: NO DATA ≠ SOURCE UNAVAILABLE ≠ STALE DATA ≠ UNKNOWN. Bir projection-kaynağının okunamaması gerçek-veri-yokluğu gibi gösterilemez. Foundation ileride şu truth-health durumlarını destekleyebilecek biçimde açık kalır: CURRENT · LAST-UPDATED · STALE · REFRESHING · UNAVAILABLE · UNKNOWN (exact-vocabulary ilgili NFR/Rule/UX'te). Bir section'ın başarısızlığı mümkün olduğunda bütün cockpit'i zorunlu çökertmemelidir. PARTIAL FAILURE ≠ FALSE EMPTY STATE.

31. OPERATIONAL OBSERVABILITY

Cockpit ve management-composition opaque black-box olamaz. İhtiyaç doğduğunda gözlemlenebilir olması gereken alanlar: section/projection health · source failures · latency · action outcomes · authorization denials · bulk partial outcomes · audit correlation. Exact telemetry-schema ve performans-bütçeleri ilgili NFR/implementation kararlarında belirlenir (bu doktrinde dondurulmaz).

32. MUTATION SAFETY

Hangi yüzeyden gelirse gelsin mutation-disiplini korunur: ACTOR → CONTEXT → CAPABILITY / AUTHORIZATION → DOMAIN / SECURITY RULES → AUTHORITATIVE MUTATION → AUDIT. Cockpit veya başka management-surface, güvenliği bypass eden ikinci mutation-kanalı OLAMAZ. Non-trivial/retryable/privileged/bulk işlemler platformun idempotency · concurrency · authorization · guard · audit politikalarını miras alır (exact-mekanizma bu doktrinde dondurulmaz).

33. AI'NIN EVENTINN'DEKİ KONUMU 〔anchor: DOC-AI〕

AI EventInn'in ürünü değildir; AI: Decision Engine'in ve gerektiğinde platform-operasyonlarının capability'sidir. Yardımcı olabileceği alanlar: brief understanding · requirement extraction · conflict/unknown/dependency detection · adaptive questioning · sub-brief decomposition · candidate explanation · evidence synthesis · next-action recommendation · proposal comparison assistance · operational anomaly explanation. AI: sessizce ownership değiştiremez · gerçeklik-durumu üretemez · verified-evidence ilan edemez · security-ceiling'i aşamaz · yetkili-action zincirini bypass edemez. RECOMMENDATION ≠ MUTATION · AI INFERENCE ≠ VERIFIED FACT · AI-GENERATED CONTENT ≠ HUMAN CONFIRMATION. AI'nın stratejik değeri daha fazla metin üretmek değil; dağınık bilgiyi karar-verilebilir yapıya dönüştürmek ve doğru karar-boşluğunda doğru aksiyonu önermektir.

34. OPERATIONAL ACTION ≠ VERIFIED TRUTH

Bir kullanıcının cockpit/management-surface üzerinde işlem yapması bir AUDIT EVENT üretir. Bu olay kendiliğinden VERIFIED FACT / EVIDENCE / LEARNING TRUTH DEĞİLDİR: AUDIT EVENT ≠ SOURCE FACT ≠ VERIFIED EVIDENCE ≠ LEARNING SIGNAL. Operator-correction/verification/owner-confirmation/moderation gibi olaylar; provenance ve semantic-qualification sağlandığında Data-Quality/Evidence/Compounding-Data-Loop için değerli sinyale dönüşebilir: OPERATOR ACTION → AUDIT EVENT → SEMANTIC CLASSIFICATION → gerekirse VERIFICATION → QUALIFIED EVIDENCE / DATA-QUALITY SIGNAL → COMPOUNDING DATA LOOP. Bu promotion sessizce yapılamaz.

35. EVENTINN'İN BÜYÜK SİSTEM HARİTASI

                              EVENTINN — EVENT DECISION INFRASTRUCTURE
          ┌──────────────────────────────┼──────────────────────────────┐
   DECISION ENGINE                    MARKETPLACE                      SaaS ENGINE
   Decision Intake                    Venue / Space                    Plans
   Decision Context                   Supplier                         Features / Limits
   Brief Intelligence                 Claim / Verification             Subscriptions
   Requirement & Dependency Model     Discovery                        Entitlements
   Evidence · Unknowns · Fit          Shortlist · RFI / RFP            Add-ons
   Compare · Next Action              Proposal · Marketplace Action    Usage / Quotas
          └──────────────────────────────┼──────────────────────────────┘
                              ACCESS DECISION LANGUAGE
              Actor · Context · Capability · Subject · Role · Membership
              Policy · Entitlement · Visibility · Workflow State
          ┌──────────────────────────────┼──────────────────────────────┐
   PUBLIC SURFACE                   PRODUCT SURFACES                 MANAGEMENT SURFACES
   Composed CMS                     Personal Workspace               Platform Operator
   SEO / Landing                    Decision Experience              Tenant Admin
                                    Discovery · Compare              Workspace Manager
                                    Marketplace                      Personal User · In-Context
                                                                            │
                                                                     ENTITY COCKPITS
                                                         User · Tenant · Venue · Supplier
                                                                            │
                                                                DATA & AI FOUNDATION
                                          Provenance · Evidence · Search · Scoring
                                          AI Providers · Cost Governance · Audit
                                          Compounding Data Loop · Metrics

36. STRATEJİK VERİ DÖNGÜSÜ 〔anchor: DOC-DATA-LOOP〕

EventInn'in sürdürülebilir farkı yalnız feature-set değildir: MORE DECISIONS → MORE MARKETPLACE ACTIONS → MORE REAL OUTCOMES → MORE QUALIFIED EVIDENCE → BETTER REQUIREMENT RELATIONSHIPS → BETTER FIT → BETTER UNKNOWN DETECTION → BETTER NEXT ACTION → BETTER DECISIONS. In-Context veri-kalitesini artırır; owner-confirmation gerçeklik-doğrulamasına katkı sağlar; RFI unknown kapatır; RFP+Proposal gerçek-piyasa-cevabı üretir; cockpit-operasyonları doğru semantic-qualification ile veri-kalitesi/operasyon-öğrenimi sağlar. COMPOUNDING DATA LOOP, EventInn'in stratejik varlıklarından biridir.

37. VARSAYILAN STRATEJİK GELİŞTİRME YÖNÜ

Varsayılan yön (mevcut stratejik-sıra KORUNUR):

USER MANAGEMENT
  ( + USER360 FIRST REFERENCE IMPLEMENTATION + BOUNDED COCKPIT FOUNDATION SEED )
↓
DISCOVERY CORE
↓
DISCOVERY CURATION / DATA QUALITY   (gerekiyorsa ayrı gerçek Feature Train)
↓
ENTITLEMENT & ACCESS
↓
MARKETPLACE ACTION   (RFI → RFP → PROPOSAL → COMPARE)
↓
SUPPLY SaaS
↓
ADVANCED SaaS MONETIZATION

SEQUENCE INVARIANT (AI-CEO redline): Cockpit / Control Plane Foundation, Discovery'den ÖNCE tamamlanması zorunlu ayrı/bağımsız bir stratejik-aşama DEĞİLDİR. Cockpit Foundation, User-Management / User-360 ile birlikte doğan bounded-foundation-seed'dir (ilk gerçek tüketiciyle egzersiz edilir). Bunun ayrı bir big-bang "Cockpit Foundation programı"na dönüşmesi, ancak Human-CEO'nun roadmap-doktrinini ayrıca değiştirmesiyle olur.

Brief Intelligence / From Brief to Decision bu üst-stratejinin ayrılmaz ürün-yönüdür; ancak implementasyonu mevcut MVP akışını big-bang biçimde durduramaz — kendi Scenario/UC/Rule/Feature-Train zincirinde gerçek-ihtiyaç + kabul-edilmiş-kapsamla doğar. Tenant / Workspace / Personal Management-Surface'lerin teslimat-sırası ilgili ürün-ihtiyacı + Human-CEO roadmap-kararıyla belirlenir.

Bu doktrin "her şeyi şimdi kodla" emri DEĞİLDİR; yeni yapılan her şeyin hangi büyük sisteme ait olduğunu ve hangi yöne büyümesi gerektiğini belirleyen yön-sınırıdır. Gerçek ürün-bağımlılığı, güvenlik-riski ve Human-CEO roadmap-kararı sıralamayı değiştirebilir.

38. YASAKLI STRATEJİK SAPMALAR

• Generic Listing Regression — SEARCH → LIST → DETAIL tek başına EventInn ürünü değildir; Discovery Decision-Context/Fit/Evidence/Unknown/Next-Action yönünü korur.
• Mandatory Long Brief — Kullanıcı bütün brief'i tamamlamadan değer göremiyorsa Progressive Decisioning ihlal edilmiştir.
• Silent AI Assumption — AI inference confirmed-fact'a çevrilemez.
• Fake Intake Promise — Çalışmayan capability aktif ürün-vaadi olarak sunulamaz; Brief Intelligence çalışmadan "Brief'imi Analiz Et" girişi aktive edilemez.
• Tier-as-Authority — Tier ticari-erişim source-of-truth'u olamaz.
• Big-Bang Access Kernel — Ortak-contract bahanesiyle mega altyapı/yıllık-platform projesi açılamaz.
• Entitlement Inside Unrelated Feature Train — Entitlement-ready olmak full-monetization-engine yazma yetkisi değildir.
• App-as-Unrestricted-Page-Builder — Stateful ürün/yönetim workflow'ları serbest CMS'e çevrilemez.
• Dual Write Surfaces — Aynı alan iki bağımsız authoritative-yazım-yüzeyinden yönetilemez.
• God Cockpit / God Form — Bütün domain-gerçekleri tek form/mega-object'e sıkıştırılamaz.
• Cockpit Inflation — Her resource otomatik cockpit olamaz.
• Super-Admin-UI-Downscaling — Tenant/workspace/personal yüzeyler super-admin-UI'dan yalnız menü-saklayarak türetilemez.
• Menu-as-Security — Menü/buton gizlemek authorization yerine geçemez.
• Universal UI Kernel — Ortak semantic-contract bahanesiyle bütün shell'leri tek UI-engine'e zorlama programı açılamaz.
• Audit-as-Truth — Bir operasyon-kaydı kendiliğinden verified-fact/evidence sayılamaz.
• Fake Cockpit Intelligence — Gerçek motor yokken WHY / effective-access / effective-visibility / AI-insight uydurulamaz.
• Canonical Resource Menu Sprawl — Bir resource'un var olması primary-navigation'da görünmesini zorunlu kılmaz.
• Retro Module Contract Program — Bütün legacy capability'ler sırf-uyum için topluca yeniden-yazılmaz.
• AI-as-Product — "AI destekli" söylemi karar-kalitesinin yerine geçirilemez.
• Micro-Phase Delivery — Gerçek-risk veya bağımsız-ürün-sonucu sınırı olmadan feature'lar aşırı mikro (faz/wave/paket) bölünemez.
• Silent Scope/Sequence Change — Bu Canon-kaydının (CAN-STR-DOCTRINE-001) gelecekteki revision'ları mevcut normatif-kapsamı veya stratejik-sırayı değiştiriyorsa, bunu açık revision-summary + impact-analysis ile belirtmelidir (sessiz-daraltma/değiştirme yok). (Tüm-Canon revision-governance politikasını tanımlamaz — o CAN-GOV-LCYCLE-001'dedir.)

39. DOKTRİNEL ÜRÜN VE İŞLETİM İLKELERİ

1. EventInn, etkinlik üretiminin karar motorudur. 2. Üç intake tek Decision Engine + tek Decision Context'e akar. 3. Kullanıcı bildiği kadarını söyler; sistem karar-boşluğunda doğru soruyu sorar. 4. Minimum intent değer üretmeye başlamak için yeterli olabilir. 5. Source-fact, inference, recommendation ve action birbirine karıştırılmaz. 6. Unknown geçerli bir karar durumudur. 7. Önemli kararlar mümkün olduğunca kaynak+bağlama izlenebilir olmalıdır. 8. Alt brief'ler yaşayan karar-varlıklarıdır. 9. Brief decomposition adaptive'dir. 10. Karar-sırası gerçek bağımlılığa göre belirlenir. 11. RFI unknown kapatır. 12. RFP decision-ready ihtiyacı pazara taşır. 13. Proposal ana-gereksinim-zincirinden kopuk değerlendirilemez. 14. Recommendation ≠ mutation. 15. AI inference ≠ verified fact. 16. Kod inşa eder; Control Plane yönetir. 17. Bir şey mümkün olduğunda yaşadığı yerde yönetilir. 18. Control Plane yalnız super-admin paneli değildir. 19. Lower-authority surface, super-admin UI eksi gizli-menüler değildir. 20. One domain truth + one access language + one management grammar + multiple contextual surfaces. 21. Same semantics ≠ same presentation. 22. Personal Workspace ≠ Tenant. 23. Menu visibility ≠ authorization. 24. Cockpit bir dashboard değil, operational decision surface'tir. 25. Bilgi-yoğunluğu tek başına cockpit-değeri değildir. 26. Cockpit composes; authoritative mutation-rules korunur. 27. Canonical resource ≠ primary navigation item. 28. Tier ticari-etikettir; Entitlement ticari-erişim otoritesidir. 29. Tek erişim-motoru tek mega-tablo değil, ortak karar dilidir. 30. Contract-first; engine demand-driven büyür. 31. Public composable; stateful app code-orchestrated'dır. 32. Yeni capability modüler, yetkilendirilebilir, entitlement-ready, görünürlük-yönetimli, audit-edilebilir ve ölçülebilir doğar. 33. Cockpit Definition, Module Contract'ın yerine geçmez. 34. Foundation upfront olabilir; universal mega-framework olamaz. 35. Partial source-failure gerçek-veri-yokluğu gibi gösterilemez. 36. Audit event kendiliğinden verified-truth değildir. 37. Operasyonel/marketplace outcome'lar ancak nitelikli-provenance ile Compounding Data Loop'u besler. 38. Feature Train gerçek-ürün-sonucu veya gerçek-risk sınırına göre bölünür. 39. AI Search tek başına moat değildir. 40. EventInn'in moat'ı karar-problemini modelleyen ve gerçek-sonuçlarla güçlenen karar-altyapısıdır.

40. NİHAİ STRATEJİK HÜKÜM

EventInn'in geleceği daha fazla sayfa, admin-formu, mekan-kaydı, menü veya AI-cevabı üretmek değildir. EventInn'in geleceği: etkinlik üretiminin dağınık bilgi ve karar problemini; izlenebilir, güvenilir, bağlam-duyarlı ve marketplace-aksiyonuna dönüşebilen bir karar sistemine dönüştürmektir.

Müşteri tarafında INTENT-TO-DECISION + BRIEF-TO-DECISION + DECISION-TO-MARKETPLACE ACTION işler. Platform/SaaS işletim tarafında DOMAIN TRUTH + CONTEXTUAL MANAGEMENT + ENTITY COCKPITS + SAFE ACTIONS + AUDIT & QUALIFIED OUTCOMES işler. Bunlar kopuk sistemler değildir: Customer Decision Engine kullanıcının etkinlik-kararını yapılandırır; Control Plane ve Contextual Management Surfaces, EventInn'in insan-aktörlerinin platformu kendi yetki+bağlamları içinde güvenli işletmesini sağlar; Entity Cockpit'ler dağıtık gerçekleri birleştirerek doğru operasyonel-karara ve güvenli sonraki-aksiyona ulaşmayı kolaylaştırır. Entitlement SaaS-erişimini paketler; Access Decision Language "kim, hangi context'te, hangi capability üzerinde ne yapabilir" sorusunu tutarlı kılar; AI dağınık bilgiyi karar-yapısına dönüştürür; insan-doğrulaması ve nitelikli-provenance güven üretir; gerçek kullanım/karar/sonuç verisi Decision Engine'i güçlendirir.

Bu nedenle EventInn:

HAM BİR ETKİNLİK FİKRİNİ VEYA PROFESYONEL BİR MASTER BRIEF'İ; YAPILANDIRILMIŞ GEREKSİNİMLERE, KARAR BAĞLAMINA, YAŞAYAN KARAR VARLIKLARINA, VENUE/SPACE VE TEDARİKÇİ KARAR AKIŞLARINA VE GÜVENİLİR MARKETPLACE AKSİYONLARINA DÖNÜŞTÜREN; AYNI ZAMANDA KENDİ PLATFORMUNU CONTEXTUAL MANAGEMENT SURFACES VE ENTITY CONTROL COCKPITS İLE İŞLETİLEBİLİR KILAN MODÜLER, CONTROL-PLANE-DRIVEN SaaS KARAR ALTYAPISIDIR.

En kısa stratejik ifade değişmez:

ETKİNLİK ÜRETİMİNİN KARAR MOTORU.

---

CANON KABUL SINIRI

Bu doktrinin kabulü, burada anılan bütün gelecekteki capability'lerin implementasyonuna, merge'üne, deploy'una veya aktive edilmesine kendiliğinden yetki vermez. Her somut capability SCENARIO → UC → RULE/POLICY → gerekirse ADR → FEATURE TRAIN → CODE → TEST/VERIFY → HUMAN CEO ACCEPTANCE zincirinde kendi kapsam ve risk-sınırlarıyla ilerler.

Bu doktrin: bütün cockpit'leri şimdi build-etme · bütün management-surface'leri şimdi build-etme · universal UI-engine kurma · big-bang Access Kernel geliştirme · gelecekteki bütün section/capability tiplerini bugünden kodlama yetkisi VERMEZ.

• Brief Intelligence, privacy/retention/disposition/provider-data-processing kapıları tamamlanmadan aktive edilemez.
• Contextual Management yüzeyleri, actor/context/capability güvenlik-sınırları tanımlanmadan aktive edilemez.
• Privileged mutations, gerekli authorization/guard/audit önkoşulları olmadan açılamaz.

Yaşam döngüsü ilkesi: Kabul ≠ effective ≠ implementation ≠ merge ≠ deploy.

---

CAN-STR-DOCTRINE-001 · governance_status: accepted (Human-CEO exact-SHA kabulü "KABUL EDİYORUM", 15 Tem 2026 — çift-SHA künye = extensions.acceptance; source fef3c76 / blob 1f6b4b8; R4 İnsan-CEO; panel-CRLF-fallback klasik-materialize; accepted ≠ effective) · v2-accept-anchor: commit fef3c76 / blob 1f6b4b8 · Orijinal-accept-anchor (immutable): commit 47b6a2c / blob e9ca83f · Revision-base: commit 3495aca / blob 536cfb9 · Bu kayıt artık authoritative canon-path'te ACCEPTED (kabul-edildi; accept ≠ effective ≠ materialize); önceki accepted-içerik acceptance_anchor'da (47b6a2c/e9ca83f) immutable · Superset yeniden-yazım: AI-CEO (rewrite) + Müdür (gap-analizi restorasyonları) + AI-CEO redline2 (superset-kuralı + sequence-koruma) · Üst-ilişki: CAN-STR-PHASES-001 (faz-stratejisi, §10 PHASES-SEAM) tamamlayıcı. accepted ≠ effective.