CAN-STR-ORGOS-001 — Organization Operating System & Collaboration Doktrini

Konum: CAN-STR-DOCTRINE-001'e bağlı alan-doktrini — onun rakibi veya revizyonu DEĞİLDİR. Üst-doktrin "EventInn nasıl bir sistemdir?" sorusunu cevaplar; bu doktrin "şirketler EventInn içinde nasıl kimlik kazanır, insanlarla ve başka şirketlerle nasıl çalışır, karar ve yetki sınırları nasıl korunur?" sorusunu cevaplar. Karar sahibi: Human CEO. Uyumluluk-kısıtı: CAN-DEC-ADR-002 (USER ≠ ORGANIZATION ≠ TENANT ≠ WORKSPACE) mevcut kabul-edilmiş kavramsal-kararlarıyla bağlayıcı kalır — bu doktrin ona ters düşmez, fakat stratejik otoritesini ondan türetmez (otorite = üst-doktrin).

YORUMLAMA SINIRI — Bu kayıtta geçen Decision Rights, Approval Authority, Shared Context, Trust-Profile, Organization-Graph, kurumsal-hafıza ve benzeri adlar stratejik kavram/seam'lerdir; fiziksel tablo, kolon, API-imzası, class, enum, exact state-machine veya implementation-schema kararı oluşturmaz. Metindeki capability-adları (org.decision.rfp_start vb.) non-normative örnek-adlardır (bağlayıcı-adlandırma-sözleşmesi değil; fiziksel adlar Rule/Access-Contract aşamasında doğar). Mevcut kabul edilmiş UC/Rule/ADR kayıtlarını sessizce amend etmez. Somut kararlar CAN-GOV-HIER-001 zincirinde (Scenario → UC → Rule → ADR → Feature Train) türetilir.

ÜST-DOKTRİN SEAM'İ — Bu doktrin, CAN-STR-DOCTRINE-001'in hiçbir hükmünü daraltmaz veya supersede etmez; onun yönetim-sürekliliği (platform-operator → tenant-admin → workspace-manager → personal-user), Access Decision Contract (§25), erişim-eksenleri (§26), hibrit-yetki (§27), Control-Plane ve işletim-modeli hükümlerinin Organization-alanına uygulanışını tanımlar.

1. TEMEL TEZ

EventInn'de Organization, bir şirket profil-kaydı değil; insanların, karar haklarının, çalışma bağlamlarının, ticari hakların ve dış iş birliklerinin birleştiği kurumsal işletim kimliğidir.

Tenant ise ürün-kimliği değil, teknik izolasyon konteyneridir. Kullanıcı tenant'a ait değildir; organization'a membership ile bağlanır ve tenant-erişimi bu ilişkiden türetilir.

2. KAVRAMSAL INVARIANT'LAR

ORGANIZATION ≠ TENANT
ORGANIZATION ≠ WORKSPACE
MEMBERSHIP ≠ USER ACCOUNT
MEMBERSHIP RELATIONSHIP ≠ AUTHORIZATION ROLE
COMMERCIAL ROLE ≠ ACCESS ROLE

İlişki-türü ayrımı (REDLINE-3):

MEMBERSHIP    = kişinin organization İÇİNDEKİ kalıcı/geçici iç-ilişkisi
PARTICIPATION = kişinin veya organization'ın SHARED-CONTEXT'e katılımı
REPRESENTATION = kişinin belirli organization ADINA işlem-yapma yetkisi

Bu üçü aynı kayıt/rol olarak modellenemez. Örnek: Ayşe→Acme-çalışanı = MEMBERSHIP · Acme→Etkinlik-Projesi-X-katılımcısı = PARTICIPATION · Ayşe→Acme-adına-RFP-gönderme-yetkilisi = REPRESENTATION + CAPABILITY.

Yetki-türü ayrımı (GÜÇLENDİRME-1):

CAPABILITY ≠ DECISION RIGHT ≠ APPROVAL AUTHORITY ≠ REPRESENTATION AUTHORITY ≠ EXECUTION ASSIGNMENT

Marketplace-kimliği ayrımı (GÜÇLENDİRME-5):

DECLARED BUSINESS ROLE ≠ VERIFIED MARKETPLACE CAPABILITY ≠ COMMERCIAL ENTITLEMENT ≠ OPERATIONAL ACCESS

Üyelik-ilişkisinin türü ile yetki-rolü aynı alanda birleştirilemez; organizasyonun ticari-rolü ile üyelerinin erişim-rolleri ayrı eksenlerdir.

3. KURUMSAL ÇALIŞMA MODELİ

ORGANIZATION
→ MEMBERS
→ WORKSPACES / PROJECT CONTEXTS
→ ROLES / CAPABILITIES
→ DECISION RIGHTS
→ APPROVAL AUTHORITY
→ SAFE ACTIONS
→ AUDIT / OUTCOME

Membership yalnız "çalışan kaydı" değildir. Membership, kişinin Organization ile temel iç-ilişkisini kurar; workspace ve proje bağlamlarındaki çalışma-erişimi bu membership'e bağlı role, capability, assignment, resource-scope ve policy üzerinden AYRICA türetilir (membership-ilişkisi ≠ workspace-assignment; aynı tabloya/lifecycle'a sıkıştırılmaz):

MEMBERSHIP                              → ORGANIZATION RELATIONSHIP
ASSIGNMENT / ROLE / CAPABILITY / SCOPE  → WORKSPACE OR PROJECT ACCESS

Yetkiler capability-diliyle tanımlanır (üst-doktrin §25 Access Decision Contract), kritik işlemler karar-hakkı ve onay-yetkisi katmanından geçer, her önemli sonuç denetim-izine bağlanır.

4. ÇOKLU İŞ ROLÜ

Bir organization aynı anda birden fazla marketplace-rolü taşıyabilir:

BUYER · AGENCY · VENUE OPERATOR · SUPPLIER · PARTNER

Tek bir değişmez organization_type alanına sıkıştırılamaz. (Emsal: Medya Canlı — hem tedarikçi hem alıcı hem partner davranışı gösterebilen gerçek-işletme.) İş-rolleri zamanla kazanılır/bırakılır.

Kritik invariant (GÜÇLENDİRME-5): Bir organization kendini VENUE OPERATOR beyan ettiğinde OTOMATİK olarak venue-yayınlama / marketplace-approved-görünme / RFP-cevaplama / venue-ownership-claim yetkisi KAZANMAZ. Rol-beyanı erişim üretmez; erişim-sonuçları doğrulama + entitlement zincirinden türetilir (DECLARED ≠ VERIFIED ≠ ENTITLEMENT ≠ OPERATIONAL).

5. CROSS-ORGANIZATION COLLABORATION

Şirketler birbirlerinin tenant'ına personel ekleyerek DEĞİL, kontrollü ortak bağlamlarda çalışır:

ORGANIZATION A + ORGANIZATION B
→ SHARED EVENT / RFP CONTEXT
→ SCOPED CAPABILITY (yalnız o bağlamda, yalnız tanımlı yetkiyle)

Karşı-tarafın kullanıcısı bizim organizasyonumuzun üyesi OLMAZ; ortak-bağlam üzerinden, kapsamı sınırlı yetkiyle katılır (PARTICIPATION, MEMBERSHIP değil).

Shared-Context invariant'ları (REDLINE-3):

SHARED CONTEXT ≠ TENANT
SHARED CONTEXT ≠ ORGANIZATION
PARTICIPATION ≠ MEMBERSHIP
SHARING ≠ OWNERSHIP TRANSFER
VISIBILITY ≠ MUTATION AUTHORITY

Her ortak-bağlam kavramsal olarak şunları taşımalıdır (fiziksel-şema değil, doktrinel-sınır): açık-amaç · sponsor/owner · katılan-organization'lar · kapsam · süre/kapanış-koşulu · görülebilen-veri-sınırı · yapılabilen-aksiyonlar · veri/provenance-sahipliği · erişim-sonlandırma · audit. Tenant-izolasyonu (üst-doktrin kod-tavanı) bu iş birliğiyle DELİNMEZ.

6. KARAR VE ONAY YETKİLERİ

EventInn bir karar-motoru olduğu için Organization OS yalnız kullanıcı-CRUD'u değildir. Kurumsal karar-hakları yönetilebilir olmalıdır — ve karar-otorite taksonomisi ayrı tutulmalıdır (GÜÇLENDİRME-1):

CAPABILITY             = bir aksiyonu teknik/operasyonel yapabilme      (ör. Event Manager → shortlist düzenler)
DECISION RIGHT         = belirli kararın sahibi olma                    (ör. Project Owner → venue-seçimine karar verir)
APPROVAL AUTHORITY     = başkasının aksiyon/kararını onaylama            (ör. Finance Approver → bütçe onaylar)
REPRESENTATION AUTHORITY = organization'ı dış-ilişkide bağlayabilme      (ör. Authorized Rep → şirket-adına RFP gönderir)
EXECUTION ASSIGNMENT   = alınmış kararı uygulama sorumluluğu

Bu ayrım EventInn'i sıradan RBAC-ekip-sisteminden çıkarıp gerçek kurumsal-karar-altyapısına dönüştürür. Örnek capability-adları (org.decision.rfp_start, org.approval.budget) non-normative; fiziksel adlar Access-Contract-aşamasında doğar.

Koşullu fail-closed (GÜÇLENDİRME-1 — daraltıldı): İlgili Rule tarafından approval-required ilan edilen aksiyonlarda — örneğin privileged, geri-döndürülmesi-zor veya yüksek-riskli işlemlerde — gerekli-onay sağlanmadan işlem ilerlemez:

APPROVAL REQUIREMENT              = RULE-DRIVEN (bu belirler)
PRIVILEGED / IRREVERSIBLE / HIGH-RISK = approval-gerektirebilecek ÖRNEK-sınıflar (hepsi-birden-şart-değil)

AKSİYON approval-required(rule) → gerekli-onay-sağlandıysa → ilerler
AKSİYON approval-gerektirmez    → NORMAL AUTHORIZATION CONTRACT geçerlidir

Yani "her kurumsal işlem approval-engine olmadan kapalıdır" DEĞİL (canlı-emsal: PrivilegedAccessLog — super_admin-atama, rule-driven-privileged).

7. TRUST VE TEMSİL — ÇOK EKSENLİ TRUST PROFİLİ (REDLINE-2)

Güven tek bir doğrusal-merdiven DEĞİL, çok-eksenli profildir. Bir şirket aynı anda bir eksende doğrulanmış, diğerinde doğrulanmamış olabilir (ör. domain-verified ama belge-doğrulanmamış; marketplace-approved ama belirli-kullanıcı-yetkili-temsilci-değil).

Trust eksenleri (ayrı doğrulama-boyutları):

ORGANIZATION IDENTITY STATUS
DOMAIN CONTROL STATUS
LEGAL / DOCUMENT VERIFICATION
MARKETPLACE APPROVAL
REPRESENTATION AUTHORITY
ASSET / VENUE CLAIM STATUS

İnvariant'lar:

IDENTITY VERIFICATION ≠ MARKETPLACE APPROVAL ≠ REPRESENTATION AUTHORITY ≠ RESOURCE OWNERSHIP CLAIM
ONE VERIFIED DIMENSION ≠ ALL DIMENSIONS TRUSTED

Claim tek başına membership veya capability üretmez. Tek bir verification_level alanıyla bütün trust-modelini temsil etmek YASAK (yanlış-temsil-riski); her eksen kendi kanıtını taşır.

Temsil-yetkisi kapsamlıdır (GÜÇLENDİRME): Representation Authority var/yok-ikilisi değildir; kapsamlı, süre-sınırlı ve geri-alınabilirdir:

REPRESENTATION AUTHORITY → SUBJECT / ACTION SCOPE → CONTEXT → VALIDITY PERIOD → EVIDENCE → REVOCATION
INVARIANT: REPRESENTATION AUTHORITY IS SCOPED, TIME-BOUND AND REVOCABLE

(Örn: bir kişi şirkete üye olabilir + belirli-etkinlikte temsil edebilir + genel-sözleşme-imzalama-yetkisine sahip-olmayabilir — üçü ayrı.)

8. ORGANIZATION RELATIONSHIPS / GRAPH SEAM (GÜÇLENDİRME-2)

Organization zaman içinde başka organization'larla ilişkiler taşıyabilir:

HOLDING ├─ LEGAL ENTITY ├─ BRAND ├─ BRANCH ├─ BUSINESS UNIT └─ VENUE OPERATING ENTITY
(parent · subsidiary · branch · brand · operating-company · partner)

Kritik invariant:

ORGANIZATION RELATIONSHIP ≠ AUTOMATIC ACCESS INHERITANCE

Bir holdingin üst-şirket olması, bağlı-şirketin bütün verisini otomatik-görmesi anlamına GELMEZ. Organization-ilişkisi kendiliğinden üyelik, veri-erişimi veya yetki-mirası üretmez. (İlk train'de universal-organization-graph KURULMAZ — bu yalnız gelecek-seam'i tanımlar; erken-güvenlik-açığı önlemi.)

Ontoloji-sınırı: Bu kavramların (legal-entity/brand/branch/business-unit/venue-operating-entity) doktrinde anılması, her düğümün aynı Organization entity-türü olarak fiziksel-modellenmesini zorunlu kılmaz; marka/business-unit ileride ayrı organizational-unit-türü olabilir. Exact organizational-ontology ilgili Scenario/UC/ADR zincirinde belirlenir ("her-şeyi-organizations-tablosuna-at" riski önlenir).

9. KURUMSAL HAFIZA — TRUTH-CLASS AYRIMI (GÜÇLENDİRME-3)

Organization'ın geçmiş kararları gelecekte Discovery ve karar-motorunu besleyebilir; ancak farklı truth-class'lar karıştırılamaz:

HISTORICAL OBSERVATION  (şirket geçmişte otel seçti)
  ≠ INFERRED PREFERENCE  (sistem "otel tercih ediyor" tahmini)
  ≠ DECLARED PREFERENCE  (kullanıcı "otel tercih ediyoruz" dedi)
  ≠ APPROVED ORGANIZATION POLICY  (yetkili yönetici şirket-politikası yaptı)
  ≠ CURRENT EVENT REQUIREMENT  (mevcut etkinlik açık-hava zorunlu)

Ana invariant'lar korunur: PAST BEHAVIOR ≠ CURRENT REQUIREMENT · AI RECOMMENDATION ≠ ORGANIZATION POLICY. Kurumsal hafıza öneri-zenginleştiricidir; AI onu gerçek-gereksinim/politika gibi dayatamaz, organization adına sessizce yetki/politika üretemez (üst-doktrin: RECOMMENDATION ≠ MUTATION). Her hafıza-öğesi: kaynak · zaman-aralığı · freshness · onay-durumu · geçerlilik-kapsamı · kaldırma/unutma-politikası taşımalıdır.

10. YAŞAM DÖNGÜSÜ VE SÜREKLİLİK (GÜÇLENDİRME-4)

Organization yalnız "açılır/kapanır" değildir; uzun-ömürlü seam'ler tanınır (şimdi build EDİLMEZ):

OWNERSHIP TRANSFER · LEGAL NAME CHANGE · MERGER · ACQUISITION · SPLIT
REPRESENTATION CHANGE · TENANT MIGRATION · CLOSURE · RESTORATION

Hüküm: Organization-kimliği, sahiplik veya hukuki/operasyonel-yapı değişikliklerinde SESSİZCE yeni-organization'a dönüştürülemez; kaynaklar, üyelikler, karar-geçmişi ve temsil-yetkileri izlenebilir geçiş-kurallarıyla yönetilir.

Askıya-alma/kapanış: kullanıcı-hesaplarını KAPATMAZ · kişisel-workspace'leri ETKİLEMEZ · diğer-organization-üyeliklerini BOZMAZ · audit ve geçmiş-kararları SİLMEZ · kurumsal-kaynakları sahipsiz BIRAKMAZ (devir/emanet kendi-zincirinde). (Not: kalıcı üyelik-sonlandırma/offboarding bilinçli olarak bu zincire bırakıldı — K327.)

11. YASAKLI SAPMALAR

• Organization = Tenant indirgemesi (kimlik ≠ konteyner)
• Membership = User-Account indirgemesi
• Membership / Participation / Representation'ı tek-kayıt/rol yapma
• Capability / Decision-Right / Approval / Representation'ı tek-yetkide birleştirme
• Tek organization-type enum'una bütün işletme-rollerini sıkıştırma
• Declared-business-role'ü otomatik-marketplace-capability/erişim sayma
• Trust'ı tek verification_level ile temsil etme (çok-eksen zorunlu)
• Organization-ilişkisini otomatik-erişim-mirası sayma
• Tenant-admin'i "küçültülmüş super-admin" yapma (contextual-management-yüzeyi menü-gizleyerek üretilmez — üst-doktrin)
• Membership olmadan tenant-erişimi
• Cross-org iş birliği için karşı-tarafı tenant-çalışanı yapma
• Kurumsal-hafıza truth-class'larını karıştırma (inferred'i approved-policy sayma)
• İlk train'de generic-HR-sistemi / universal-organization-graph / generic-custom-policy-engine kurma
• AI'ın organization adına sessizce yetki veya politika üretmesi

12. İLK TRAIN KAPSAM SINIRI (vizyonu build'le karıştırmama)

Bu doktrinin kabulü hiçbir capability'yi build'e yetkilendirmez. İlk Organization-train'in kapsamı DARDIR:

Organization creation · Tenant/workspace provisioning · Owner membership
Invitation lifecycle · Basic scoped roles · Team Management v1
Context switching · Tenant isolation · Audit

Decision-rights/approval-authority, cross-org-collaboration, çok-eksenli-trust, organization-graph, kurumsal-hafıza, yaşam-döngüsü-seam'leri = vizyon + seam (bu doktrinde yön-sınırı olarak yaşar; her biri kendi Scenario → UC → Rule → ADR → Feature Train zinciriyle, gerçek ürün-ihtiyacıyla doğar).

---

CANON KABUL SINIRI

Bu alan-doktrininin kabulü, burada anılan hiçbir capability'nin implementasyonuna, deploy'una veya etkinleştirilmesine kendiliğinden yetki vermez. Her somut capability Scenario → UC → Rule/Policy → gerekirse ADR → Feature Train zincirinde kendi kapsam ve güvenlik sınırlarıyla ilerler. Kabul ≠ effective ≠ merge ≠ deploy.

---

CAN-STR-ORGOS-001 · strategy/normative · R4 · CAN-STR-DOCTRINE-001'e bağlı alan-doktrini (rakip/revizyon değil; CAN-DEC-ADR-002=compatibility-constraint) · Doğrulanmış uygulama-emsalleri (Gate-A/MAIN-VERIFIED): User-360/PlatformRoleGuard/MembershipGuard/PrivilegedAccessLog (UserMgmt-treni) · İçerik: Human-CEO 10-bölüm-direktifi + AI-CEO-review (3-redline+5-güçlendirme + 6-kabul-öncesi-düzeltme) (16 Tem 2026) + Müdür-Canon-formatı & section-fix · accepted (Human-CEO 16 Tem 2026; chat-accept).