Kuyruklar, roller, politika uygulama, yükseltmeler, denetim günlükleri, analitik ve güvenli entegrasyonlar dahil olmak üzere içerik moderasyonu için bir web uygulaması nasıl tasarlanıp inşa edilir öğrenin.
Bir moderasyon iş akışı tasarlamadan önce, aslında neyi denetlediğinize ve “iyi”nin ne olduğuna karar verin. Net bir kapsam, moderasyon kuyruğunuzun uç durumlar, tekrarlar ve oraya ait olmayan isteklerle dolmasını önler.
Risk veya kullanıcı zararına yol açabilecek her içerik türünü yazın. Yaygın örnekler: kullanıcı tarafından oluşturulan metin (yorumlar, gönderiler, değerlendirmeler), resimler, video, canlı yayınlar, profil alanları (isimler, biyolar, avatarlar), özel mesajlar, topluluk grupları ve pazar ilanları (başlıklar, açıklamalar, fotoğraflar, fiyatlandırma).
Ayrıca kaynakları not edin: kullanıcı gönderimleri, otomatik içe aktarmalar, mevcut öğelerin düzenlenmesi ve diğer kullanıcıların raporları. Bu, yalnızca “yeni gönderiler” için çalışan fakat düzenlemeleri, yeniden yüklemeleri veya DM istismarını kaçıran bir sistem kurmayı engeller.
Çoğu ekip dört hedefi dengeler:
Her alanda hangi hedefin birincil olduğunu açıkça belirtin. Örneğin, yüksek şiddetli kötüye kullanım hızı tutarlılığın önüne koyabilir.
Ürününüzün gerektirdiği tüm sonuçları listeleyin: onayla, reddet/kaldır, düzenle/kırp, etiketle/yaş sınırlaması uygula, görünürlüğü kısıtla, inceleme altında bırak, liderine yükselt, ve uyarılar, geçici kilitler veya yasaklar gibi hesap düzeyinde işlemler.
Ölçülebilir hedefler tanımlayın: ortanca ve yüzde 95’lik inceleme süresi, bekleyen iş sayısı, itirazlarda geri döndürme oranı, QA örnekleminden politika doğruluğu ve SLA içinde ele alınan yüksek şiddetli öğelerin yüzdesi.
Moderasyoncuları, ekip liderlerini, politika ekibini, destek, mühendislik ve hukuku dahil edin. Buradaki uyumsuzluk, özellikle “yükseltme”nin ne anlama geldiği ve nihai kararların kimde olduğu konusunda, sonradan yeniden işe yol açar.
Ekranlar ve kuyruklar oluşturmadan önce, tek bir içerik parçasının tüm yaşam döngüsünü taslağını çıkarın. Net bir iş akışı, inceleyicileri şaşırtan “gizemli durumları”, bildirimleri bozan akışları ve denetimleri zorlaştıran durumları önler.
Başlangıç olarak diyagramda ve veritabanınızda tutabileceğiniz basit, uçtan uca bir durum modeli oluşturun:
Submitted → Queued → In review → Decided → Notified → Archived
Durumları birbirini dışlayacak şekilde tutun ve hangi geçişlerin kim tarafından yapılabileceğini tanımlayın. Örneğin: “Queued” yalnızca atandığında “In review”e geçebilmeli ve “Decided” itiraz akışı dışında değiştirilemez olmalıdır.
Otomatik sınıflandırıcılar, anahtar kelime eşleşmeleri, hız sınırlamaları ve kullanıcı raporları sinyal olarak ele alınmalıdır; karar olarak değil. “İnsan‑arayüzlü” tasarım sistemi dürüst tutar:
Bu ayrım, politika mantığını yeniden yazmadan modelleri ileride geliştirmenizi de kolaylaştırır.
Kararlar itiraz edilecektir. Birinci sınıf akışlar ekleyin:
İtirazları geçmişi düzenlemek yerine yeni inceleme olayları olarak modelleyin. Böylece baştan neler olduğunu tam olarak anlatabilirsiniz.
Denetimler ve uyuşmazlıklar için hangi adımların zaman damgaları ve aktörlerle kaydedilmesi gerektiğini tanımlayın:
Sonradan bir kararı açıklayamıyorsanız, o kararın verilmediğini varsayın.
Bir moderasyon aracı erişim kontrolüne dayanır. Herkes her şeyi yapabiliyorsa, tutarsız kararlar, yanlışlıkla veri sızıntıları ve net hesap verebilirliğin olmaması gibi sorunlar yaşarsınız. Güven ve emniyet ekibinizin gerçekte nasıl çalıştığına uyan roller tanımlayarak başlayın, sonra bunları uygulayabilecek izinlere çevirin.
Çoğu ekip için küçük ve net bir rol seti yeterlidir:
Bu ayrım “politikaların kazara değişmesini” önlemeye yardımcı olur ve politika yönetimini günlük uygulamadan ayırır.
Her rolun sadece ihtiyaç duyduğu erişime sahip olması için rol tabanlı erişim kontrolü uygulayın:
can_apply_outcome, can_override, can_export_data).Yeni özellikler (dışarı aktarmalar, otomasyonlar, üçüncü taraf entegrasyonları) eklediğinizde, bunları izinlere bağlayarak tüm organizasyon yapısını yeniden tanımlamaktan kaçınabilirsiniz.
Erken dönemde çoklu ekipleri planlayın: dil pod’ları, bölge bazlı gruplar veya farklı ürün hatları. Ekipleri açıkça modelleyin, sonra kuyrukları, içerik görünürlüğünü ve atamaları ekiplere göre sınırlandırın. Bu, bölge karışıklıklarını önler ve iş yükünü ekipler bazında ölçülebilir kılar.
Yöneticiler bazen erişimi debug etmek veya bir inceleyici sorununu yeniden üretmek için taklit etme yapmalıdır. Taklit etmeyi hassas bir işlem olarak ele alın:
Geri döndürülemez veya yüksek riskli eylemler için yönetici onayı (veya iki kişilik onay) ekleyin. Bu küçük sürtünme, hatalara ve insider kötüye kullanıma karşı koruma sağlar, rutin moderasyonu ise hızlı tutar.
Kuyruklar moderasyon işini yönetilebilir kılar. Tek bir sonsuz listeden ziyade, işi risk, aciliyet ve niyete göre bölün—ve öğelerin gözden kaybolmasını zorlaştırın.
Ekiplerin gerçekte nasıl çalıştığına uyan küçük bir kuyruk setiyle başlayın:
Mümkün olduğunda kuyrukları birbirini dışlar şekilde tutun (bir öğenin bir “evi” olsun) ve ikincil özellikler için etiketler kullanın.
Her kuyruğun içinde üst sıralara çıkmayı belirleyen puanlama kuralları tanımlayın:
Sıralamanın kullanıcı arayüzünde açıklanabilir olmasını sağlayın (“Bunu neden görüyorum?”) ki inceleyiciler sıralamaya güvensinler.
Claim/locking kullanın: bir inceleyici öğeyi açtığında, ona atanır ve diğerlerinden gizlenir. Bir zaman aşımı ekleyin (ör. 10–20 dakika) ki terk edilen öğeler kuyruğa geri dönsün. Claim, release ve completion olaylarını her zaman kaydedin.
Sistem hız ödüllüyorsa, inceleyiciler hızlı vakaları seçip zor olanları atlayabilir. Bunu önlemek için:
Amaç tutarlı kapsama sağlamaktır, sadece yüksek verim değil.
Sadece PDF halinde olan bir moderasyon politikası her inceleyici tarafından farklı yorumlanır. Kararları tutarlı (ve denetlenebilir) kılmak için politika metnini yapılandırılmış verilere ve UI seçimlerine çevirin.
İnceleyicilerin seçebileceği ortak bir sözlükle politikayı parçalara ayırın. Yararlı bir taksonomi genelde şunları içerir:
Bu taksonomi daha sonra kuyruklar, yükseltme ve analitik temelini oluşturur.
İnceleyicilere her seferinde sıfırdan karar yazdırmak yerine, taksonomi öğelerine bağlı karar şablonları sağlayın. Bir şablon şunları doldurabilir:
Şablonlar “mutlu yolu” hızlı yapar, yine de istisnalara izin verir.
Politikalar değişir. Politikaları sürümlü kayıtlar olarak saklayın ve etkinlik tarihlerini tutun; her karar için hangi sürümün uygulandığını kaydedin. Bu, eski davalar itiraz edildiğinde karışıklığı engeller ve aylar sonra sonuçları açıklamanızı sağlar.
Serbest metin analiz için zordur ve unutulmaya eğilimlidir. İnceleyicilerin bir veya daha fazla yapılandırılmış neden seçmesini zorunlu kılın (taksonomiden) ve isteğe bağlı not eklemeye izin verin. Yapılandırılmış nedenler itiraz yönetimini, QA örneklemesini ve trend raporlamayı kolaylaştırır—inceleyicilere uzun yazılar yazdırmadan.
İyi bir inceleyici panosu, bilgiyi aramayı en aza indirip, güvenli ve tekrarlanabilir kararları maksimize ettiğinde başarılıdır. İnceleyiciler ne olduğunu, neden önemli olduğunu ve bir sonraki adımı UI’dan çıkarabilmelidir—beş sekme açmaya gerek kalmadan.
İzol edilmiş bir gönderi gösterip tutarlı sonuçlar beklemeyin. Kısa bir bağlam paneli sunun ki inceleyicinin sıkça sorulan sorulara hızlıca cevap bulmasını sağlayın:
Varsayılan görünümü özlü tutun; derinlemesine bakış için genişletme seçenekleri verin. İnceleyicilerin karar vermek için nadiren pano dışına çıkması gerekmeli.
Eylem çubuğunuz politika sonuçlarına uymalı, genel CRUD düğmelerine değil. Yaygın kalıplar:
Görünür eylemler ve geri döndürülemez adımlarda açık/kanıtlı onay gösterin. Denetimler için kısa bir neden kodu ve isteğe bağlı not yakalayın.
Yüksek hacimli işler düşük sürtünüm ister. En yaygın eylemler için (onayla, reddet, sonraki öğe, etiket ekle) klavye kısayolları ekleyin. UI içinde kısa bir kısayol yardım penceresi gösterin.
Açık spam gibi tekrarlayan işlerde toplu seçim desteği verin ama korumalarla: önizleme sayısı göster, bir neden kodu zorunlu kıl ve toplu işlemi logla.
Moderasyon insanları zararlı materyale maruz bırakabilir. Güvenlik varsayılanları ekleyin:
Bu tercihler kararların doğru ve tutarlı kalmasını sağlarken inceleyicileri korur.
Denetim günlükleri, biri sorduğunda “Bu gönderi neden kaldırıldı? İtirazı kim onayladı? Model mi yoksa insan mı son kararı verdi?” sorularına cevap verir. İzlenebilirlik yoksa, soruşturmalar tahmine dönüşür ve inceleyici güveni hızla düşer.
Her moderasyon eylemi için kim yaptığı, neyi değiştirdiği, ne zaman gerçekleştiği ve neden (politika nedeni + serbest metin notu) kaydedin. Aynı derecede önemli: ilgili nesnelerin önce/sonra snapshot’larını saklayın—içerik metni, medya hash’leri, algılanan sinyaller, etiketler ve nihai sonuç gibi. Öğe değişebiliyorsa (düzenlemeler, silinmeler), snapshot’lar kaydın bozulmasını engeller.
Pratik bir desen olarak eklenebilir (append‑only) olay kayıtları kullanın:
{
"event": "DECISION_APPLIED",
"actor_id": "u_4821",
"subject_id": "post_99102",
"queue": "hate_speech",
"decision": "remove",
"policy_code": "HS.2",
"reason": "slur used as insult",
"before": {"status": "pending"},
"after": {"status": "removed"},
"created_at": "2025-12-26T10:14:22Z"
}
(Kod bloğu içeriği çevrilmeden korunmalıdır.)
Kararlardan öte, iş akışı mekaniğini de loglayın: claimed, released, timed out, reassigned, escalated ve auto‑routed gibi. Bu olaylar “neden 6 saat sürdü” veya “neden öğe ekipler arasında dolaştı” sorularını açıklar ve inceleyicilerin kolay vakalar seçmesi gibi kötüye kullanım tespitleri için şarttır.
Araştırmacılara actor, içerik ID, politika kodu, zaman aralığı, kuyruk ve eylem türüne göre filtreleme verin. Bir vaka dosyasına dışa aktarım ekleyin; değiştirilemez zaman damgaları ve ilgili öğelere (çoğaltmalar, yeniden yüklemeler, itirazlar) referanslar ekleyin.
Denetim olayları, snapshot’lar ve inceleyici notları için açık saklama pencereleri belirleyin. Politikayı belgeleyin (ör. rutin kuyruk günlükleri için 90 gün, yasal tutuklamalar için daha uzun) ve silme/redaksiyon taleplerinin saklanan kanıtlara etkisini açıklayın.
Bir moderasyon aracı, raporların inceleme görevine dönüşmesi, kararların ilgili kişilere ulaşması ve kullanıcı düzeyindeki eylemlerin tutarlı şekilde yürütülmesi durumunda işe yarar. Pek çok sistem burada kopar—kuyruk temizlenir ama başka hiçbir şey değişmez.
Kullanıcı raporları, otomatik bayraklar (spam/CSAM/hash eşleşmeleri/toksisite sinyalleri) ve dahili yükseltmeler (destek, topluluk yöneticileri, hukuk) aynı temel nesne olarak ele alınmalı: bir rapor ve bir veya daha fazla inceleme görevi oluşturabilen.
Tek bir rapor yönlendiricisi kullanın:
Eğer destek yükseltmeleri akışın bir parçasıysa, bunları doğrudan ilişkilendirin (ör. /support/tickets/1234) ki inceleyiciler bağlam değiştirmek zorunda kalmasın.
Moderasyon kararları için şablonlu bildirimler üretin: içerik kaldırıldı, uyarı verildi, işlem yok veya hesap eylemi yapıldı. Mesajlaşmayı tutarlı ve minimal tutun—sonucu açıklayın, ilgili politikaya atıf yapın ve itiraz talimatı verin.
Operasyonel olarak, moderation.decision.finalized gibi bir olay gönderin ki e‑posta/in‑app/push aboneleri yavaşlatmadan dinleyebilsin.
Kararlar genellikle tek bir içerikten öte işlemler gerektirir:
Bu eylemleri açık ve geri döndürülebilir yapın; net süreler ve nedenler ekleyin. Her eylemi karara ve temel rapora bağlayın ve itirazlara hızlı bir yol sağlayın ki kararlar kolayca yeniden değerlendirilebilsin.
Veri modeliniz, her öğede ne olduğunun kaynağıdır: ne incelendi, kim tarafından, hangi politika ile ve sonuç neydi. Bu katmanı doğru kurarsanız, kuyruklar, panolar, denetimler ve analitik daha kolay olur.
Her şeyi tek bir kayıtta tutmaktan kaçının. Pratik bir desen:
HARASSMENT.H1, NUDITY.N3) referans olarak saklanmalı ki politikalar evrildiğinde geçmiş yazılmasınBu, politika uygulamasını tutarlı kılar ve haftalık “en çok ihlal edilen politika kodları” gibi raporlamayı netleştirir.
Büyük resimleri/videoları doğrudan veritabanına koymayın. Nesne depolama kullanın ve içerik tablosunda sadece nesne anahtarları + meta saklayın.
İnceleyiciler için kısa süreli imzalı URL’ler (signed URLs) üretin ki medya herkese açık olmadan erişilebilsin. İmzalı URL’ler süresi dolmayı ve gerektiğinde erişimi iptal etmeyi sağlar.
Kuyruklar ve soruşturmalar hızlı arama gerektirir. Aşağı için indeksler ekleyin:
Moderasyonu açık durumlar şeklinde modelleyin (ör. NEW → TRIAGED → IN_REVIEW → DECIDED → APPEALED). Durum geçiş olaylarını (zaman damgası ve aktör ile) saklayın ki ilerlemeyen öğeleri tespit edebilin.
Basit bir koruma: last_state_change_at alanı ve SLA’yı geçen öğeler için uyarılar; ayrıca IN_REVIEWde uzun süre kalanları yeniden kuyruğa atan bir onarım işi.
Trust & Safety araçları genellikle ürününüzün en hassas verilerini tutar: kullanıcı içerikleri, raporlar, hesap tanımlayıcıları ve bazen yasal talepler. Moderasyon uygulamasını yüksek riskli bir sistem olarak ele alın ve baştan güvenlik ile gizliliği tasarlayın.
Güçlü kimlik doğrulama ve sıkı oturum kontrolleriyle başlayın. Çoğu ekip için bu şunları içerir:
Bunu rol tabanlı erişim kontrolü ile eşleştirin; inceleyiciler sadece ihtiyaç duydukları şeyi görsün (ör. tek bir kuyruk, tek bir bölge veya tek bir içerik türü).
Veriyi hem taşıma sırasında (HTTPS her yerde) hem de dinlenmede (veritabanı/depolama şifrelemesi) şifreleyin. Sonra maruziyeti azaltmaya odaklanın:
Onay veya özel veri kategorilerini işliyorsanız, bu bayrakları inceleyicilere gösterin ve UI’da uygulanan kuralları zorunlu kılın (ör. kısıtlı görüntüleme veya saklama kuralları).
Raporlama ve itiraz uç noktaları spam ve taciz için bir hedeftir. Şunları ekleyin:
Son olarak, her hassas eylemi denetlenebilir yapın (bkz. /blog/audit-logs) ki inceleyici hataları, ele geçirilmiş hesaplar veya koordineli kötüye kullanım soruşturulabilsin.
Bir moderasyon iş akışı ancak ölçülürse iyileşir. Analitikler, kuyruk tasarımınızın, yükseltme kurallarınızın ve politika uygulamanızın tutarlı kararlar ürettiğini söylemeli—inceleyicileri yıpratmadan veya zararlı içeriğin beklemesine neden olmadan.
Sonuca bağlı küçük bir metrik setiyle başlayın:
Bunları bir SLA panosunda gösterin ki operasyon liderleri hangi kuyrukların geride kaldığını ve darboğazın işe alım mı, belirsiz kurallar mı yoksa rapor patlaması mı olduğunu görebilsin.
Uyuşmazlık her zaman kötü değildir—uç durumları işaret edebilir. Şunları takip edin:
Denetim günlüğünüzü her örneklenen kararı inceleyici, uygulanan kural ve kanıt ile ilişkilendirecek şekilde kullanın. Bu, inceleyicileri koçlukta ve pano UI’sinin insanları tutarsız kararlara itip itmediğini değerlendirirken açıklanabilirlik sağlar.
Analitikler size “politikamızın iyi kapsamadığı ne görüyoruz?” sorusunu cevaplamalı. Şu tür kümeleri arayın:
Bu sinyalleri somut eylemlere dönüştürün: politika örneklerini yeniden yazın, inceleyici panosuna karar ağaçları ekleyin veya uygulama önayarlarını güncelleyin (ör. varsayılan süreli cezalar vs. uyarılar).
Analitiği insan‑arayüzlü bir sistemin parçası olarak ele alın. Ekip içi kuyruk düzeyinde performansı paylaşın, ancak bireysel metrikleri dikkatle yönetin ki hızı kaliteye tercih eden teşvikler oluşmasın. Nicel KPI’ları düzenli kalibrasyon oturumları ve küçük, sık politika güncellemeleriyle eşleştirin—böylece araçlar ve insanlar birlikte gelişir.
Bir moderasyon aracı en çok uç durumlarda başarısız olur: garip gönderiler, nadir yükseltme yolları ve birden fazla kişinin aynı vakaya dokunduğu anlar. Test ve yayına alma sürecini ürünün bir parçası olarak görün, son bir onay kutusu değil.
Küçük bir “senaryo paketi” oluşturun, gerçek işi yansıtsın. İçeriğe şunları dahil edin:
Staging ortamında üretime benzer veri hacimleri kullanın ki kuyruk yavaşlamaları ve sayfalama/arama sorunlarını erken görün.
Daha güvenli bir yayına alma deseni şudur:
Shadow modu, otomasyon veya politika uygulamalarını gerçek kullanıcı etkisi olmadan doğrulamak için özellikle faydalıdır.
Kısa, görev tabanlı oyun kitapları yazın: “Bir raporu nasıl işlersiniz”, “Ne zaman yükseltirsiniz”, “İtirazları nasıl ele alırsınız” ve “Sistem belirsizse ne yapmalı”. Sonra aynı senaryo paketiyle eğitin ki inceleyiciler tam olarak kullanacakları akışları pratik yapsın.
Bakımın sürekli bir iş olduğunu planlayın: yeni içerik türleri, güncellenen yükseltme kuralları, periyodik QA örneklemeleri ve kuyruk patlamalarında kapasite planlama. Politika güncellemeleri için net bir sürüm süreci tutun ki inceleyiciler neyin, ne zaman değiştiğini görsün ve değişikliklerin moderasyon analitiklerine etkisini korrele edebilesiniz.
Bunu bir web uygulaması olarak uyguluyorsanız, çaba büyük ölçüde tekrarlayan altyapıda olur: RBAC, kuyruklar, durum geçişleri, denetim günlükleri, panolar ve kararlar ile bildirimler arasındaki olay tabanlı yapıştırıcı. Koder.ai, moderasyon iş akışını sohbet arayüzünde tanımlamanıza ve yineleyebileceğiniz çalışan bir temel üretmenize yardımcı olarak bu inşa sürecini hızlandırabilir—genelde React ön yüzü ve Go + PostgreSQL arka uç ile.
Trust & Safety araçları için iki pratik kullanım yolu:
Temel yerleştikten sonra kaynak kodunu dışa aktarabilir, mevcut model sinyallerinizi “girdi” olarak bağlayabilir ve inceleyicinin kararını nihai yetki olarak tutmaya devam edebilirsiniz—insan‑arayüzlü mimariyle uyumlu şekilde.
Her ele alınacak içerik türünü listeleyerek başlayın (gönderiler, yorumlar, DM’ler, profiller, ilanlar, medya) ve ayrıca tüm kaynakları belirtin (yeni gönderimler, düzenlemeler, içe aktarmalar, kullanıcı raporları, otomatik bayraklar). Ardından nelerin hariç olduğunu tanımlayın (ör. dahili yönetici notları, sistem tarafından üretilen içerik), böylece kuyruğunuz çöplük haline gelmez.
Pratik bir kontrol: içerik türünü, kaynağını ve sorumlu ekip adını söyleyemiyorsanız, muhtemelen henüz moderasyon görevi yaratmamalısınız.
Hem hızı hem de kaliteyi yansıtan az sayıda operasyonel KPI seçin:
Kuyruk başına hedefler belirleyin (ör. yüksek risk vs. backlog) ki düşük öncelikli işlere odaklanıp zararlı içeriklerin beklemesine neden olmayın.
Basit, açık bir durum modeli kullanın ve izin verilen geçişleri uygulayın, örneğin:
SUBMITTED → QUEUED → IN_REVIEW → DECIDED → NOTIFIED → ARCHIVEDDurumları birbirini dışlar şekilde tutun ve “Decided”i sadece itiraz/yeniden inceleme akışıyla tersine çevrilebilir kabul edin. Bu, “gizemli durumları”, kırık bildirimleri ve denetimi zorlaştıran düzenlemeleri önler.
Otomatik sistemleri sinyal olarak ele alın, nihai karar verme yetkisi insanda kalsın:
Bu yaklaşım politikayı açıklanabilir tutar ve modelleri geliştirmeyi karar mantığını yeniden yazmadan kolaylaştırır.
İtirazları orijinal karara bağlı birinci sınıf nesneler olarak oluşturun:
Küçük ve net bir RBAC seti ile başlayın:
Açık bir “ev sahibi” sahipliğine uygun birden fazla kuyruk kullanın:
Bir kuyruktaki önceliklendirmeyi ciddiye alarak açıklanabilir sinyallerle yapın: şiddet, erişim/viralite, benzersiz raporlayan sayısı ve SLA zamanlayıcıları. Kullanıcı arayüzünde “” gösterin ki sıra güvenilir olsun ve oyunlaştırma kolayca fark edilsin.
Claim/lock (çekme/kilit) mekanizması uygulayın ve zaman aşımı ekleyin:
Bu, çift işleme riskini azaltır ve darboğazları ya da cherry‑picking davranışlarını teşhis etmenizi sağlar.
Politikayı yapılandırılmış bir taksonomiye ve şablonlara dönüştürün:
Bu, tutarlılığı artırır, analizleri anlamlı kılar ve denetim/itiraz süreçlerini basitleştirir.
Hikâyeyi yeniden oluşturmak için gerekli her şeyi kaydedin:
Araştırmacıların actor, content ID, politika kodu, kuyruk ve zaman aralığı ile filtreleyebileceği şekilde arama yapabilir yapın ve saklama kurallarını (hukuki tutuklamalar dahil) netleştirin.
Ayrıca hangi politika sürümünün ilk kararda uygulandığını ve itiraz sırasında hangi sürümün uygulandığını kaydedin.
Sonra yetkileri yetenek bazlı (ör. can_export_data, can_apply_account_penalty) şekilde en az ayrıcalık prensibiyle detaylandırın, böylece yeni özellikler erişim modelinizi bozmaz.