Exit, Export و Deletion

خروج از سرویس یک دکمه Delete نیست

یک مشتری SaaS سرویس را خاتمه می‌دهد و export سپس deletion می‌خواهد. رکوردهای اصلی حذف شده‌اند، اما حذف یک subprocessor هنوز PENDING است، backup طبق schedule بعداً منقضی می‌شود، یک رکورد به دلیل retention قانونی باید بماند و یک API token هنوز فعال است. اگر فقط customer row حذف شود و closure_state=COMPLETE ثبت شود، خروج واقعی اثبات نشده است. در این درس Service Exit, Export, Deletion & Residual-Data Closure Ledger v1 را می‌سازیم تا export، delete/return، retention، backup/subprocessor، credential/integration و residual evidence جدا بمانند.

مرز درس و ترتیب تصمیم

AGN-011 مالک exit/export/deletion است. AGN-010 مالک IP/Rights و AGN-012 مالک Billing Adapter است. مسیر درست: inventory را freeze کن؛ export/return requirement را تعیین کن؛ export را با format + integrity + delivery evidence ببند؛ deletion scope را از retention exception جدا کن؛ primary/backup/subprocessor state را مستقل ثبت کن؛ credentialها و integrationها را ببند؛ residual scan را اجرا کن؛ و فقط بعد closure را COMPLETE, PARTIAL یا HOLD اعلام کن.

مدل ذهنی: هفت دروازه مستقل

هفت دروازه را یکی نکن: inventory, export/return, retention, primary deletion, backup/subprocessor closure, credential/integration shutdown, residual verification. گذر از هر دروازه فقط همان بخش را ثابت می‌کند. export موفق deletion را ثابت نمی‌کند؛ حذف primary، backup را ثابت نمی‌کند؛ certificate بدون residual evidence کل closure را ثابت نمی‌کند.

۲۲ بُعد Ledger

Contract روی ۲۲ فیلد قفل است: exit_case_id, asset_inventory_ref, data_inventory_ref, agent_memory_inventory_ref, export_scope, export_format, export_integrity_hash, export_delivery_state, deletion_scope, retention_exception_ref, retention_until, primary_delete_state, backup_delete_state, subprocessor_delete_state, credential_revoke_state, integration_disconnect_state, residual_scan_ref, residual_state, deletion_certificate_ref, legal_review_required, closure_state, audit_ref. Lab چند فیلد کمکی مثل retained_data_present, retention_exception_valid, return_required, return_state, active_credential_count, active_integration_count, transfer_recomputed و baseline_decision_reused هم دارد تا shortcutها قابل‌تست شوند.

Fact، Inference و Design را جدا نگه دار

FACT: Article 20 GDPR تحت شرایط مشخص portability را برای personal data در format ساخت‌یافته، رایج و machine-readable تعریف می‌کند. FACT: Article 28(3)(g) در context processor می‌گوید پس از پایان خدمات، در انتخاب controller داده باید delete یا return شود و copyها حذف شوند مگر قانون ذخیره را لازم کند. INFERENCE: چون این obligationها و scopeهای عملیاتی متفاوت‌اند، exit را به چند closure state تفکیک می‌کنیم. DESIGN: exact export format، retention window، proof artifact، backup policy و authority نهایی closure تصمیم‌های محلی MAKNOW/contract/legal review هستند.

Baseline: چرا PARTIAL درست است؟

Baseline یک export تحویل‌شده با SHA-256 دارد. primary data حذف شده، backup SCHEDULED_FOR_EXPIRY است، subprocessor PENDING, credential هنوز ACTIVE, integration قطع شده و retention exception معتبر برای یک billing record وجود دارد. نتیجه‌ی درست EXIT_PARTIAL_REVIEW_READY است. اگر learner صرفاً primary_delete_state=DELETED را ببیند و closure را COMPLETE کند، evaluator باید false-complete را رد کند.

Mutation 1: subprocessor_delete_state=PENDING + closure_state=COMPLETE → HOLD_FALSE_COMPLETE_PENDING_SUBPROCESSOR. Mutation 2: retained data باقی است ولی retention exception حذف شده → HOLD_RETENTION_BASIS_MISSING. Mutation 3: export delivery VERIFIED ولی integrity hash حذف شده → HOLD_EXPORT_INTEGRITY_MISSING. Mutation 4: residual=CLEAR ولی API token هنوز فعال است → HOLD_ACTIVE_CREDENTIAL_RESIDUAL_CONFLICT.

Failure modeهای مهم

1. حذف primary را برابر خروج کامل گرفتن. 2. export بدون integrity evidence. 3. retained data بدون basis معتبر. 4. backup pending زیر closure COMPLETE. 5. subprocessor pending زیر closure COMPLETE. 6. credential فعال بعد از exit. 7. integration متصل بعد از closure. 8. residual=CLEAR در حالی‌که asset/credential شناخته‌شده باقی است. 9. deletion certificate بدون evidence قابل بازسازی. 10. legal review لازم است ولی closure نهایی اعلام شده. 11. transfer، basis یا closure baseline را کپی می‌کند.

COMPLETE، PARTIAL، HOLD و RETURN

COMPLETE فقط وقتی مجاز است که همه stateهای required بسته یا با exception معتبر مستند شده باشند. PARTIAL وقتی درست است که export یا primary deletion انجام شده ولی backup/subprocessor/credential/residual closure هنوز درحال تکمیل است. HOLD وقتی evidence decisive مفقود یا contradictory است. در بعضی processor relationships، RETURN به‌جای delete انتخاب می‌شود؛ این مسیر را باید جدا مدل کرد و آن را با portability right یکی نگرفت.

پل برای فرد باتجربه: Backups، Subprocessors و Legal Hold

در سیستم واقعی، deletion فوری همه copyها همیشه ممکن نیست. backup ممکن است فقط با expiry schedule از چرخه خارج شود؛ subprocessor ممکن است evidence جدا بدهد؛ legal hold می‌تواند retention موقت بسازد. نکته‌ی حرفه‌ای این است که exception را failure نام نگذاری و failure را exception جا نزنی. retention_exception_ref, retention_until, owner/legal review و residual evidence باید قابل ممیزی باشند.

تمرین هدایت‌شده و مستقل

Baseline را اجرا کن و توضیح بده چرا PARTIAL است. سپس فقط یک فیلد را در هر بار تغییر بده: subprocessor، retention basis، export hash، credential، integration، residual scan و certificate. اولین gate شکسته را نام ببر. سپس fixture transfer را حل کن: بعضی data باید RETURN شود، portability right وجود ندارد اما contractual export promise وجود دارد. تصمیم را از evidence جدید بساز؛ baseline label را نبین.

چه چیزی باید بازسازی‌پذیر باشد؟

Reviewer باید بتواند پاسخ دهد: inventory کجاست؟ export scope چه بود؟ format و hash چیست؟ delivery چگونه ثابت شد؟ deletion scope چیست؟ کدام داده با چه basis تا چه زمانی retained است؟ primary/backup/subprocessor چه stateی دارند؟ credential و integration بسته شده‌اند؟ residual scan چه چیزی نشان داده؟ certificate به چه evidenceای متصل است؟ legal review لازم است؟ و چرا closure دقیقاً COMPLETE/PARTIAL/HOLD است؟

Transfer: Return به‌جای Delete و Contractual Export

Case دوم processor-held data را برای بخشی از scope باید RETURNED کند، نه delete. در این case portability right اعمال نمی‌شود، ولی contract یک export machine-readable را وعده داده است. export basis را CONTRACTUAL_PROMISE ثبت کن، return state را verify کن، retention و residual را از نو محاسبه کن و closure را مستقل بساز. reuse کردن jurisdictional basis یا baseline closure باید fail شود. با evidence کامل، نتیجه می‌تواند TRANSFER_EXIT_REVIEW_READY باشد.

منابع و تازگی

FACT: متن رسمی GDPR Article 20 حق portability را تحت شرایط مشخص بیان می‌کند. FACT: Article 28(3)(g) delete-or-return processor data پس از پایان services را با استثنای storage required by law بیان می‌کند. European Commission همچنان SCCهای controller–processor تحت Article 28(7) را منتشر می‌کند. INFERENCE: این evidence جداسازی stateهای exit را توجیه می‌کند. DESIGN: closure policy دقیق متعلق به MAKNOW و قرارداد/بررسی حقوقی است. منابع حقوقی تا 2026-11-02 یا زودتر در صورت تغییر مادی بازبینی شوند.