# Review — Spec 1: Platform Omurgası (EGT-21) — 25.07.2026

> **Review type:** spec-review
> **Previous review:** N/A (ilk review)
> **Upstream document(s) read:** `cati-dokumani.md`, `docs/arch/mimari-kararlar.md` (AD-01…AD-28), `docs/mevzuat-kurallari.md`
> **Other cross-referenced documents:** `mevzuat/1-egitim/IMDG_Kod_Kapsaminda_Egitim_ve_Yetkilendirme_Yonetmeligi.pdf` (Y-2016 md.13/f doğrulaması), `mevzuat/5-gozetim/Deniz_Ticareti_Gozetim_Hizmetleri_Uygulama_Yonergesi.pdf` (DG-2020 md.14/4 ve md.14/8 doğrulaması)
> **Stage locks in effect:** None (ilk aşama; çatı dokümanı + AD'ler upstream işlevi görür ve tartışılmaz veri kabul edilmiştir)

---

## Upstream Coverage Matrix

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| AD-02 — tenant = müşteri firma; bağımsız katılımcı da tenant, fatura kesilebilir (çatı 2. tur #14) | ⚠ | §3 tenant tanımı var; bağımsız katılımcının **kullanıcı türü eşlemesi** tanımsız (F-7) |
| AD-03 — iki bağımsız izolasyon katmanı | ✓ | §4.1, §4.3, §14/1 |
| AD-04 — tenant bağlamı yalnız transaction içinde | ✓ | §4.1, §13 ilk satır, §14/2 |
| AD-05 — alan bazlı şifreleme + tenant bazlı anahtar day-one | ⚠ | §8.1 yapılandırılmış alanları kapsıyor; hassas **dosya/evrak içerikleri** (kimlik fotokopisi, SGK belgesi) omurga güvencesinin dışında (F-8) |
| AD-06 — append-only audit + KamuSM RFC 3161 batch damga + WORM | ✓ | §7.1; damga async istisnası §13'te doğru kurulmuş |
| AD-07 — dört yöntem, MFA zorunluluğu, magic link kanıt sınırı | ⚠ | §5.1–5.3 büyük ölçüde uyumlu; §5.3'te ek kimlik teyidi maddesi kendi içinde çelişkili (F-11) |
| AD-08 — parametrik kurallar (yöntem matrisi, eşikler, kademeler, takvim) | ✓ | §5.1, A-1, A-6, §10.5, §12 (takvim) |
| AD-13 — video kaydı için KVKK aydınlatma + açık rıza | ✓ | K-1 |
| AD-16 — audit maskeleme + dump anonimleştirme | ✓ | §7.1 (maskeleme), §8.3, K-3, T-7 |
| AD-17 — transactional/promosyonel ayrı akış; İYS hard gate; bounce/şikayet suppression; sürümlü admin şablon | ⚠ | §10.1–10.3 kapsıyor; ancak alınan onay/ret'in **İYS'ye bildirilmesi** yükümlülüğü spec'te gereksinim olarak yok (F-9) |
| AD-18 — SMS yalnız auth/işlem, promosyonel yok | ✓ | §10.1 |
| AD-19 — referans kodu kuralları (rastgele, değişmez, kod ≠ yetki, merkezî prefix, global arama koda göre bulur) | ⚠ | R-1…R-6 üretim ve kullanım kurallarını kapsıyor; **kodla kayıt bulma/arama davranışı** tanımsız (F-10) |
| AD-20 — gelen e-posta doğrulanmamış içerik; onay yalnız panelden | ✓ | §10.6 |
| AD-21 — erişim logu / aktivite logu sınıf ayrımı | ⚠ | §7.2–7.3 sınıfları doğru ayırıyor; erişim logunun **saklama süresi** (F-5) ve okuma loglarının **yazım garantisi seviyesi** (F-4) tanımsız |
| AD-21 — audit işlemle aynı bütünlükte, kuyruk yok | ✓ | §7.1, §12 istisna satırı, §14/6 |
| AD-21 — analitik yalnız agregat, kişi kırılımı yok, k-anonimlik 2, "son aktif" | ✓ | §8.5, §14/9 |
| AD-21/AD-22 — çevrimiçi göstergesi yalnız direktör + operasyon direktörü | ✓ | RT-6 |
| AD-22 — realtime dar kapsam: private kanal, presence yok, TTL'li "çalışıyor" uyarısı, hassas içerik taşınmaz | ✓ | RT-1…RT-5 |
| AD-23 — kullanıcı silinmez, pasifleştirilir; eylem sahipliği değişmez | ✓ | A-5, §13 |
| Çatı §5 — üç eğitim türü: kurumsal / açık (bölgesel) / **çoklu kurumsal (davet bazlı)** | ❌ | T-5 "eğitimin varlığı, tarihi ve doluluk sayısı **herkese** görünür" — davet bazlı türle ve açık eğitimin bölge sınırıyla bağdaşmıyor (F-1) |
| Çatı §15 — kontenjan sayacı kapsam-bağımsız okunur, tahsis atomik | ✓ | T-6, §13 sayaç satırı |
| Çatı §2/§14 + YÖN-2019 md.8 — yenileme takibi kişi bazlı sürer ("af yok" kuralı kişinin geçmişine dayanır) | ❌ | §13 "birden fazla tenant'a izin verilmez" + "farklı tenant'ta aynı e-posta ayrı kullanıcı" kuralları, katılımcının **firma değiştirmesi** senaryosunda kimlik/geçmiş sürekliliğini tanımsız bırakıyor (F-6) |
| AD-16 gerekçesi — silinemez kayıt ↔ KVKK silme hakkı gerilimi | ❌ | K-2'nin önermesi ("silinemez kayıtlarda kişisel veri maskelenmiş") audit için doğru, **imzalı yoklama** için yanlış (F-2); mevzuat saklama süresiyle etkileşim tanımsız (F-3) |
| Mevzuat — Y-2016 md.13/f "en az üç yıl", DG-2020 md.14/4 "5 yıl", md.14/8 onay modeli | ✓ | §7.4 — resmî PDF metinlerinden birebir doğrulandı |

---

## ✅ What works

- **İzolasyon çekirdeği sağlam.** §4 iki katmanı, transaction-ömürlü bağlamı ve "bağlamsız istek hata verir" davranışını AD-03/AD-04 ile birebir uyumlu tanımlıyor; §4.3 kabul kriteri "uygulama kapsamı devre dışıyken de veri gelmez" şartıyla AD-26'nın negatif test disipliniyle örtüşüyor. T-1'in "bulunamadı" (yetkiniz yok değil) davranışı kayıt varlığı sızıntısını da kapatıyor.
- **Audit ↔ dayanıklılık istisnası doğru kurulmuş** (kullanıcının 2. sorusu): §7.1 "audit yazılamıyorsa işlem gerçekleşmez" garantisi ile §12 "dış servis erişilemezse akış durmaz" ilkesi çelişmiyor, çünkü audit yazımı dış servis değil DB-içi işlemdir ve §12 istisnayı açıkça yazmış; damgalama (gerçek dış servis) §13'te doğru şekilde async'e ayrılmış — AD-21'in "damgalama ve WORM async" kuralıyla birebir.
- **T-5 ve T-6 birbirleriyle çelişmiyor** (kullanıcının 1. sorusu, ilk yarısı): T-6, T-5'teki doluluk sayısının nasıl doğru üretileceğini tanımlıyor; çatı §15'in "sayaç kapsam dışı okunur, satır bazlı sorgudan okunamaz" kuralının omurga karşılığı. (T-5'in sorunu başka: F-1.)
- **§7.3 ile §7.4 arasında çelişki yok** (kullanıcının 5. sorusu): §7.4'ün süreleri *eğitim kayıtlarına* (domain verisi) ilişkindir, §7.3'ün retention'ı *aktivite loguna* (liste/sayfa görüntüleme) — farklı veri sınıfları; §7.4 "audit saklamasından bağımsızdır" diyerek sınırı açıkça çiziyor. Mevzuat referansları resmî metinden doğrulandı. (Bu eksende kalan tek boşluk erişim logu retention'ı: F-5.)
- **k-anonimlik eşiği 2, spec'in kendi ilkesini zayıflatmıyor — upstream'e uyumlu** (kullanıcının 4. sorusu): AD-21 eşiği bilinçli ve gerekçeli seçmiş ("az personelli süreçte veri kaybedilmesin; amaç fişleme değil"); §8.5 buna birebir uyuyor ve kişi kırılımı/performans metriği yasağını ayrıca koruyor. k=2'de iki kişilik bir kırılımın üyelerinden biri diğerinin kullanımını çıkarabilir — bu kalıntı risk AD-21'in bilinçli trade-off'udur, spec bulgusu değildir.
- **Kabul kriterleri (§14) ölçülebilir** (kullanıcının 6. sorusu): 14 maddenin tamamı falsifiye edilebilir test senaryosuna çevrilebilir (çapraz erişim denemesi, kapalı yöntemle giriş, ikinci magic link kullanımı, audit engellendiğinde işlemin gerçekleşmemesi, k<2 kırılımın gösterilmemesi…). Temenni niteliğinde madde yok.
- Referans kodu bölümü (§9) AD-19'un güvenlik özünü (ardışık yasak, kod ≠ yetki, değişmezlik) eksiksiz taşıyor; R-6'nın bakanlık numaralarını açıkça ayrı tutması isabetli.
- §10.6 gelen e-posta sınırı ve "onay yalnız panelden" kuralı AD-14/AD-20 ile tam uyumlu; §13 sınır durumları tablosu (pasif kullanıcının oturumu, eşzamanlı yazma, sayaç atomikliği) omurga seviyesinde doğru soruları yakalamış.

## ⚠️ Findings & Risks (in-scope for this review type)

**F-1 — T-5 çok-tenant'lı kayıt kuralı, davet bazlı eğitim türüyle çelişiyor.** Çatı §5 üç eğitim türü tanımlar; üçüncüsü (çoklu kurumsal) *davet bazlı / seçilmiş firmalara* açıktır ve açık eğitim de *bölgeseldir*. T-5 ise çok-tenant'lı kayıtlarda "eğitimin varlığı, tarihi ve doluluk sayısı **herkese** görünür" der. Bu omurga garantisi olduğu gibi devralınırsa, davet bazlı bir grup-şirket eğitiminin varlığı ve doluluğu davetli olmayan tüm tenant'lara görünür — eğitim varlığı ve doluluk ticari bilgidir (AD-19 gerekçesindeki "iş hacmi sızar" ilkesinin aynısı). Çok-tenant'lı kaydın görünürlük kümesinin (herkese / bölge / davetli liste) nasıl belirlendiği omurga seviyesinde tanımsız.

**F-2 — K-2'nin önermesi imzalı yoklama için yanlış.** K-2, silme talebinin karşılanabilirliğini "silinemez kayıtlarda (audit, imzalı yoklama) kişisel veri **maskelenmiş** olduğu için" gerekçesine bağlıyor. Bu, yazım anında maskelenen audit için doğrudur (AD-16); ancak imzalı yoklama **taranmış bir belgedir** ve ad-soyad + ıslak imza (Y-2016 md.9/1-c gereği eğiticinin ad-soyad yazarak imzaladığı çizelge) maskesiz biçimde içeriğinin kendisidir. Silinemez + maskelenemez bir kayıt sınıfı için silme/anonimleştirme talebinin nasıl karşılanacağı (veya hangi hukuki dayanakla reddedileceği) tanımsız — K-2 gerilimi çözmüş görünüyor ama kritik kayıt sınıfında çözmemiş. (Kullanıcının 3. sorusunun cevabı: hâlâ açık.)

**F-3 — KVKK silme hakkı ile mevzuat saklama yükümlülüğünün etkileşimi tanımsız.** K-2 "talep, ana kayıttaki şifreli veriyi anonimleştirerek karşılanır" der; §7.4 ise eğitim kayıtları için mevzuat asgari saklama süresi (3 yıl / 5 yıl) koyar ve "altına inilemez" der. Saklama süresi dolmadan gelen bir silme/anonimleştirme talebinde davranış (talep reddedilir mi, ertelenir mi, kısmen mi karşılanır) spec'te yok. Ana kayıt anonimleştirilirse İdare denetiminde "kim eğitim aldı" sorusu cevapsız kalır — iki gereksinim yan yana duruyor ama kesişimleri kurallanmamış.

**F-4 — Erişim ve aktivite logları için yazım garantisi seviyesi tanımsız.** §7.1'in "audit yazılamıyorsa işlem gerçekleşmez" garantisi yalnız yazma olayları için kurulmuş; §7.5 kabul kriteri de yalnız yazmayı sınıyor. Hassas bir kaydın görüntülenmesi sırasında erişim logu yazılamıyorsa okumanın engellenip engellenmediği — ve aynı soru aktivite logu için — tanımsız. AD-21'in pazarlıksız 1. kuralı hangi log sınıflarını kapsıyor sorusu spec'te cevapsız; bu, plan aşamasına belirsizlik olarak sızar.

**F-5 — Erişim logunun saklama süresi tanımsız.** AD-21 erişim logu için "Uzun — mevzuat saklama süreleriyle uyumlu" der. Spec §7.3 aktivite loguna retention tanımlar (taban 2 yıl, admin-tanımlı), §7.4 eğitim kayıtlarına mevzuat tabanı koyar; §7.2 erişim logu için hiçbir saklama gereksinimi içermiyor. Aktivite retention'ının erişim loguna da uygulandığı yorumu mümkün ve yanlıştır — açık gereksinim yok.

**F-6 — Katılımcının tenant değiştirmesi (işveren değişikliği) senaryosu tanımsız.** §13 "ofis kullanıcısı dışındaki türlerde birden fazla tenant'a izin verilmez" ve "farklı tenant'larda aynı e-posta ayrı kullanıcı olabilir" der. Oysa eğitim geçmişi ve yenileme takibi **kişiye** bağlıdır: YÖN-2019 md.8 "af yok" kuralı gereği satışın doğru teklifi (yenileme mi tam eğitim mi) kişinin geçmiş sertifika tarihine dayanır ve çatı §14 bu kaydın yenileme motorunun temeli olduğunu söyler. Firma değiştiren bir katılımcının yeni tenant'ta yepyeni bir kayıt mı olduğu, geçmişinin izole mi kaldığı, kim tarafından hangi kurallarla taşınabildiği omurga kimlik modelinde tanımsız. Bu, dikey modüllerin (Spec 4+) kendi başına çözemeyeceği bir izolasyon/kimlik garantisi boşluğudur — spec'in kendi kuralıyla (§2 son cümle) bulgudur.

**F-7 — Bağımsız katılımcı aktör modelinde eşlenemiyor.** §3 bağımsız katılımcıyı tenant sayar (çatı 2. tur #14: fatura ona kesilebilir). Fatura kesilebilmesi ve teklif onayı, "müşteri kullanıcısı" davranışlarıdır; kişinin kendisi ise "katılımcı" türündedir. Dört tür birbirini dışlayan tanımlanmışken bağımsız katılımcının hangi türde olduğu — veya bir kişinin aynı anda iki tür olup olamayacağı — tanımsız. Kimlik doğrulama yöntemi matrisi ve izolasyon sınırı türe bağlandığı için bu belirsizlik omurganın kendi mekanizmalarını etkiler.

**F-8 — Hassas evrak dosyaları omurganın hassas veri güvencesinin dışında.** §8.1 şifrelemeyi yapılandırılmış alanlar (TCKN, kimlik, SGK, iletişim, banka) için tanımlar. Oysa sistemdeki en yoğun hassas veri taşıyıcıları dosyalardır: kimlik fotokopisi, SGK evrakı, imzalı yoklama taraması — TCKN'nin kendisini içerirler. Bu dosyaların saklanırken nasıl korunacağına dair omurga gereksinimi yok; §2'deki Spec 2 kapsamı da yalnız şablon/gereklilik motorunu kapsıyor, depolama korumasını değil. Alan şifrelenip aynı verinin dosyası korumasız kalırsa §8.1'in güvencesi kâğıt üstünde kalır — downstream'in ihtiyaç duyacağı garanti boşluğu (§2 son cümle kuralıyla bulgu).

**F-9 — İYS'ye onay/ret bildirimi gereksinimi eksik.** AD-17 day-one kararı iki bacaklıdır: onay alınır **ve** İYS bildirimi yapılır. §10.2 ilk bacağı (hard gate + kayıtların kanıtla saklanması) tanımlıyor; alınan onay ve retlerin İYS'ye iletilmesi — 6563 kapsamında hizmet sağlayıcı yükümlülüğü — spec'te gereksinim olarak yer almıyor. Kapı içeride doğru çalışsa bile İYS kaydı olmayan onay, mevzuat karşısında eksik kalır.

**F-10 — Referans koduyla kayıt bulma davranışı tanımsız.** §9 kodun üretim ve değişmezlik kurallarını tanımlar; ancak kodun varlık sebebi "destek ve iletişimde kullanım"dır ve AD-19 bunu "global arama koda göre bulur" işleviyle somutlar. Spec'te kodla kayda ulaşma davranışı (kimin, hangi yetki kontrolünden geçerek — R-5 bunu varsayar ama işlevin kendisi tanımlı değil) yer almıyor. İşlev tanımsızken R-5'in "kodla erişim her zaman yetki kontrolünden geçer" cümlesi boşlukta kalıyor.

**F-11 — §5.3 kendi içinde çelişkili.** "Katılımcı magic link ile girdiğinde ek bir kimlik teyidi adımı **uygulanır**" (kesin davranış) ile hemen ardındaki "bu adımın hangi kullanıcı türleri için zorunlu olduğu **admin ayarıdır**" (kapatılabilir) aynı anda doğru olamaz: admin katılımcı için kapatabiliyorsa ilk cümlenin garantisi yoktur; kapatamıyorsa ikinci cümle yanlıştır. Magic link'in kanıt sınırı zaten dar olduğundan bu teyidin zorunluluk seviyesi güvenlik duruşunu belirler — net olmalı.

**Not (blocker değil, dil):** §7.3'teki retention seçeneği ifadesi "(2 yıl / 5 yıl / daha eskisini sil)" muğlak okunuyor — "2 veya 5 yıl seçilir, eskisi silinir" kastediliyorsa yazımı netleştirilebilir. Typo/dil istisnası kapsamında, reject sebebi değildir.

## ❓ Open Questions (to be answered before next stage)

1. Çok-tenant'lı kaydın görünürlük kümesi kim tarafından, hangi seviyede belirlenir (F-1) — omurga bir "görünürlük kapsamı" kavramı mı tanımlayacak, yoksa tür bazlı sabit kurallar mı?
2. Saklama süresi dolmamış eğitim kaydına gelen KVKK silme talebinde resmi cevap ne (F-3): red mi, erteleme + otomatik yürütme mi?
3. Firma değiştiren katılımcının geçmişi kimin onayıyla, hangi kapsamda yeni tenant'a görünür olur (F-6)? Eski işverenin verisi üzerindeki hakkı ile kişinin kendi eğitim geçmişi üzerindeki hakkı nasıl ayrışır?
4. Bağımsız katılımcı tek kullanıcı mı, iki rollü tek kişi mi, yoksa "müşteri kullanıcısı" türünün özel hali mi (F-7)?
5. Erişim logu yazılamadığında hassas veri görüntüleme engellenir mi (F-4)? Aktivite logu için de aynı garanti mi geçerli?
6. Spec'teki 5 açık nokta (§15) makul şekilde downstream'e/plana devredilmiş; ancak §15/2 (anahtar yönetimi) plan aşamasına giderken F-8'in cevabı (dosya koruması) spec seviyesinde verilmelidir — hangi spec'in konusu olduğu netleşmeli.

## Verdict: ❌ REJECTED

Omurganın çekirdeği — iki katmanlı izolasyon, transaction-ömürlü bağlam, audit sınıfları ve istisna hiyerarşisi, analitik sınırı — upstream'e sadık ve büyük ölçüde iyi yazılmış; kullanıcının işaret ettiği altı noktadan dördü (T-5/T-6 tutarlılığı, audit/dayanıklılık istisnası, §7.3–7.4 ilişkisi, kabul kriterlerinin ölçülebilirliği, k=2 uyumu) temiz çıktı. Ancak matrix'te üç ❌ ve altı ⚠ satır var: çok-tenant'lı kayıt görünürlüğü davet bazlı eğitim türüyle çelişiyor (F-1), KVKK silme hakkı gerilimi imzalı yoklama sınıfında ve mevzuat saklama kesişiminde çözülmemiş (F-2, F-3), kimlik modeli katılımcının tenant değişimini ve bağımsız katılımcıyı taşıyamıyor (F-6, F-7) ve erişim logu ile hassas dosyalar için omurga güvenceleri eksik (F-4, F-5, F-8). Scope içinde bulgu varken orta yol yok. Bulgular çözülüp re-review talep edilmelidir.