EventInn Kontrollü Kavram ve Otorite Sistemi (EKOS)

Bu kayıt bir mühendislik standardıdır. Doktrini değiştirmez, mimari kararların yerine geçmez, ürün davranışı icat etmez ve üst kayıtlarda bulunmayan bir yetki modeli kuramaz. Makine-okunur sözleşmeler (KOS-*.json) bu standarda tabidir; bağımsız normatif otorite üretmezler.

§1 · Amaç — çözdüğü problem sınıfı

EKOS tek bir soruna değil, tekrar eden bir arıza sınıfına cevap verir:

aynı gerçeğin birden fazla yerde elle tanımlanması,
yanlış rejimde yaşayan sözlükler (veri olması gereken şeyin koda, kod olması gereken şeyin veriye kaçması),
aktif yazma yüzeyi + eksik okuyucu — kullanıcıya vaat edilen ama hiçbir yerde karşılığı olmayan ayar,
uykuda şema ile aktif ürün vaadinin birbirine karışması,
token ↔ label karışması (kalıcı kimlik ile çevrilebilir adın aynı şey sanılması),
bir durum listesinin durum makinesi sanılması,
kuyruk dispatch'i ile worker kapsamasının sessizce ayrışması.

Bu arızaların ortak özelliği sessiz olmalarıdır: sistem hata vermez, sadece yanlış çalışır ya da hiç çalışmaz. EKOS'un amacı bu sessizliği makine tarafından duyulur hâle getirmektir.

§2 · Kapsam

Kapsam içi — kontrollü kavram örnekleri: rol · durum · izin · olay tipi · audit eylemi · erişim tipi · ret kodu · hata kodu · kuyruk · worker grubu · sağlayıcı · kanal · aktör tipi · scope · kademe · yerel ayar · para birimi · birim · özellik modu · aggregate tipi · veri sınıflandırması.

Kapsam dışı: serbest metin · her veritabanı kolonu · her yapılandırma değeri · fonksiyon içi geçici sabit · matematik sabitleri · tasarım token'ları (design tokens).

Bir kavram EKOS kapsamına girer mi? — altı ölçüt. Bir tanesi bile "evet" ise kavram sınıflandırılmalıdır:

Kapalı bir üye kümesi var mı?
Davranışı dallandırıyor mu?
Veritabanında, API'de, audit'te veya outbox'ta kalıcılaşıyor mu?
Başka katmanlarda tekrar ediyor mu?
Yanlış değer sessiz ya da güvenlik-kritik bir arıza üretir mi?
Yeni bir üye eklemek başka bileşenlerde değişiklik gerektiriyor mu?

§3 · Doktrin / Mimari karar / EKOS / Brief / Test ayrımı

Katman	Ne söyler
Doktrin	Bozulamaz kavramsal ayrımlar
Mimari karar (ADR)	Seçilen mimari seçenek
EKOS	Seçilen kavramların günlük kodda sınıflandırma, otorite ve makine-koruma standardı
Brief	Hangi dosyaların değişeceği
Test / CI	Sözleşmenin kanıtı

EKOS doktrini değiştiremez, bir mimari kararı geçersiz kılamaz, ürün davranışı icat edemez ve üst bir kayıtta bulunmayan bir authority modeli kuramaz.

§4 · Altı rejim (normatif)

Her kontrollü kavram tam olarak bir rejime aittir. Rejim, kavramın nasıl genişletileceğini, kimin otorite olduğunu ve hangi korumaların zorunlu olduğunu belirler.

PROTOCOL
STATE_MACHINE
AUTHORITY
BUSINESS_CATALOG
EXTERNAL_REFERENCE
PROJECTION

Yukarıdaki blok makine-okunur çapadır: ekos/registries/ekos-regime-register.json ve ekos/schemas/ekos-contract.schema.json içindeki rejim kümeleriyle birebir eşit olmak zorundadır. Üç kopya birbirinden ayrışamaz; scripts/canon_ekos_contract_lint.py bu eşitliği ölçer.

PROTOCOL — kodun veya bir entegrasyonun anlam yüklediği stabil token: domain olay adı, audit eylemi, ret/hata kodu, kuyruk adı, aggregate tipi, API ayırıcısı. Yeni üye eklemek pratikte deploy demektir.

STATE_MACHINE — üye kümesi tek başına yetmez: geçişler, terminal durumlar ve guard'lar birlikte tanımlanır. Üyelik, davet, ödeme, rezervasyon ve outbox yaşam döngüleri buradadır. Bir durum LİSTESİ tek başına durum makinesi DEĞİLDİR.

AUTHORITY — erişim veya karar yetkisi taşıyan kavramlar: üyelik rolü, platform yetkisi, capability, aktör tipi, grant tipi, scope. Tenant paneli güvenlik tavanını gevşetemez.

BUSINESS_CATALOG — yeni üyenin özel kod dalı gerektirmediği iş sınıflandırmaları: etkinlik tipi, mekân kategorisi, ajans uzmanlığı, tenant'a özel etiket. Üye bir veri satırı olarak doğar.

EXTERNAL_REFERENCE — üye kümesini dış bir otorite belirler: ülke kodu, para birimi, saat dilimi, mevzuat listesi. Kaynak senkronu ile gelir; uygulama kodunda rastgele dallanma yoktur.

PROJECTION — başka bir otoritenin yüzey temsili: yönetim paneli seçenekleri, tip birleşimleri, etiket, çeviri, rozet/renk, rapor filtresi. Bağımsız otorite olamaz.

§5 · Aktivasyon durumları ve uyum durumu

Rejim kavramın ne olduğunu, aktivasyon durumu ise bugün ne kadarının gerçekten çalıştığını söyler. Bu ikisi bilinçli olarak ayrıdır: şemanın var olması özelliğin aktif olduğu anlamına gelmez.

DORMANT
AUTHORING_ONLY
SHADOW
ACTIVE
DEPRECATED

DORMANT — dikiş yeri (seam) vardır; kullanıcıya verilmiş bir vaat ve yazma yüzeyi yoktur.
AUTHORING_ONLY — veri hazırlanır, zorlama (enforcement) yoktur; yüzey bunu açıkça söyler.
SHADOW — karar hesaplanır, sonucu değiştirmez; yalnız kanıt üretir.
ACTIVE — otoriterdir; karar bağlayıcıdır.
DEPRECATED — yeni yazıcı kapalıdır; uyumluluk için okuma sürebilir.

CONFORMANT
NONCONFORMANT
UNKNOWN

Uyum durumu gerçeği söyler: bir sözleşme niyetini identity_authority ile, bugünkü gerçeğini conformance_state ile beyan eder. NONCONFORMANT, tespit edilmiş ve tescil edilmiş bir boşluktur — gizlenmiş bir hata değildir.

§6 · KOS sözleşmesinin zorunlu alanları

Her makine sözleşmesi (ekos/contracts/KOS-*.json) şu 29 alanı taşır:

schema_version · contract_id · name · description · regime · subtype · activation_state · conformance_state · risk_class · owner · identity_authority · members_or_member_source · writers · authoritative_readers · effects · db_mirrors · code_mirrors · projections · allowed_surfaces · forbidden_surfaces · extension_policy · rename_policy · compatibility_policy · drift_guards · runtime_verification · evidence_refs · related_canon · known_debt · unknowns

Rejime bağlı ek zorunluluklar: STATE_MACHINE → state_machine · PROJECTION → projection_source.

§7 · Otorite türleri, zincir, token/label ve projeksiyon

Kimlik otoritesi türleri: code_registry · db_constraint · catalog_table · external_registry · derived. Bir kavram için tek otorite vardır; ayna (mirror) otorite değildir.

Zorunlu zincir:

WRITER  →  AUTHORITATIVE READER  →  ENFORCED EFFECT  →  OBSERVABLE RESULT

Bağlayıcı sonuç: WRITABLE CONFIGURATION → AUTHORITATIVE READER OR WRITE SURFACE CLOSED. Yazılabilir bir ayar varsa ya onu okuyan otoriter bir okuyucu vardır, ya da o yazma yüzeyi kapatılır. Üçüncü bir seçenek yoktur.

Token ve label: TOKEN = stabil kimlik · LABEL = çevrilebilir ad. Varsayılan politika: label değişikliği serbest, token yeniden adlandırma yasak. Yeniden adlandırma zorunlu hâle gelirse plan şunları içermek zorundadır: alias · çift okuma (dual-read) · geri doldurma (backfill) · append-only etkisinin değerlendirilmesi · dış tüketici analizi · emeklilik (retirement) · geri alma (rollback).

Projeksiyon: AUTHORITY WRITTEN → PROJECTIONS DERIVED. Projeksiyon otoriteden türetilir; türetme mümkün değilse birebir drift testi zorunludur.

§8 · Bağlayıcı kurallar (R01–R12)

#	Kural
R01	Yeni kontrollü kavram → rejim zorunlu. Sınıflandırılmamış yeni kavram birleştirilemez.
R02	Bir kavram → tek kimlik otoritesi.
R03	Aktif yazıcı + otoriter okuyucu + zorlanan etki olmadan bir kavram açılamaz.
R04	SCHEMA EXISTS ≠ FEATURE ACTIVE.
R05	Uykudaki motorda aktif yazma yüzeyi olamaz. Menüyü gizlemek yetmez; route ve sunucu tarafı mutasyon da kapanır.
R06	Projeksiyon bağımsız otorite olamaz.
R07	Durum makinesi; durumlar + geçişler + terminalite + guard'lar + yazıcılar + audit/outbox + eşzamanlılık tanımlanmadan tamam sayılmaz.
R08	Label değişikliği token yeniden adlandırmasına dönüştürülemez.
R09	Veritabanı ve kod aynı sözlüğü temsil ediyorsa makine karşılaştırması zorunludur.
R10	Eski borç = envanter · yeni borç = RED. Registry veya sözleşme dışında yeni literal borcu üretilemez.
R11	CODE-USED TOKEN ⊆ REGISTERED TOKEN SET — ve aktif üyenin ya bir okuyucusu ya da açık bir uyku beyanı olur.
R12	DECLARED/DISPATCHED SET ⊆ DURABLE CONSUMER SET ⊆ RUNTIME OBSERVED SET (ilk referans: kuyruklar).

§9 · On iki zorunlu senaryo (S1–S12)

#	Senaryo ve öz-kuralı
S1	Yeni yaşam döngüsü durumu yalnız CHECK kısıtına eklenirse RED. Registry + geçiş matrisi + terminalite + audit + eşzamanlılık + drift testi birlikte gelirse PASS.
S2	Tenant'a özel rol yazılabiliyor ama okuyucusu yoksa RED → ya motor bağlanır ya yüzey kapatılır.
S3	Yeni kuyruk dinlenmiyorsa CI RED; canlı dinleyici eksikse deploy doğrulaması RED.
S4	Katalogsuz izin RED. Okuyucusu olmayan aktif izin ya uyku olarak beyan edilir ya kapatılır.
S5	Label değişir; token, audit ve yetkilendirme değişmez.
S6	Append-only veya dış etkisi olan token'ın yeniden adlandırılması varsayılan RED — uyumluluk planı şarttır.
S7	İş kataloğu üyesi kod dalı istemiyorsa satır olarak eklenir; istiyorsa kavram yeniden sınıflandırılır.
S8	Dış referans seed/senkron ile gelir.
S9	Uykudaki yönetim route'u: navigasyonda gizli ve doğrudan route reddedilir ve oluşturma/düzenleme reddedilir.
S10	Yazıcı var + okuyucu yok + etki yok = FALSE PROMISE.
S11	Registry'de yeni üye + arayüz seçeneklerinde eksik → türetilen yüzeyse yeniden üretilir, elle tutuluyorsa drift testi RED verir.
S12	Aynı token farklı sözlüklerde geçiyorsa anlamsal namespace sözleşmesi yazılır (örnek: platform rolü `admin` ile üyelik rolü `admin` aynı şey değildir). Mevcut veritabanı token'ları bunun için yeniden adlandırılmaz.

§10 · KOS JSON şema şartları

ekos/schemas/ekos-contract.schema.json şunları zorunlu kılar:

additionalProperties: false — tanımsız alan RED;
sözleşme kimliği deseni KOS-...-NNN; KOS-* kimlikleri CAN-* uzayında değildir;
rejim / aktivasyon / uyum / risk sınıfı enum'ları;
boş olmayan kimlik otoritesi;
yazıcı, okuyucu ve projeksiyon listelerinde tekrar yasağı;
ACTIVE sözleşmede en az bir yazıcı ve bir otoriter okuyucu ve bir etki;
PROJECTION rejiminde otorite referansı;
yeniden adlandırma izinliyse uyumluluk planı zorunlu;
STATE_MACHINE rejiminde geçişler ve terminal durumlar zorunlu;
DORMANT durumda aktif yazma yüzeyi beyanı yasak;
ilişkili Canon kimliklerinde kimlik deseni doğrulaması.

KOS sözleşmesi ikinci bir Canon değildir: CAN-* kimliği taşımaz, Canon yaşam döngüsü statüsü taşımaz, bağımsız normatif otorite üretmez ve bir Canon kaydını geçersiz kılamaz.

§11 · Rejim registry'si

ekos/registries/ekos-regime-register.json altı rejimin stabil kimliklerini, Türkçe/İngilizce açıklamalarını, varsayılan genişletme ve yeniden adlandırma politikalarını, rejime özel zorunlu sözleşme alanlarını ve her rejim için bir örnek ile bir karşı-örnek taşır.

Üç-kopya eşitliği zorunludur: bu kaydın §4'ündeki rejim kümesi == registry rejim kümesi == şema regime enum'u. Üç kopya birbirinden ayrışamaz; lint bunu ölçer.

§12 · Dört pilot sözleşme

Sözleşme	Rejim · Aktivasyon · Uyum	Özet
`KOS-AUTH-MEMBERSHIP-ROLE-001`	AUTHORITY · ACTIVE · CONFORMANT	Üyelik rol vokabüleri. Otorite koddadır; veritabanı kısıtı aynadır ve eşitlik makine ile ölçülür. Yasaklar: hiyerarşi kolonuyla yetkilendirme, sayısal sıranın yetki modeline dönüşmesi, tenant panelinin güvenlik tavanını gevşetmesi, sahiplik devri token'ının bu sözleşmeye eklenmesi.
`KOS-STATE-MEMBERSHIP-LIFECYCLE-001`	STATE_MACHINE · ACTIVE · CONFORMANT	Üyelik yaşam döngüsü: durumlar, geçişler, terminal durumlar, süreklilik frenleri ve olay token'ları. Kapsam `CAN-DEC-ADR-007` P2.1 dilimidir; sahiplik devri bu sözleşmeye eklenmez.
`KOS-OPS-QUEUE-COVERAGE-001`	PROTOCOL · ACTIVE · CONFORMANT	Kuyruk adı protokolü ve kapsama invariant'ı: dispatch edilen küme ⊆ dayanıklı tüketici kümesi ⊆ runtime'da gözlenen küme. İki yaşanmış olay envanterde tutulur; olaylar yeniden açılmaz.
`KOS-AUTH-CUSTOM-ROLE-SURFACE-001`	AUTHORITY · DORMANT · NONCONFORMANT	Tenant'a özel rol yüzeyi. Bulgu: yazılabilir yönetim yüzeyi vardır, otoriter okuyucu yoktur — FALSE PROMISE. Düzeltme ayrı bir uygulama brief'ine aittir; EKOS bu turda uygulama koduna dokunmaz.

§13 · Bilinen boşluklar

KNOWN GAP ≠ CURRENTLY ENFORCED CONTROL. Aşağıdakiler bu kayıtta beyan edilir; bu turda düzeltilmez. Beyan edilmiş bir boşluk, var olmayan bir korumanın var sanılmasını engeller.

#	Boşluk
F-1	Canon kayıtlarında `related` ve `governed_by` alanlarının varlık doğrulaması yoktur. Yalnız `traceability.upstream` çözümlenir; diğer ikisinde yazım hatası sessizce geçer.
F-2	Üretilen `downstream-register` dosyası bayattır ve drift koruması yoktur — sürüklenme denetimi yalnız üç üretilmiş dosyayı kapsar.
F-3	Yönetim indeksi üreticisinin başlık yorumu, kimlik registry'sini okuduğunu söyler; kod okumaz. `COMMENT ≠ AUTHORITY` ilkesinin canlı örneğidir.
G1-9	Kimlik registry'si ile diskteki kayıtlar arasında çift yönlü kontrol yoktur; bugünkü birebir tutarlılık tamamen elle korunmaktadır.
OWNER	`owner` alanı bir enum veya registry ile sınırlı değildir (bilinen yetki-token'ı boşluğu). Bu standart o boşluğu kapatmaz; kapatmak ayrı bir yönetişim kararıdır.

§14 · Lint — asgari kontroller

scripts/canon_ekos_contract_lint.py iki katmanda çalışır. Hiçbir toplam sayı bu metne veya koda elle yazılmaz — koşum raporundaki her sayaç canlı nesnelerden türetilir (kod-kontrolü sayısı çalıştırılan plandan, şema-koşullu-kural sayısı şemanın kendisinden). Bir guard silinirse raporlanan sayı da düşer.

Keşif sözleşmesi (her şeyden önce gelir). Sözleşme keşfi ekos/contracts/** altında özyinelemelidir ve contract-root altındaki her .json ya geçerli bir KOS sözleşmesidir ya da açık bir RED üretir. Ayrıştırılamayan veya tanınmayan dosya sessizce atlanmaz; ayrıca keşfedilen == doğrulanan + reddedilen eşitliği ölçülür. Gerekçe: lint, taramadığı bir dosya hakkında "ağaç temiz" diyemez.

Şema katmanı (ekos-contract.schema.json tarafından tek seferde ölçülür — kodda yeniden yazılmaz): tanımsız alan · enum dışı değer · liste içinde tekrar · boş token · related_canon kimlik deseni · ACTIVE sözleşmede yazıcı + otoriter okuyucu + etki · DORMANT sözleşmede aktif yazma yüzeyi beyanı yasağı · STATE_MACHINE rejiminde durumlar ve geçişler · PROJECTION rejiminde otorite referansı · yeniden adlandırma izinliyse uyumluluk planı.

Kod katmanı (şemanın ifade edemediği dosyalar-arası ve anlamsal kurallar):

Keşif–doğrulama sayım bütünlüğü.
Dosya adı == contract_id.
Sözleşme kimlikleri dosyalar arasında benzersizdir.
Registry rejim kümesi == şema regime enum'u.
Bu kaydın gövdesinde yayınlanan kümeler == registry kümeleri (rejimler · aktivasyon durumları · uyum durumları). Yayınlanan küme bloğu yoksa sonuç "ölçülemez"dir ve sessizce yeşile dönemez.
Yardımcı sözlük eşitliği: aktivasyon durumları · uyum durumları · kimlik otoritesi türleri · zorunlu sözleşme alanları — registry ↔ şema küme karşılaştırması.
Kontrollü genişleme: sözleşme kimlik kümesi beklenen kümedir (yeni sözleşme, kümenin bilinçli güncellenmesini gerektirir — R01).
Öz-çelişki: uyum ↔ borç · uyku ↔ etki · emeklilik ↔ yazıcı.
FALSE PROMISE fail-closed: DORMANT bir sözleşmede kullanılabilir yazıcı varsa, conformance_state NONCONFORMANT olmalı veya kanıtlı bir known_debt beyanı bulunmalıdır. Yazıcısı olan uykudaki motor, dürüstlük beyanı olmadan geçemez.

Hata mesajı sözleşmesi: her RED, ihlal edilen invariant'i adıyla söyler. Çıplak bir exception, alakasız bir şema hatası veya genel "geçersiz" ifadesi yetersizdir.

Negatif testler geçici fixture ve geçici dizinlerle koşar; gerçek ağaç asla bozulmaz. Mutasyon probu zorunludur: bir guard kaldırıldığında ilgili negatif test yanlış yeşile dönmemelidir — RED görülür, guard geri konur, GREEN doğrulanır. Test raporu pozitif, negatif, prob, şema, sözleşme ve rejim sayılarını komut çıktısıyla verir.

0 bulundu ile hiç aramadı aynı şey değildir: her desen, bilinen bir örneği yakaladığını göstermek zorundadır (pozitif kontrol).

§15 · Yürürlük ve sınırlar

Bu kayıt governance_status: accepted durumundadır — fakat yürürlükte değildir (effective_at: null). Kabul ve yürürlük ayrı kapılardır; bu kaydın varlığı hiçbir uygulama davranışını değiştirmez.

EKOS yeni bir birleştirme engeli getirmez — lint yalnız ekos/ ağacını ve bu kaydı denetler.
DRAFT STANDARD ≠ NEW MERGE BLOCKER · DOCUMENTED DEBT ≠ DEBT WAIVED.
PILOT CONTRACT ≠ PILOT CODE CHANGE: dört pilot mevcut durumu tescil eder, uygulama kodunu değiştirmez.
EKOS AUTHORING ≠ APP IMPLEMENTATION.

governance_status: **accepted** · effective_at: null (yürürlükte DEĞİL) · CAN-ENG-EKOS-001 · mühendislik standardı · KOS sözleşmeleri bu kayda tabidir.

§1 · Amaç — çözdüğü problem sınıfı​

§2 · Kapsam​

§3 · Doktrin / Mimari karar / EKOS / Brief / Test ayrımı​

§4 · Altı rejim (normatif)​

§5 · Aktivasyon durumları ve uyum durumu​

§6 · KOS sözleşmesinin zorunlu alanları​

§7 · Otorite türleri, zincir, token/label ve projeksiyon​

§8 · Bağlayıcı kurallar (R01–R12)​

§9 · On iki zorunlu senaryo (S1–S12)​

§10 · KOS JSON şema şartları​

§11 · Rejim registry'si​

§12 · Dört pilot sözleşme​

§13 · Bilinen boşluklar​

§14 · Lint — asgari kontroller​

§15 · Yürürlük ve sınırlar​