Humindx Docs

Appearance

Bağlam Odaları ve Veri İzolasyonu (Context Rooms Design) ​

Bu doküman, Humindx'in "Bölümlenmiş Genom" (Compartmentalized Genome) modelinin veri katmanında (Database) nasıl modellendiğini ve Bağlam Odaları arasındaki Veri Sızdırmazlık Duvarları'nın (Privacy Firewalls) teknik implementasyonunu açıklar.

Kapsam Uyarısı: Bu doküman, PostgreSQL şema tasarımını ve izolasyon politikalarını kapsar. Değişikliklerin tarihsel kaydı için ../security/audit-trail.md dosyasına, vektörel dönüşümler için ../security/vector-privacy.md dosyasına bakınız.

1. Temel Problem ve Çözüm Yaklaşımı ​

Geleneksel psikometrik veya profil sistemleri user_traits gibi tek bir tablo kullanır ve skorları bu tablo üzerinde günceller. Humindx'te ise bir kullanıcının "Dışadönüklük" (Extraversion) skoru; evde (Sosyal), işte (Profesyonel) veya terapi seansında (Klinik) farklı değerler alabilir.

Çözüm: Veriyi, ait olduğu bağlam ile etiketleyip, PostgreSQL'in Row-Level Security (RLS) mekanizmasını kullanarak donanımsal olmasa da mantıksal düzeyde aşılmaz duvarlar (Firewalls) inşa etmektir.

2. Veri Modeli ve Şema Tasarımı ​

Sistemde skorlar tek bir statik değer değil, odalara bölünmüş bir yapıdadır.

2.1. Temel Tablolar (ER Modeli) ​

2.2. Oda Tipleri (Room Types) ENUM ​

  • PROFESSIONAL: B2B Uyum skorunun tek kaynağıdır.
  • SOCIAL: Sadece B2C arayüzünde yaşar. (RLS ile B2B'den tamamen gizlenir).
  • CLINICAL: Şifrelenmiş odadır. Sadece klinik yetkisi (Dr.) olan roller okuyabilir.
  • DISCOVERY: Etkileşimlerin toplandığı ham odadır. Alt etiketler ([PRO], [SOCIAL], [NEUTRAL]) içerir.

[AÇIK SORU]: CLINICAL odanın şifreleme stratejisi (column-level pgcrypto vs. application-level encryption) henüz belirlenmedi. Bu karar, uzman panelinin sorgu ihtiyaçlarına göre guides/architecture-decisions/ altında bir ADR ile netleştirilecektir.

3. Privacy Firewall: Row-Level Security (RLS) İmplementasyonu ​

Veri Sızdırmazlık Duvarı, uygulama koduna (Backend API) güvenmez. Çünkü kodda unutulacak bir WHERE room_type != 'SOCIAL' filtresi, büyük bir gizlilik ihlaline (EU AI Act ihlali) yol açabilir. Sızdırmazlık, veritabanı motoru seviyesinde kilitlenir.

3.1. RLS Politika Örneği (PostgreSQL) ​

B2B Gateway veritabanına bağlandığında, özel bir veritabanı rolü (b2b_gateway_role) kullanır. Bu role uygulanan RLS politikası şu şekildedir:

sql
-- 1. RLS'yi Aktif Et
ALTER TABLE trait_scores ENABLE ROW LEVEL SECURITY;

-- 2. B2B Servisi için sadece PROFESSIONAL odalara erişim politikası
CREATE POLICY b2b_isolation_policy ON trait_scores
FOR SELECT
TO b2b_gateway_role
USING (
    room_id IN (
        SELECT id FROM context_rooms 
        WHERE user_id = current_setting('request.jwt.claim.sub')::uuid 
        AND room_type = 'PROFESSIONAL'
    )
);

Sonuç: Bir İK Yöneticisi B2B panelinden API isteği yaptığında, Backend kodunda filtreleme unutulsa dahi, PostgreSQL motoru SOCIAL veya CLINICAL veriyi hiç yokmuş gibi (0 satır) döndürür.

4. Keşif Odası ve Anchor Hesaplaması (Discovery Room) ​

Kullanıcı Sisli Sohbetler yaptığında veri DISCOVERY odasına akar. Bu odanın PROFESSIONAL odayı nasıl etkilediği özel bir "Anchor" (Çapa) mantığıyla çalışır.

Mantık: ​

  1. Senaryo bittiğinde bir olay (Event) oluşur: SCENARIO_COMPLETED.
  2. Olayın etiketi [SOCIAL] ise, hesaplanan özellik skorları sadece Discovery ve Social odalarını besler.
  3. Olayın etiketi [PRO] veya [NEUTRAL] ise, hesaplanan özellik skorları Discovery'i beslerken, aynı zamanda Professional odasındaki skoru da (belirli bir ağırlıkta) günceller.

Anchor ağırlık katsayıları ve hesaplama formülleri için bkz. ../psychometrics/scoring-algorithms.md

Teknik Not: Bu güncelleme asenkron çalışır ve Event-Bus (Kafka) üzerindeki tüketiciler (Consumers) tarafından dağıtılır.

5. Pozitif Transfer Köprüsü (The Bridge) ​

Bağlam Odaları arası otomatik geçiş yasaktır. Ancak kullanıcı, Sosyal odasında parlayan bir yetkinliğini Profesyonel odasına taşımak isteyebilir. Bu, Pozitif Transfer Köprüsü (Positive Transfer Bridge) adlı bir state-machine (durum makinesi) işlemiyle yapılır.

İşlem Akışı: ​

  1. Kullanıcı Mobilden "Bu özelliğimi (Empati) Profesyonel Profilime Ekle" der.
  2. Backend, trait_scores tablosunda PROFESSIONAL odaya yeni bir kayıt oluşturur veya mevcut kaydı günceller.
  3. Bu yeni kaydın metadata JSON alanına bir damga (stamp) vurulur:
    json
    {
  "transferred_from": "SOCIAL",
  "transfer_timestamp": "2026-04-15T10:00:00Z",
  "original_confidence": 0.85
}
  4. Veri Tutarlılık Puanı Etkisi: B2B tarafında bu özellik görüntülendiğinde, sistem İK uzmanına bu skorun doğal iş simülasyonlarından değil, kullanıcının "sosyal profilinden kendi beyanıyla transfer edildiğini" Audit Trail üzerinden raporlar.

Yön Kısıtı: Transfer yalnızca SOCIAL/DISCOVERY → PROFESSIONAL yönünde çalışır. Bu kısıt, Backend API'de uygulama seviyesinde enforce edilir ve her transfer işlemi Audit Trail'de loglanır.

6. Performans Optimizasyonu (Materialized Views) ​

Her anket/sohbet bir olaydır (Event). Orijinal skorlar binlerce satırlık event log'larından toplanarak (aggregate edilerek) hesaplanır. B2C uygulaması açıldığında bu toplamayı anlık yapmak yavaştır.

Bu yüzden trait_scores tablosu aslında bir Materialized State'dir (Gerçekleşmiş Durum).

  • Event Bus'a yeni bir skor değişimi düştüğünde, arka plan işçisi (Cold Path Worker) yeni skoru hesaplar.
  • Odaya ait current_score değerini RDBMS üzerinde günceller (Upsert).
  • Mobil uygulama okuma yaparken hiçbir hesaplama yapmaz, direkt O(1) hızında mevcut durumu çeker.

Son Güncelleme: 2026-04-15 — RLS politikaları, ER modeli, Pozitif Transfer Köprüsü ve CLINICAL şifreleme açık sorusu tanımlandı.

Simetri tarafından inşa ediliyor.