Mustafa Sezer Başar

Bir denetim firması için geliştirilen saha denetim sisteminin kural motoru: mevzuatı RAG ile okuyup denetim kurallarına çeviren, uçtan uca çalışır durumdaki bileşen. Külliyat kendi topladığı kaynaktan geliyor: mevzuat ve Yargıtay/Danıştay kararlarını çekip veritabanına yazan bir toplayıcı yazdı, RAG bunun üzerinde çalışıyor. Kurallar madde referansı ve zaman geçerliliğiyle JSON'da tutuluyor, insan onayından geçiyor, sonrasını Go servisi deterministik olarak uyguluyor. LLM sıcak yolda değil — çevrimdışı çalışıyor, böylece her denetim koşusu tekrarlanabilir ve gerekçelendirilebilir kalıyor. Mükellef verisi sistemden hiç çıkmıyor: dışarıdaki dil modeli yalnızca kamuya açık mevzuatı görüyor.

• Python (LLM)
• Go
• Next.js
• MySQL

Çok ülkeli bir perakende grubu için hedef veri mimarisi ve aşamalı geçiş yolu: altı belge, beş karar kaydı. Teşhis, problemin hacim olmadığı: yılda ~150 milyon satır, bölümlenmiş tek bir ilişkisel veritabanının rahat taşıdığı büyüklük. Problem tanım (aynı kelime farklı sayı), otorite (tek yayınlayan yok) ve gecikme (tutarsızlık ancak büyüyünce fark ediliyor). Bu yüzden mimarinin büyük kısmı kurulmayacak şeylerin listesi: dağıtık işleme, veri gölü ve akış altyapısı gerekçeli olarak kapsam dışı. Power BI, Excel ve dil modeli erişimi aynı semantik katmana bağlanıyor — tanım tek yerde yaşamazsa üç yerde yaşar ve üç farklı sayı üretir. Dil modeline serbest SQL verilmiyor; metrik biçiminde araçlar veriliyor ve soruyu soranın yetkisiyle çalışıyor. Geçiş sırasının birinci kısıtı benimsenme: hiçbir eski yol, yenisinin çalıştığı görülmeden kapatılmıyor. Tasarım aşamasında — hiçbir geçiş aşaması tamamlanmadı ve hacim rakamları işin şeklinden türetildi, ölçümden değil.

• Mimari tasarım
• katmanlı ilişkisel veri ambarı
• semantik katman
• ADR

Misafirin resepsiyona uğramadan giriş yapmasını sağlayan, ticari olarak geliştirilmiş ürün. Kullanıma hazır hâle geldi ama sahaya alınmadı: bölgede kullanılan otel yönetim sistemi dışarıdan entegrasyona kapalıydı. Akış üç adımlı: kimlik ya da pasaport yükleniyor ve üzerindeki bilgiler Tesseract ile okunuyor, misafir kendi fotoğrafını çekiyor, iki yüz face_recognition ile karşılaştırılıyor — ardından konum doğrulanıyor, çünkü yüz eşleşmesi kişinin kim olduğunu kanıtlar, otelde olduğunu kanıtlamaz. Yüz verisi KVKK m.6'da özel nitelikli sayıldığından akış açık rıza kapısıyla başlıyor ve rıza vermeyen misafir resepsiyonda yüz yüze giriş yapabiliyor: alternatifi olmayan onay hukuken rıza sayılmaz. Fotoğraf saklanmıyor: karşılaştırma bittiğinde geriye yalnızca yüzün sayısal temsili kalıyor ve onun saklama süresini otel kendisi belirliyor — KVKK'da veri sorumlusu otel olduğuna göre kararın da orada olması gerekiyor. Canlılık tespiti yok; sistem ekranda gösterilen bir fotoğrafla kandırılabilir ve konum doğrulaması bu açığı kapatmıyor.

• Python
• Tesseract OCR
• face_recognition

Çalışan PII'sini alan bazında AES-256-GCM ile şifreleyen full-stack sistem: kişi başına anahtar sayesinde silme, anahtarın imhası (kripto-parçalama); rol bazlı maskeleme, hash zincirli denetim logu ve politika tablosundan üretilen 64 düşman testi. Uyum iddiaları, kirliyse yapıyı düşüren bir kanıt raporundan geliyor.

• TypeScript
• Express
• node:sqlite
• Node crypto (AES)

Birden fazla rezervasyon kanalından (Booking, Hotels vb.) her gün fiyat toplayacak, zaman serisi olarak saklayacak ve üzerine fiyat önerisi üretecek biçimde yazılmış uçtan uca sistem: toplama, bot korumasına takılan headless yaklaşım yerine gerçek oturumda çalışan bir Chrome uzantısıyla yapılıyor; geçmiş PostgreSQL'de, üstünde Express API ve React + Recharts arayüz. Önerinin ayırt edici girdisi rakip doluluğu — fiyat herkese açıktır, doluluk değildir. Kanalın müsaitlik sorgusunda oda sayısını artırarak ikili arama yapılıp rakibin gösterdiği kalan envanter bulunuyor, tesisin ilan edilmiş oda sayısına bölünerek doluluk tahmin ediliyor. Rezervasyon oluşturulmuyor; yalnızca her müşterinin görebildiği müsaitlik yanıtı okunuyor. Yöntemin ne kadar doğru olduğunu ölçmek için açık kaynak bir çalışma yazdı: gerçek doluluğun bilindiği simüle bir pazarda naif okuma 35 puan, sansürlü regresyonla kurulan tahmin edici 12 puan hata veriyor — ama gelir etkisi ölçüldüğünde kazancın, hiçbir toplayıcı gerektirmeyen tek satırlık bir kontrolü geçmediği çıktı ve öyle raporlandı.

• TypeScript
• Express
• node:sqlite
• Chrome Extension

Bir proje takviminin taahhüt edilen tarihi tutma olasılığını ölçen simülasyon çalışması. Yirmi faaliyetlik bir ERP geçiş takviminde deterministik kritik yol 105,2 gün veriyor; aynı tahminlerden 40.000 kez simüle edildiğinde bu tarih koşuların yalnızca %34'ünde tutuluyor. Fark tahminlerden değil ağın şeklinden geliyor: her birleşme noktası paralel yolların en yavaşını bekliyor. Etiketsiz kontrol ağlarında gösterildi ki hiçbir görev uzatılmadan yalnızca paralel yol ekleyerek proje 12,6 gün geç bitiyor. Ayrıca kritiklik endeksinin altı faaliyeti 1,0'da berabere bıraktığı, oysa bitişe etkilerinin 4,6 kat farklı olduğu ölçüldü. Müdahale karşılaştırması ortak rastgele sayılarla eşleştirildi; koşum öncesi yazılan hipotezin mekanizması çürüdü ve öyle raporlandı.

• Python (NumPy
• SciPy
• Monte Carlo)