EBYS (Elektronik Belge Yönetim Sistemi), kurumların tüm evrak, belge ve iş akış süreçlerini tek bir güvenli platformda toplayan çok kiracılı (multi-tenant) bir belge yönetim ürünüdür. Fiziksel arşiv maliyetlerini ortadan kaldırır, onay/imza/havale süreçlerini otomatikleştirir ve belgeler üzerinde yapay zekâ destekli arama, özetleme ve risk analizi sağlar.

Kimler için?

Yoğun evrak trafiği olan kamu kurumları, holdingler ve KOBİ'ler için tasarlanmıştır. Gelen/giden evrak kaydı, kurumsal hiyerarşiye göre paraf ve imza zincirleri, saklama (retention) ve imha süreçleri ile mevzuata uyum gereksinimlerini karşılar.

Öne çıkan yetenekler

Mimari özet

Backend, .NET 8 üzerinde alan-odaklı (domain-driven) bir tasarımla kuruludur. Her iş alanı kendi domaini, veritabanı şeması ve servis ucuyla yalıtılmıştır. Çok kiracılı izolasyon, her tablonun composite anahtarında (TenantID + ID) taşınır. Frontend ise Next.js (Pages Router) tabanlı iki uygulamadan oluşur: kiracı kullanıcıları için EBYS_Site_App ve platform yöneticileri için EBYS_Admin_App.

Ürün vaatleri ve ölçülebilir hedefler

EBYS yalnız bir özellik listesi değil, ölçülebilir deneyim vaatleri üzerine kuruludur. Aşağıdaki hedefler her sürümde korunması beklenen ürün taahhütleridir; analiz ve test dokümanlarında kabul kriteri olarak kullanılır.

EBYS yalnızca belge depolayan bir DMS değildir. Hedef; Türkiye pazarı için güçlü EBYS uyumunu, global ölçekte rekabetçi metadata-first belge zekasını ve son kullanıcı için düşük eğitim ihtiyacı olan görev odaklı deneyimi tek platformda birleştirmektir. Önerilen konumlandırma: EBYS + DMS + Workflow + Form Designer + Archive + Governed AI; multi-tenant SaaS veya özel kurulum için aynı çekirdek.

Pazar segmentleri

Rakiplerden öğrenilenler

Farklılaştırma ilkeleri

Paketleme stratejisi

EBYS senaryoları farklı aktörlerin sorumluluklarına göre kurgulanmıştır. Bir aktörün hangi uygulamayı kullandığı, ekran ve yetki tasarımını doğrudan belirler. Aşağıdaki tablo, analiz dokümanlarındaki aktör modelini özetler.

Yetkilendirme modeli

• Yetki kararı = RBAC AND ABAC AND DocumentPermission AND tenant eşitliği. Tüm koşullar birlikte sağlanmalıdır.
• Deny kuralı Allow üzerinde önceliklidir; çakışmada erişim engellenir.
• Sistem rolleri değiştirilebilir ama güvenlik açısından silinemez veya temel izinleri boşaltılamaz.
• Belge erişimi klasör adına değil yetki ve metadata'ya göre değerlendirilir.

EBYS, sol navigasyonda görünen işlevsel alanlardan ve bunları besleyen backend domainlerinden oluşur. Aşağıda hem kullanıcı modülleri hem de teknik domainler özetlenmiştir.

Kullanıcı modülleri (sol menü)

Backend domainleri

Entegrasyon sağlayıcıları

Dış servisler, bağımlılıktan arındırılmış 9 arayüz (IObjectStorage, ISearchIndexer, IOcrEngine, ILlmGateway, ISignatureProvider, IFileScanner, IWebhookPublisher, IStorageManagementProvider, IAIProviderHealthProbe) üzerinden bağlanır. Varsayılan implementasyonlar arasında yerel dosya depolama, Anthropic/Claude LLM ağ geçidi (OpenAI-uyumlu embedding ile), OpenSearch/Elasticsearch indeksleyici, OCR.space motoru, ClamAV virüs tarayıcısı ve HMAC imzalı webhook yayıncısı yer alır.

Use case seti, ürünün yalnız modül listesini değil; self-service onboarding, çok kanallı belge alımı, kalite kapılı upload, kontrollü dış paylaşım, kişiselleştirilmiş çalışma alanı ve tenant bazlı ürün politikaları gibi farklılaştırıcı iş akışlarını da kapsar. Her senaryo multi-tenant güvenlikle başlar; kullanıcı az karar ile, geri dönülebilir biçimde ilerler; AI yalnız öneri üretir, kritik resmi adımlar insan onayı gerektirir.

Use case haritası

Kritik senaryolar — derinleştirme

Use case işlemleri (dallanmalar)

Aşağıdaki tablo her use case içinde kullanıcının yapabileceği ayrı aksiyonları/dallanmaları özetler: yeni ekleme, düzenleme, silme/iptal, senkronize/yenileme ve durum geçişleri (onay/ret/havale/imza vb.).

Backend .NET 8 üzerinde alan-odaklı (domain-driven) bir tasarımla kuruludur. Her domain tam dikey dilim olarak inşa edilir: Domain (entity + iş kuralı) → Data.API (iş mantığı) → Rest/RestFE (controller) → DI wiring → seed. Çok kiracılı izolasyon her tablonun composite anahtarında (TenantID + ID) taşınır; filtre sonradan eklenmez.

API konvansiyonları

Entegrasyon arayüzleri (9 sözleşme)

Dış servisler bağımlılıktan arındırılmış arayüzler üzerinden bağlanır; her birinin değiştirilebilir bir concrete implementasyonu vardır. Bu, 'kapalı kutu' hissini kırar ve tenant bazlı sağlayıcı seçimine olanak tanır.

Eventing, outbox ve webhook

• Domain olayları OutboundEvent (outbox) tablosuna yazılır; teslimat asenkron ve idempotent çalışır.
• Webhook abonelikleri tenant bazlıdır; teslimat HMAC imzalıdır ve başarısız event'ler retry edilebilir.
• Entegrasyon sırları (IntegrationCredential/Secret) tenant bazlı şifreli saklanır ve RestFE'de maskelenir; log'a yazılmaz.

Sahiplik: Bring Your Storage / Bring Your AI

BYOS'ta dosya binary'leri tenant'ın kendi storage sağlayıcısında tutulur; platform yalnız referans, hash, boyut ve provider metadata'sını saklar. BYAI'da AI çağrıları tenant'ın kendi provider hesabı ve anahtarı ile yapılır. Bu yaklaşım veri sahipliğini artırır, vendor lock-in'i azaltır ve regüle kurumların satın alma bariyerini düşürür.

AI burada ayrı bir vitrin değil, belge yaşam döngüsünü hızlandıran denetimli (governed) yardımcı katmandır. Her öneri güven skoru (confidence) ve kanıt (evidence) ile gelir; kullanıcı düzeltmeleri geri besleme metriklerine işlenir.

Öncelikli AI yetenekleri

• Belge tipi önerisi ve sınıflandırma
• Metadata (alan) çıkarımı
• Özet ve önemli maddeler
• Eksik imza / eksik ek / zorunlu alan kontrolü
• Riskli ifade tespiti
• Yetki filtreli belge Q&A (yalnız izinli parçalar retrieval'a girer)
• Süreç şablonu önerisi

Sağlayıcı yaklaşımı

AI katmanı tek provider'a gömülü değildir. Tenant seviyesinde desteklenen sınıflar: OpenAI, Azure OpenAI, Claude, Gemini, Amazon Bedrock, Ollama / şirket içi model ve Custom provider. Tenant AI ayarında en az şu alanlar bulunur: provider tipi, API key/bağlantı sırrı, model, embedding modeli, sistem prompt paketi, timeout / rate limit / maliyet politikası.

Zorunlu guardrail ilkeleri

Aşağıdaki adım adım kılavuzlar en sık kullanılan senaryoları kapsar. Tüm akışlar oturum açmış bir kullanıcı gerektirir; ekranlara giriş yaptıktan sonra ulaşabilirsiniz.

Belge yükleme (S-05)

1. 1Üst bardan “Hızlı Yükle” veya Belgeler ekranından “Yeni Belge” ile sihirbazı açın.
2. 2Dosyayı seçin veya sürükle-bırak yapın.
3. 3Belge tipi ve AI tarafından önerilen özeti gözden geçirin.
4. 4Belge tipine göre açılan dinamik metadata formunu doldurun.
5. 5Klasör / saklama planını (SDP) seçin.
6. 6Kalite kapısını geçin, önizleyin ve kaydedin.

Onay süreci tasarlama (S-11)

1. 1Süreçler → Tasarımcı ekranını açın.
2. 2Yeni bir tanım oluşturun ve adımları ekleyin (ad, tip, atama, SLA).
3. 3Adımları yukarı/aşağı sıralayın; paralel onaylar için Parallel adım tipini kullanın.
4. 4Gerekirse Form Tasarımcısı’nda (S-12) ilişkili formu hazırlayın.
5. 5“Yayınla” ile süreci aktif edin.

Görev karara bağlama (S-09)

1. 1Görevlerim listesinden bir görevi açın.
2. 2Belge özetini, versiyon farkını ve süreç timeline’ını inceleyin.
3. 3Onayla / Reddet / Revizyon iste seçeneklerinden birini, gerekirse yorum ekleyerek uygulayın.
4. 4Gerekirse görevi başka bir kullanıcıya Yeniden Ata veya Vekalet ver.

Gelen evrak kaydı ve havale (S-13)

1. 1Evrak → Gelen Evrak ekranını açın.
2. 2Kanal bazlı gelen kaydı seçin; OCR ve kalite durumunu kontrol edin.
3. 3“Kaydet” ile defter sırasından kayıt numarası üretin (Prefix-Yıl-Sıra).
4. 4Toplu veya tekil “Havale” ile ilgili birim/kullanıcıya yönlendirin.

Güvenli paylaşım linki oluşturma (S-19)

1. 1Belge detayında Paylaşım sekmesini açın.
2. 2Süre, OTP ve watermark ayarlarını yapın.
3. 3Linki kopyalayın; harici kullanıcı /verify/[token] üzerinden doğrular.
4. 4Gerektiğinde paylaşımı “İptal Et” (revoke) ile geçersiz kılın.

AI asistanı ile belgeye soru sorma (S-16)

1. 1Belge detayında AI Asistan ekranını açın.
2. 2Soru-cevap panelinden sorunuzu yazın.
3. 3Citation kartları, özet ve risk görünümünü inceleyin.
4. 4AI’nın önerdiği metadata’yı kabul / düzelt / reddedin.

Kiracı kurulumu (yönetici, S-31)

1. 1Yönetim → Setup ekranındaki rehberli kurulumu açın.
2. 2Eksik setup listesini takip ederek birim, rol ve kullanıcıları tanımlayın.
3. 3Belge tipleri, sınıflandırmalar ve retention kurallarını yapılandırın.
4. 4Storage entegrasyonu (S-32) ve AI provider (S-33) ayarlarını tamamlayın.

EBYS iki uygulamadan oluşur. EBYS_Site_App kiracı kullanıcılarının günlük işlerini yürüttüğü uygulamadır; EBYS_Admin_App ise platform yöneticileri içindir. Aşağıdaki tablolar her ekranın rotasını ve amacını listeler.

Genel yerleşim

• Üst bar: global arama, bildirimler, görev sayaçları, kiracı/birim göstergesi, hızlı yükleme.
• Sol nav: Aksiyon Merkezi, Belgeler, Capture, Arama, Görevlerim, Süreçler, Evrak, Arşiv, Raporlar, Yönetim.
• Sağ yardımcı panel: AI özet, kalite uyarıları, son aktiviteler, ilgili görevler.
• Tüm kritik ekranlarda loading, empty, error ve retry durumları tasarımın parçasıdır.

Kiracı kullanıcı ekranları

Kiracı içi yönetim ekranları

Platform yönetim ekranları (EBYS_Admin_App)

• S-A01 Admin Login · S-A02 Platform Dashboard (tenant sayısı, depolama, webhook hataları, queue sağlığı).
• S-A03 Tenant Yönetimi · S-A04 Plan ve Özellik Politikaları · S-A05 Global Belge Tipi Kataloğu.
• S-A06 İzin Kataloğu · S-A07 Sistem Varsayılanları · S-A08 Cross-Tenant Raporlar · S-A09 Platform Audit.
• S-A10 Entegrasyon ve Webhook Sağlığı · S-A11 Tenant Storage ve AI Sağlığı.

Anahtar ekranların fonksiyonel anlatımı

Aşağıdaki kartlar, en sık kullanılan ekranların amacını, üzerinde gerçekte bulunan başlıca işlevleri ve bağlandığı use case'i özetler. Liste/tablo ekranları ortak bir desen kullanır: filtre + arama çubuğu, sayfalı DataTable, durum rozetleri ve loading/empty/error/retry durumları.

Ekran işlemleri (dallanmalar)

Aşağıdaki tablo, her ekranda kullanıcının yapabileceği başlıca işlemleri ve dallanmaları (yeni ekleme, düzenleme, silme/iptal, senkronize/yenileme, durum geçişleri) özetler. Yönetim ekranları temel olarak liste + ekle/düzenle/sil (CRUD) deseni izler; ekrana özgü ek aksiyonlar ayrıca belirtilir.

Ekran → Servis → Backend eşleşmesi

Bu test seti yalnız mutlu akışları değil; tenant izolasyonu, feature policy, onboarding, capture dayanıklılığı, güvenli dış paylaşım, AI guardrail, outbox/webhook güvenilirliği ile erişilebilirlik ve operasyonel gözlemlenebilirliği kapsar. Senaryolar ürün analizi, mimari ve use case dokümanlarıyla hizalıdır.

Test tipleri

Tenant izolasyonu ve feature policy

Onboarding ve yönetim

Belge ekleme, capture ve kalite kapısı

Versiyon, viewer ve paylaşım

Arama, kayıtlı görünüm ve keşif

Workflow, görev ve delegasyon

Evrak, imza ve resmi akışlar

AI, özet, risk ve guardrail

Bildirim, workspace ve raporlama

Audit, güvenlik ve uyum

Outbox, webhook ve dayanıklılık

BYOS / BYAI entegrasyon testleri

Saklama, legal hold ve imha

Performans, operasyon ve erişilebilirlik

Çıkış kriterleri

• Tüm TC-TEN-* ve TC-SEC-* testleri yeşil.
• İlgili modülün E2E kritik akışları yeşil.
• Yeni event veya worker içeren işlerde TC-EVT-* ve TC-OPS-* kapsanmış.
• AI içeren işlerde citation, tenant isolation ve PII testleri yeşil.
• BYOS/BYAI içeren işlerde TC-BYO-* testleri yeşil.
• Kullanıcıya dönük yeni akışlarda en az temel A11Y kontrolleri yeşil.

Bu sözlük, dokümanlarda geçen alan, uyum, mimari ve AI terimlerinin ne anlama geldiğini açıklar. Amaç, ürün/yazılım/test ekiplerinin aynı kelimeyi aynı anlamda kullanmasıdır.

Uyum, arşiv ve resmi yazışma

Multi-tenant ve ürünleşme

Yetkilendirme ve güvenlik

Belge yaşam döngüsü, AI ve mimari

Aşağıda, EBYS’nin Laviya tabanından bağımsız bir belge yönetim ürününe dönüşümünü özetleyen sürüm geçmişi yer alır. Tarihler geliştirme dönemini yansıtır.

1. 2026-06-25

   Backend temeli (1:1 port)

   Laviya_BE temiz kaynaktan EBYS_BE’ye portlandı; tüm Laviya→Ebys yeniden adlandırması (805 dosya) yapıldı. Yeniden kullanılabilir altyapı: Tenant, kullanıcı/auth, Collaboration, Communication, Logging, Data.API/Service.

2. 2026-06-25

   DocumentHub domaini

   İlk tam dikey dilim: 13 entity, Data.API + Rest/RestFE controller’ları, DI wiring ve varsayılan belge tipi/gizlilik derecesi seed’i.

3. 2026-06-26

   Yeni domainler: Workflow, Records, Intelligence, IntegrationOps

   Dört net-new domain eklendi. Workflow süreç motoru, Records evrak akışı, Intelligence AI job/sonuç kabuğu ve IntegrationOps outbox/webhook altyapısı kuruldu.

4. 2026-06-26

   Entegrasyon katmanı ve şifreli sırlar

   9 bağımlılıksız entegrasyon arayüzü, Anthropic/Claude LLM ağ geçidi, HMAC imzalı webhook teslimi ve per-tenant şifreli IntegrationCredential/Secret saklama eklendi.

5. 2026-06-26

   Frontend temeli — EBYS_Site_App

   Next.js Pages Router iskeleti kuruldu; PM/collaboration kodu ayıklandı. App shell, Aksiyon Merkezi, login ve servis katmanı hazır.

6. 2026-06-26

   Belgeler dilimi + eksik ekranlar

   Belge listesi/viewer, ortak parçalar (DataTable, usePagedData, StatusBadge) ve S-09/S-11/S-12/S-17/S-19 ekranları tamamlandı; contextual admin menüsü eklendi.

7. 2026-06-27

   Collaboration uzantıları + admin uçtan uca

   OrganizationUnit, Delegation, SavedView, WorkspacePreference eklendi; RestFE CollaborationController genişletildi; yönetim ekranları gerçek uçlara bağlandı. Toast ve TenantSwitcher eklendi.

8. 2026-06-27

   EBYS_Admin_App + platform ekranları

   Laviya admin paneli portlandı, EBYS markasına uyarlandı, marketplace temizliği yapıldı ve eksik platform ekranları (S-A05/S-A10/S-A11) eklendi.

9. 2026-06-27

   Domain mantığı + AI job tipleri + concrete sağlayıcılar

   Workflow paralel/join, Records sıra kilidi (advisory-lock), AI job tipleri (Classification/Extraction/Risk/Qa/OCR), JobMethod orchestration ve 9 entegrasyon sağlayıcısının concrete implementasyonu eklendi.

Altın kural

• Hedef: EBYS_BE (ve EBYS_Site_App / EBYS_Admin_App). Namespace kökü Ebys.*, çözüm Ebys.sln.
• Kaynak: Laviya_BE — ASLA değiştirilmez, yalnızca referans/port kaynağıdır.
• Doğrulama: dotnet build Ebys.sln -c Debug → 0 hata.

Tamamlananlar

1. ✓

   Tüm backend domainleri

   DocumentHub, Workflow, Records, Intelligence ve IntegrationOps tam dikey dilim olarak tamamlandı (domain → Data.API → Rest/RestFE → DI → seed). Mimari §5.2’deki tüm net-new domainler kuruldu.

2. ✓

   Entegrasyon katmanı + default impl

   9 arayüz sözleşmesi, default implementasyonlar, DI bağlama ve HMAC imzalı webhook teslim akışı. Sırlar per-tenant şifreli; RestFE’de maskeleniyor.

3. ✓

   AI job akışları

   Summary, Classification, Extraction, RiskDetection, Qa ve OCR job tipleri ortak RunResultJob iskeleti üzerine kuruldu; JobMethod orchestration giriş noktaları bağlandı.

4. ✓

   Frontend (Site + Admin)

   EBYS_Site_App tüm S-01..S-33 ekranlarıyla build geçiyor. EBYS_Admin_App portlandı, EBYS’leştirildi ve platform admin kapsamı S-A01..S-A11 tamamlandı.

Henüz yapılmayanlar (önemli)

1. •

   EF migration üretimi

   Hiçbir domain için dotnet ef migrations add henüz çalıştırılmadı; DB’de tablolar oluşmaz. Index’ler HasSafeIndex ile idempotent; migration üretildiğinde safe generator devreye girecek.

2. •

   Job senaryolarının tamamlanması

   OCR/Index/AI/Webhook/UsageMeter/SLA akışlarının tümü JobMethod tabanlı yürütmeye bağlanmalı; ScheduledTaskManager’a Task olarak iliştirilmeli.

3. •

   Gerçek dış servis bağları

   Storage signed-url ucu, belge önizleme render bağı, e-imza/KEP/UETS/EYP gerçek entegrasyonları ve vektör store bağlantısı concrete sağlayıcı + job fazında bağlanacak.

4. •

   ApplicationClient seed (appKey)

   Site ve Admin uygulamaları için AppName bazlı ApplicationClient seed’i ve gerçek appKey gerekli (şu an placeholder).

5. •

   Collaboration temizliği (faz 2)

   PM (proje/görev yönetimi) nesnelerinin büyük kısmı silindi; çekirdek tenant + billing + storage + LLM kapsamında bırakıldı. Kademeli temizlik her adımda build ile doğrulanıyor.

Referans dokümanlar

• Mimari: EBYS_BE/AI_Context/01_Mimari.md (domain sınırları §5, entity listeleri §5.2).
• Use case / ekran / API: 02_UseCase_Analizleri.md, 03_Ekranlar.md, 04_Ekran_Fonksiyonlari_ve_API.md.
• Standartlar: backend_coding_standarts.md, frontend_coding_standarts.md.