CAN-DEC-ADR-008 — Privacy-Preserving Compounding Data Loop & Shadow-First Activation Architecture
Statü satırı:
governance_status = accepted· AS-IS TRUTH-SYNC: sistem39f1db0'da implemented,74679939'da deployed_verified, runtime activation = OFF. Bu kayıt geçmiş implementasyonu geriye dönük YETKİLENDİRMEZ (o dönem WINDOW-A dahil Human-CEO istisnası olarak ledger'da sınıflandırılmıştır); mevcut sistemi yeniden değerlendirir ve GELECEKTEKİ shadow/active kullanımını yönetir.
1. Karar sorusu
Platform, kullanıcı davranış sinyallerinden öğrenen bir compounding veri döngüsünü — gizliliği mekanik garantilerle koruyarak ve müşteri deneyimini etkilemeden — nasıl işletir ve bu döngünün AKTİVASYONU hangi mimariyle yönetilir?
2. Karar (bağlayıcı mimari)
K1 · Shadow-first aktivasyon mimarisi. Davranış-sinyali üretimi ile müşteri-etkisi ARASINA şema-seviyesi bir duvar konur: decision_patterns.activation_state AUTHORITATIVE alandır, is_active legacy projeksiyondur; bu fazda DB CHECK tek-kolludur (shadow AND is_active=false) — aktivasyon kolu şemada HİÇ AÇILMAMIŞTIR. Terfi = yeni Canon kararı + ayrı migration + ayrı yetki kapısı.
K2 · Koşum-defteri (run-ledger) otoritesi. Her zamanlanmış invocation, üretimden ÖNCE pattern_mining_runs'a iz bırakır (TX-1 pending); her koşum adlandırılmış terminal duruma ulaşır (completed/skipped/failed + ayrık skip_reason ⊥ error_code sözlükleri; adsız terminal DB-CHECK ile yasak). FAILED RUN HAS LEDGER EVIDENCE + FAILED RUN HAS NO PARTIAL PATTERNS.
K3 · Eşzamanlılık: pending→lock→running arbitrasyonu. Kilit sahipliği = canlı yürütme yetkisi; running etiketi tek başına yetki DEĞİLDİR. Kilidi kazanan sahipsiz running'i orphaned_running_run ile terminalize eder ve yürütmeye devam eder ⇒ her (job_type, period_start, period_end) için EN FAZLA BİR canlı üretici; arbitration bütün contender'ların kendini skip etmesine YOL AÇAMAZ. Adlandırılmış bağımsız bir hata nedeniyle completed-üretici sıfır olabilir — o durumda failed ledger kanıtı zorunludur (ZERO PRODUCER CAUSED BY SELF-SKIP RACE = FORBIDDEN · ZERO COMPLETED OUTPUT WITH NAMED FAILURE = POSSIBLE; CAN-REQ-RULE-025/INV-5).
K4 · Gizlilik mekaniği — İKİ HAT AYRIDIR. repeat_search_proxy hattı: ham sorgu metni yerine HMAC-SHA256 takma-adı (özel COMPOUNDING_QUERY_HASH_KEY; APP_KEY yasak; anahtar-yok + mode-shadow = adlandırılmış fail-closed; HMAC PSEUDONYMIZATION ≠ ANONYMIZATION) + k≥5 distinct-kullanıcı + ≥2 distinct-tenant tabanları sınıf-sabiti (env ile indirilemez) + düşük-k kalıcılığı yasak. cohort_aggregation hattı: AYRI cohort_sample_floor — HACİM/anlamlılık tabanıdır, k-anonimlik kanıtı DEĞİLDİR. Reddedilenler yalnız toplam SAYAÇ olarak yaşar (privacy_rejections ⊥ numeric_rejections ⊥ gate_rejections). Exact-key closure: payload'larda izinli-küme dışı anahtar = ihlal.
K5 · Mode-otoritesi. COMPOUNDING_MINING_MODE tek yürütme-otoritesidir: off (default) → iz bırakıp üretmez · shadow → K1-K4 altında üretir · active → bu ADR kapsamında YETKİSİZ (aktivasyon-sözleşmesi implementasyonu yoktur; fail-closed) · tanınmayan → fail-closed. Sayısal eşikler karar vermez, ÖLÇÜLÜR (meets_numeric_thresholds + activation_blockers dürüstlük beyanı).
K6 · Runtime-config yürürlük ilkesi (KALICI) + güncel köprü (RUNBOOK). Kalıcı mimari ilke: CONFIG WRITTEN ≠ RUNTIME CONFIG EFFECTIVE — bir runtime-config değişikliği, çalışan release'e AKTARIM KÖPRÜSÜ tamamlanmadan ve RUNTIME PROBE ile doğrulanmadan effective SAYILMAZ. Acil müdahale iki ayrı mekanizmadır: IMMEDIATE CONTAINMENT (yürütmeyi durdurur) ≠ DURABLE ROLLBACK (config-geri-alma + köprü + probe). Güncel implementasyon notu: mevcut Forge altyapısında aktarım köprüsü SAME-SHA REDEPLOY'dur (horizon:terminate containment değildir); exact komut dizisi ve zamanlama shadow-run paketi v1.2'nin otoritesindedir (ADR = KALICI MİMARİ İLKE · RUNBOOK = GÜNCEL OPERASYON MEKANİZMASI).
3. Karar VERMEDİKLERİ
Aktivasyon/terfi mekaniği (ayrı ADR gerektirir) · okuyucu-sözleşmesi ve gerçek-davranış-sinyali bağlama (aktivasyon ön-koşulu, ayrı karar) · cohort hattının k-anonimlik iddiası (cohort_sample_floor = hacim tabanıdır, k-anonimlik kanıtı DEĞİLDİR) · veri-hacmi stratejisi (12-kullanıcı gerçeğinin büyütülmesi ayrı şerit).
4. Yürürlük kapıları (DRAFT → PROPOSED → ACCEPTED → EFFECTIVE)
SIRA (AI-CEO lifecycle hükmü): önce CAN-REQ-UCG-014 + CAN-REQ-RULE-025 proposed→accepted (Human CEO) → SONRA bu ADR draft→proposed → Human CEO ADR kabulü → operasyonel dry-run kapıları → effective değerlendirmesi. ACCEPTED yetkisi: Human CEO approval — AI-CEO risk/consistency review ve Verify evidence review SONRASINDA (AI-CEO REVIEW ≠ ACCEPTANCE AUTHORITY · VERIFY EVIDENCE ≠ ACCEPTANCE AUTHORITY). EFFECTIVE ön-koşulları: requirements accepted + shadow-run paketi v1.2 registered + WINDOW-B/containment/durable-rollback dry-run PASS. PROPOSED ≠ ACCEPTED ≠ EFFECTIVE ≠ IMPLEMENTATION-AUTHORIZED — implementasyon zaten mevcut ve deployed; bu zincir onu YENİDEN yetkilendirmez, GELECEK kullanımını yönetir.