# Review — Planlama, kontenjan ve bakanlık bildirimi spec v1.0 — 2026-07-29

> **Review type:** spec-review
> **Previous review:** N/A (ilk review)
> **Upstream document(s) read:** `cati-dokumani.md` (tamamı; özellikle §5, §10, §15, §16, netleştirme kararları ve açık noktalar) · `docs/specs/egitmen-spec.md` (tamamı; §6, §7, §11) · `docs/mevzuat-kurallari.md` (tamamı) · `design/HANDOFF.md` (tamamı) · `docs/arch/mimari-kararlar.md` (AD-08, AD-09, AD-11, AD-15, AD-19, AD-20, AD-21, AD-23, AD-24, AD-27) · `CLAUDE.md`
> **Other cross-referenced documents:** `mevzuat/1-egitim/IMDG_Kod_Kapsaminda_Egitim_ve_Yetkilendirme_Yonetmeligi.pdf` (Y-2016 md.6, md.7, md.13, md.16-18) · `mevzuat/1-egitim/IMDG_Kod_Egitim_Seminerlerine_Iliskin_Yonerge.pdf` (YÖN-2019 md.6, md.7, md.11, md.14) · `mevzuat/5-gozetim/Tehlikeli_Yuklere_Iliskin_Deniz_Ticareti_Gozetim_Hizmeti_Yonergesi.pdf` (TY-2019 md.17) · `mevzuat/5-gozetim/Deniz_Ticareti_Gozetim_Hizmetleri_Uygulama_Yonergesi.pdf` (DG-2020 md.14) · kod tarafı teyitleri: `database/migrations/2026_08_02_000100_create_training_definitions.php` (max/min_participants, notification_type/days, instructor_requirement, training_curricula), `2026_07_27_000200_create_customer_identity.php:307-322` (FK'sız training_id), `2026_08_03_000100_regulation_parents_and_instructor_requirements.php:83` (requires_document), `2026_07_28_000400_create_reference_codes.php`, `2026_08_04_000100_create_option_lists.php`
> **Stage locks in effect:** `egitmen-spec.md` APPROVED (heyet 158) — kararları yeniden açılmaz. Çatı ve AD'ler üst belge olarak esas alınır (çatı §16 bugünkü revizyonuyla okundu, commit `8bdbf9b`).

---

## Upstream Coverage Matrix

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| Çatı §5 (61-65) üç eğitim türü (kurumsal / açık / çoklu kurumsal) | ✓ | spec §2 — görünürlük + firma listesi (1 satır / N satır) tek mekanizma; açık eğitim dayanağı YÖN-2019 md.11 resmî metinden doğrulandı (PDF s.3) |
| Çatı §67 açık eğitim duyuru sistemi | ✓ (kapsam dışı, adresli) | spec §16 — satış turu |
| Çatı §102/§106 "planlama yapılmadan teklif süreci başlamaz" | ✓ | spec §7 (çatı §106 alıntılı), egitmen-spec §6.11 bağı spec §4.1 |
| Çatı §104-105/§194-196 planlamacı dashboard, il/firma kırılımı, sorgulama | ✓ | spec §1.1 (il alanı gerekçesi), §14 kokpit + sorgulama ekranları |
| Çatı §107-108 teklif iç onayı + müşteri onayı | ✓ (kapsam dışı, adresli) | spec §16 — EGT-26; kontenjan sözleşmesi §5'te yazılı |
| Çatı §110 iptal akışı: gerekçe, ALERT, bakanlık bildirimi, katılımcı/eğitmen bilgisi | ✓ | spec §11.1-11.2 tablosu; bildirim **görevi** md.16-17 yaptırım gerekçesiyle (resmî metinden doğrulandı, Y-2016 PDF s.3) |
| Çatı §147 kontenjan üst sınırı mevzuattan, hard block | ✓ | spec §5.1; 30 kişi Y-2016 md.13/ç ve 25 kişi TY-2019 md.17/1 resmî metinden doğrulandı |
| Çatı §148 üç sayılı gösterge; satışçı teklif sahibini görmez | ✓ | spec §5 tablo + P-26, P-32; `named_seats` dördüncü sayaç olarak eklenmiş, gösterge dili korunmuş |
| Çatı §149 denormalize sayaç + DB seviyesinde kilit | ✓ | spec §5.3, P-7 |
| Çatı §150 "önce onaylanan alır" | ✓ | spec §5 ⛔ satırı |
| Çatı §151 kontenjan teyidi — sistem seçmez, onay kaydedilir | ✓ | spec §5.4, P-27; onay ekranı metni EGT-26'ya adresli |
| Çatı §152 yedek liste: sıralı, otomatik terfi yok, gerekçe audit'e | ✓ | spec §6, P-9, P-31 |
| Çatı §153 eğitim öncesi iptal ≠ no-show | ✓ | spec §6.1, P-30 |
| Çatı §154 KUMS güncelleme bayrağı, "Devam Ediyor" kilidi | ✓ | spec §4.4, §10.4, P-18 |
| Çatı §16 (160/164) mevzuat + müfredat sürümünün saklanması | ✓ | spec §1.2, P-28 |
| Çatı §16 (161-163) sayı referanstır; uyarıya rağmen onay engellenmez + audit; tek istisna azami katılımcı | ✓ | spec §5.1, §5.5, §8.1, P-33, P-34 — bugünkü çatı revizyonuyla birebir |
| Çatı §16 (168) eğitim başına zorunlu evraklar → görev | ✓ | spec §1.3, P-29; mekanizma `OpenDocumentTasks` (T4) |
| Çatı §11 (188) / §186 tedarikçi teklifleri → bölgesel fiyat tarihçesi, MVP manuel | ✓ | spec §12; egitmen-spec §11/1 açık kalanı kapanıyor |
| Çatı §220 gece vardiyası uyarı seviyesinde, vardiya verisi toplanmaz | ✓ | spec §8.1; YÖN-2019 md.14/1 resmî metinden doğrulandı (PDF s.4) |
| `mevzuat-kurallari.md` §2 azami 30/25, asgari MEVZUATTA YOK | ✓ | spec §5.1 (sert), §5.5 (asgari yalnız uyarı, dayanaksızlığı kayıtlı), P-10 |
| `mevzuat-kurallari.md` §8 gece vardiyası + TMGD koordinasyonu (YÖN-2019 md.14/1-2) | ✓ | spec §8.1 iki uyarı, metinler mevzuat kaydının uyarı katmanından |
| `mevzuat-kurallari.md` §9 md.13/d yetkili eğitici; md.16-17 yaptırım | ✓ | spec §9.3, §11.2 — her ikisi resmî metinden doğrulandı |
| `mevzuat-kurallari.md` §9/§0 kayıt saklama süreleri (Y-2016 md.13/f 3 yıl; DGY 5 yıl) | ⚠ | spec §9.4/§17-2 saklama tabanını **yalnız** Y-2016 md.13/f'e bağlıyor; DGY ailesinin 5 yılı yok → **F-2** |
| `mevzuat-kurallari.md` §7.1 eğitici şartı: "en az **uzakyol** birinci zabiti veya **uzakyol** birinci mühendisi" (Y-2016 md.7/2-a) | ⚠ | spec §9.2 "asgari birinci zabit" diye anıyor ve "birinci zabit de karşılar" örneğini veriyor → **F-1** |
| `mevzuat-kurallari.md` §10 iki bildirim modeli (3 gün / 15 gün + onay, onaysız geçersiz) | ✓ | spec §10.1; Y-2016 md.13/g ve DG-2020 md.14/8 resmî metinden birebir doğrulandı |
| `mevzuat-kurallari.md` §11 / AD-27 uyarı ≠ kısıt, sayılar tanım alanı | ✓ | spec §1, §5.1 ⚠, §8.1, §10.1 (P-15: kodda gün sayısı yok) |
| `egitmen-spec.md` §6 atama zinciri, §6.3 aday listesi, §6.4 atomik kabul, §6.5 çakışma kaynağı | ✓ | spec §8 bağ tablosu; §5.3 aynı kilit deseni, §8.2 çakışma yalnız kesinleşmiş atama (K-4 korunmuş) |
| `egitmen-spec.md` §6.10 reconfirming, §6.11 satılabilirlik | ✓ | spec §4.3 tablo, §4.1 ⚠ (eğitmen ataması `planned` şartı değil — §6.11'e devredilmiş) |
| `egitmen-spec.md` §7.4 planlama onayı (global + planlamacı ayarı, daraltma/genişletme) | ⚠ | mekanizma spec §4.1-4.2'de birebir; **izin adı çelişik**: egitmen-spec §7.4/§9 ve AD-23 omurga tablosu (`mimari-kararlar.md:354`) `planning.approve`, bu spec §13 `training.approve` → **F-7** |
| `egitmen-spec.md` §11/1 tedarikçi kaydı açık kalanı | ✓ | spec §12 kapatıyor |
| `egitmen-spec.md` §11/2 yetkinlik kapısı veri modeli açık kalanı | ✓ | spec §9.1-9.3 kapatıyor; `instructor_requirements` + `training_definition_instructor_requirement` + `requires_document` kodda mevcut (migration teyitli); K-1 aynen korunmuş |
| `egitmen-spec.md` §11/3 resmî tatil takvimi | ✓ | spec §17/4 — aynı kalem, EGT-43 |
| `HANDOFF.md` §1 statü modeli: ortak omurga + iki bakanlık adı, KUMS bayrağı | ⚠ | spec §4 iki modeli kuruyor; ancak iptal talebinin hangi statülerden açılabildiği ve ret sonrası dönüş geçişi tanımsız → **F-5** |
| `HANDOFF.md` §4 limit aşımı akışı kırmaz, ret gerekçeli | ✓ | spec §4.2 (onay geçişin içinde), §11.1 ⚠ (talepte ve rette gerekçe) |
| `HANDOFF.md` §5 "planlamacı müşteri seçmez" | ⚠ (bilinçli sapma) | spec §2.1 — sapma gerekçeli ve doğru yerde (aşağıda "What works"); ancak sapmanın dayandığı satışçı-görünürlük kuralı spec'te tanımsız → **F-3** |
| `HANDOFF.md` §7 KUMS kimliği bizim kodumuz değil, ayrı alan | ✓ | spec §10.3 ⚠ |
| `HANDOFF.md` §15 kontenjan/yedek liste kuralları | ✓ | spec §5-6 birebir |
| AD-15 iki model, Bakanlık ID kapısı, onay kanıtı | ✓ | spec §4 ⚠, §10.1, §10.4, P-15/P-16/P-17 |
| AD-19/AD-20 PL→EG tek istisna, son ek korunur, eski kod yönlendirir, `(yıl, son ek)` benzersizliği | ✓ | spec §3, P-3 — AD-19 metniyle birebir |
| AD-23 kapsam seviyeli yetkiler (.own/.group/.all), kapsam çözümleyici | ✓ | spec §13, P-24; `training.create`'te `.own` yokluğu T4 emsaliyle gerekçeli |
| AD-24 gereklilik motoru, kapsam = eğitim | ✓ | spec §1.3 |
| AD-11 / kırmızı çizgi 12 silinmezlik | ✓ | spec §11.3, P-21 |
| AD-02/AD-03 tenant izolasyonu — firma taşıyan yeni kayıtların görünürlük gereksinimi | ❌ | Kapalı eğitim firma listesi, yedek liste ve talep kuyruğu firma verisi taşıyor; kim hangi kapsamla görür, çoklu kurumsal listede firma A firma B'yi görür mü — spec'te yok → **F-3, F-4** |
| Çatı §16 "sistemin işi bildirimi yapmak ve **uyarmak**" + Y-2016 md.13/g süre şartı | ❌ | İlk bakanlık bildirimi için son tarih yaklaşırken/geçerken sistem davranışı (uyarı/görev, kime) tanımsız → **F-6** |
| AD-05/AD-21 hassas veri erişimi — donmuş kanıt seti kopyaları | ⚠ | spec §9.4 kopyanın KVKK bedelini kaydediyor ama kopyalara **erişim** tanımsız → **F-8** |

---

## ✅ What works

- **Mevzuat sayılarının tamamı resmî metinden doğrulandı ve doğru:** 30 kişi (Y-2016 md.13/ç), 25 kişi (TY-2019 md.17/1), 3 gün bildirim (Y-2016 md.13/g), 15 gün + onay + "onaylanmamış eğitimler geçersiz sayılır" (DG-2020 md.14/8), md.13/d yetkili eğitici, md.16-17 yaptırım zinciri (idari para cezası → 1 ay süre → 3 ay askıya alma → iptal), YÖN-2019 md.6/3 KUMS + kursiyer bilgisi, md.11 ortak eğitim, md.14/1-2 gece vardiyası ve TMGD koordinasyonu. §10.1 tablosu ve §5.1 gerekçesi resmî metinlerle birebir örtüşüyor. Sayıların hiçbiri koda yazılmıyor; hepsi tanım alanından okunuyor (P-6, P-15) — kırmızı çizgi 14 spec düzeyinde korunmuş.
- **HANDOFF §5 sapması doğru yerde.** Tasarım çıktısı bağlayıcı sayfa şartnamesi değil; iş kuralının tek kaynağı çatı, ve çatı §63'ün kurumsal eğitimi tanımı gereği planlama aşamasında firmasıyla doğar. "Sahipsiz kapalı eğitim = tüm satış havuzuna açık eğitim" gerekçesi çatı §102'nin ruhuyla tutarlı. Sapmanın kendisi ve gerekçesi spec'te kayıtlı — usul doğru. (Sapmanın dayandığı görünürlük mekanizmasının tanımsızlığı ayrı bir bulgu: F-3.)
- **Kapsam sınırı (teklif/katılımcı tablolarının EGT-26/27'ye bırakılması) doğru yerden geçiyor.** Spec, teklif tarafına bakan yüzü sözleşme olarak yazmış (§5: onaylanan teklif `confirmed_seats`'i artırır, sert sınır oradadır; §5.4 teyit durumu; §6.2 yedek ibaresi), tablo tanımını satış spec'ine bırakmış. `pending_seats`'in dolduran tarafı bu turda yok — bu bir backbone teslimidir, kapanış adresi §16'da yazılı; CLAUDE.md onay kuralı 4'ün istisnası tam olarak bu durumu tanımlar. Bulgu değildir.
- **Kontenjan kilidi tasarımı yarışı kapatıyor.** Sert sınırın yalnız `confirmed_seats ≤ capacity` üzerinde, veritabanı kısıtı + satır kilidiyle olması (P-7 "eşzamanlı iki rezervasyondan yalnız biri geçer") uygulama-katmanı kontrolünün açığını kapatır; `pending_seats`'in sınır dışı bırakılması çatı §148 ("teklif bekleyen" bilgidir) ve egitmen-spec §6.5 ("bekleyen teklif bloklamaz, kabul bloklar") ile aynı kuralın aynı çalışmasıdır. Doğru.
- **Dört sayaç ayrımı gerçek akışa oturuyor:** `named_seats < confirmed_seats` uyarısının YÖN-2019 md.6/3'e (bildirim kursiyer bilgisi ister) bağlanması, sayaçları süs olmaktan çıkarıyor.
- **AD-19 istisnası birebir uygulanmış** (PL→EG, son ek korunur, eski adres yönlendirir, benzersizlik `(yıl, son ek)` uzayında); egitmen-spec §8.3'ün "PL henüz kayıtlı değil, kapanış plan aşaması" notuyla tutarlı.
- **Öz-denetimde bulunan altı eksiğin altısı da gerçekten kapatılmış** (üçüncü sayaç, kontenjan teyidi, iptal/no-show, mevzuat sürümü, eğitim evrakları, gece vardiyası/TMGD) — matriste karşılıkları ✓.
- Kabul kriterleri (P-1…P-34) gözlemlenebilir ve ölçülebilir; non-goal'lar §16'da adresli.

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

**F-1 — Mevzuat alıntısı resmî metinle çelişiyor (§9.2).** Spec, Y-2016 md.7/2'yi *"asgari birinci zabit"* diye anıyor ve *"uzakyol kaptanı da birinci zabit de karşılar"* örneğini veriyor. Resmî metin (Y-2016 md.7/2-a, PDF s.1): *"En az **uzakyol birinci zabiti** veya **uzakyol birinci mühendisi** ehliyetine sahip olmak."* "Uzakyol" nitelemesi iki kez düşmüş; uzakyol olmayan bir birinci zabit ehliyeti bu eşiği **karşılamaz**. Projenin kendi doğrulanmış kural seti (`mevzuat-kurallari.md` §7.1) doğru yazıyor — spec ondan sapmış. Bu cümle, şart × kabul edilen belge türleri tanımını backoffice'te yapacak kişinin okuyacağı gerekçe metnidir; yanlış örnek, yetkisiz eğitmeni aday listesine sokan bir belge türü tanımına yol açar (md.13/d ihlali, md.16-17 yaptırımı).

**F-2 — Donmuş kanıt setinin saklama tabanı tek mevzuata bağlanmış (§9.4, §17/2).** Spec asgariyi yalnız Y-2016 md.13/f'e (3 yıl) bağlıyor. Kayıt saklama süresi eğitim ailesine göre değişir: DGY tarafında 5 yıl (DG-2020 md.14/4; `mevzuat-kurallari.md` §0 tablosu ve §9 sistem sonucu "asgari retention" notu). Tek "3 yıl" tabanı, DGY eğitiminin kanıt seti için mevzuat altı bir saklama kararına zemin hazırlar. AD-27'ye göre kayıt saklama süresi zaten eğitim tanımının alanıdır; spec bunu tüm kanıt setleri için tek sayı gibi anıyor.

**F-3 — Kapalı eğitimin satışçı tarafındaki görünürlüğü tanımsız (§2, §2.1, P-2).** §2.1 kararının gerekçesi *"tüm satışçılara düşmesin"*; ama spec yalnız firma tarafı görünürlüğü tanımlıyor (P-2 "yalnız listelenen firmalara görünür" — kime görünür belirsiz: müşteri portalı mı, satış paneli mi?). Kapalı bir eğitimi hangi satışçının görüp satabileceği (listelenen firmalara atanmış satışçılar mı, AD-23 kapsamı mı, ikisinin kesişimi mi) hiçbir yerde yazılmıyor ve EGT-26'ya açık bir devir de yok. Kararın tüm gerekçesi bu kurala dayanırken kuralın kendisi boşlukta.

**F-4 — Yedek liste, talep kuyruğu ve çoklu kurumsal firma listesinin rol/tenant görünürlüğü tanımsız (§2, §6, §7).** Üç yeni kayıt türü de firma verisi taşıyor: (a) yedek listede hangi firmaların sırada olduğunu satışçı/müşteri görür mü — çatı §148 teklif sahipliği için "satışçı görmez" derken yedek liste için spec sessiz; (b) talep kuyruğu `training_request.view` iznini alıyor ama kapsam davranışı (hangi satışçı/planlamacı hangi firmaların taleplerini görür) tanımsız; (c) çoklu kurumsal eğitimde (N firma) firma A, listede firma B'nin adını görür mü — grup şirketi senaryosunda zararsız, bağımsız firmalar yan yana listelendiğinde müşteri-müşteriye ifşadır. Tenant izolasyon gereksinimi bu spec'in yarattığı kayıtlar için açıkça yazılmamış (Müşteri A ≠ Müşteri B spec'te yer almalı).

**F-5 — Statü makinesinde iptal geçişleri eksik (§4, §11).** (a) `cancellation_requested`'a hangi statülerden girilebildiği tanımsız: şema yalnız `ministry_notified/approved` ve `in_progress`'ten gösteriyor; oysa §4.3 teklif açılmış `planned` eğitim için *"tek yol iptal + yeniden planlama"* diyor — `planned → cancellation_requested` geçişi ne şemada ne metinde var. (b) `draft`'ın iptali tanımsız: hiçbir taahhüt taşımayan taslak da onaylı iptale mi tabi, yoksa başka bir yaşam sonu mu var? (c) `completed` eğitimin iptal edilemeyeceği hiçbir yerde yazılmıyor. (d) İptal talebi **reddedilirse** kayıt hangi statüye döner — ret gerekçesi zorunlu (§11.1 ⚠) ama ret sonrası geçiş şemada ve metinde yok. Statü makinesinin tek kaynağı olduğunu iddia eden bölüm için bunlar tanımsız davranıştır.

**F-6 — İlk bakanlık bildirimi için son tarih davranışı tanımsız (§10).** Spec'in kendi ilkesi *"sistemin işi limit alanını sunmak, bildirimi yapmak ve uyarmaktır"* (§8.1, çatı §16) ve §17/4 iş günü hesabını "bildirim süreleri" için istiyor; iptal bildirimi için görev açılıyor (§11.2, gerekçe md.16-17 yaptırımı). Ama **ilk** bildirim/onay başvurusu için hiçbir davranış tanımlı değil: bildirim son günü yaklaşan ya da geçmiş `planned` eğitimde sistem ne üretir (uyarı mı, görev mi), kime düşer (`training.notify_ministry` taşıyanlara mı)? §11.2'nin kendi cümlesi geçerli: *"unutulan bir bildirimi hatırlatan tek şey bir uyarı metniyse, o bildirim unutulur"* — aynı yaptırım riski ilk bildirim için de var ve spec bu durumda sessiz. (Onay modelinde 15 günün kaçırılması eğitimi fiilen geçersiz kılar — DG-2020 md.14/8.)

**F-7 — İzin adı iki belge arasında çelişik (§13).** Bu spec `training.approve` diyor ve düzeltmeyi ilan ediyor; ancak onaylı `egitmen-spec.md` §7.4/§9 ve AD-23'ün onay omurgası tablosu (`docs/arch/mimari-kararlar.md:354`) hâlâ `planning.approve` yazıyor. Kodda henüz hiçbir kullanım yok (grep doğrulandı — ad değişikliği davranış değiştirmiyor, onaylı kararın kendisine dokunmuyor; yön doğru). Ama ilan edilmiş, uygulanmamış bir düzeltme çelişkiyi kapatmaz: bugün iki onaylı belge aynı izin için iki ad taşıyor ve izin matrisini okuyan kişi iki ayrı onay türü var sanır. Düzeltme upstream belgelere işlenene kadar çelişki açıktır.

**F-8 — Donmuş kanıt setine erişim tanımsız (§9.4).** Kopyalar eğitmenin kişisel belgeleridir (eğitici belgesi, ehliyet vb.) ve spec kendisi KVKK çoğaltma bedelini kaydediyor; ama kopyaları **kimin görebildiği** yazılmıyor. Orijinal dosya için rejim kurulu (egitmen-spec §2.1: maskeli gösterim, açık görüntüleme ayrı eylem, erişim logu); eğitim kaydına kopyalanan nüsha için hiçbir erişim/loglama gereksinimi tanımlı değil. Eğitim kaydını görme yetkisi taşıyan herkesin (örn. satışçı, §8.2 gereği maliyeti görüyor) kanıt setini de görmesi mi bekleniyor — tanımsız. Hassas veri erişim gereksinimi spec scope'undadır.

### Not — blocker olmayan düzeltmeler (typo/format)

- §17/3 çapraz referans yanlış: çevrimiçi biçim §1.4'te, "(§1.2)" yazıyor.
- §18 revizyon geçmişi "25 kabul kriteri" diyor; tabloda 34 kriter var (P-1…P-34).

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

1. **Çoklu mevzuat bağında sürüm saklama:** çatı §165 "bir eğitim birden fazla mevzuata bağlanabilir" der; §1.2 tekil "mevzuatın o günkü sürümü"nden söz ediyor. Birden fazla bağ varsa hepsinin sürümü mü saklanır? (Bugünkü veri modeli tek `regulation` bağı + `regulation_parents` zinciriyse bunun kayda geçmesi yeterli olabilir — ama spec söylemeli.)
2. **`max_participants` boş olan tanımda (DGY — mevzuatta üst sınır yok) kapasite davranışı:** tavan yok mu sayılır? §5.1 bu durumu anmıyor.
3. **F-7'nin kapanış yolu:** `planning.approve` → `training.approve` düzeltmesi egitmen-spec ve AD-23 metnine hangi turda işlenecek? (Karar Sets'indir; çelişki kapanmadan plan aşamasına geçilmemeli.)
4. Donmuş kanıt setinin KVKK üst sınırı (§17/2) — F-2 ile birlikte **aile bazlı taban** olarak yeniden ele alınmalı.

## ⚠️ Upstream Findings

Yok. (F-7 çelişkisi bu spec'in ilan ettiği bir düzeltmedir; egitmen-spec'in onaylı kararının kendisinde hata yoktur — red-line/tenant/mevzuat ihlali seviyesinde upstream dönüşü gerektirmez.)

## Verdict: ❌ REJECTED

Matris 3 satırda ⚠/❌ dışı kalmıyor değil — 6 satır ⚠/❌ ve bunlardan F-1 (mevzuat alıntısının resmî metinle çelişmesi) ile F-3/F-4 (firma verisi taşıyan yeni kayıtların görünürlük/izolasyon gereksinimlerinin yokluğu) tek başına red sebebidir. Spec'in omurgası sağlam: kontenjan modeli, bakanlık iki-modeli, yetkinlik kapısı, AD-19 istisnası ve tasarım sapması doğru kurulmuş ve mevzuat sayılarının tamamı resmî metinle örtüşüyor. Sekiz bulgu da mevcut kararların değiştirilmesini değil, tanımsız bırakılmış davranışların yazılmasını ve iki mevzuat referansının düzeltilmesini gerektiriyor.