Digital Commerce Compliance Boundaries

وقتی Checkout سالم است اما «Compliance» هنوز قابل اثبات نیست

فرض کن یک marketplace آموزشی قیمت اولیهٔ یک دوره را نمایش می‌دهد، fee اجباری را دیرتر اضافه می‌کند، برای checkout و marketing دادهٔ learner را پردازش می‌کند و در دو jurisdiction مسیر cancellation/refund متفاوت دارد. از نظر فنی ممکن است checkout بدون خطا کار کند؛ اما این واقعیت به‌تنهایی چیزی دربارهٔ صحت claim، شفافیت price/fee، adequacy disclosure، purpose/consent، seller role یا الزام‌های cancellation/refund ثابت نمی‌کند.

در این درس Digital Commerce Compliance Boundary Matrix & Evidence Ledger v1 را می‌سازیم. هر تصمیم به evidence صریح bind می‌شود: jurisdiction، seller_role/marketplace_role، claim_evidence_ref، price_display_state، mandatory_fee_state، disclosure_prominence، consent_purpose/consent_state، privacy_notice_ref، cancellation_path_ref، refund_policy_ref، policy_version، legal_basis_ref، review_owner و review_state.

قاعدهٔ اصلی: هیچ UI سالم، platform pattern، checklist عمومی یا خروجی AI به‌خودی‌خود proof of legal compliance نیست. اگر evidence ناقص، stale یا متناقض است، state باید REVIEW_REQUIRED، HOLD یا INSUFFICIENT_EVIDENCE بماند. این درس legal advice نمی‌دهد؛ هدفش طراحی boundary و evidence contract برای ارجاع قابل‌ممیزی به review واجدصلاحیت است.

مناسب برای: مهندسان marketplace/LMS، product engineers، privacy/compliance-aware architects، QA و reviewers. مناسب نیست برای: تفسیر حقوقی نهایی، جایگزینی counsel/qualified reviewer، یا صدور نتیجهٔ قانونی برای یک کشور/محصول واقعی.

مسیر یادگیری و مرز مسئولیت

MKN-026 فقط مالک Digital Commerce Compliance Boundaries است. prerequisite رسمی آن MKN-021 است. MKN-025 outcome «Reputation Anti-gaming and Trust Signals» را دارد و MKN-027 authoring UX را؛ این درس هیچ‌کدام را جذب نمی‌کند.

مسیر Foundation با field map و یک baseline synthetic شروع می‌کند. مسیر Repair فقط اولین evidence dimension شکسته را تعمیر می‌کند: مثلاً fee visibility، consent purpose یا stale legal basis. مسیر Experienced باید trade-off میان automation، jurisdiction routing، marketplace role، privacy purpose و human review را توضیح دهد بدون اینکه آن‌ها را در یک compliant=true پنهان کند.

سه checkpoint: F1 مرز outcome و یک non-goal را بگو؛ F2 یک shortcut را با field/state دقیق رد کن؛ F3 در transfer با seller جدید و jurisdiction جدید، تصمیم را فقط از evidence جدید recompute کن.

مدل ذهنی: Compliance Gate یک Evidence Router است، نه یک Boolean

جریان مرجع:

commerce surface → jurisdiction + role identification → claim/price/disclosure evidence → consent/privacy purpose → cancellation/refund lifecycle → qualified review → RELEASE / REVIEW_REQUIRED / HOLD

سه لایه را جدا نگه دار:

1. Product behavior: چه چیزی نمایش داده، جمع‌آوری یا اجرا می‌شود—مثلاً headline price، mandatory fee، marketing toggle یا cancellation path.
2. Evidence + policy/legal references: claim substantiation، disclosure evidence، privacy notice، consent evidence، policy version و legal_basis_ref که باید versioned و traceable باشند.
3. Qualified decision: owner/reviewer واجدصلاحیت که interpretation یا conflict را می‌بندد. AI و application code فقط evidence را organize/validate می‌کنند؛ authority حقوقی ایجاد نمی‌کنند.

در این مدل، RELEASE یک state داخلیِ bounded است و فقط زمانی معنا دارد که تمام gateهای تعریف‌شده evidence کافی داشته باشند و review لازم بسته شده باشد. این state نباید به‌عنوان «این کسب‌وکار در همهٔ jurisdictionها قانوناً compliant است» تعبیر شود.

قرارداد پایه: Matrix، Ledger و State Vocabulary

برای هر commerce surface حداقل این evidence dimensions را نگه دار:

• identity: commerce_surface_id, offer_id, jurisdiction؛
• claims/pricing: claim_id, claim_evidence_ref, price_display_state, mandatory_fee_state, disclosure_id, disclosure_prominence؛
• privacy/consent: consent_purpose, consent_state, privacy_notice_ref؛
• role/lifecycle: seller_role, marketplace_role, cancellation_path_ref, refund_policy_ref؛
• authority/review: policy_version, legal_basis_ref, review_owner, review_state, effective_date, exception_ref, audit_event_id.

پنج invariant:

1. Jurisdiction explicit: هیچ row بدون jurisdiction یا route-to-review معتبر release نمی‌شود.
2. Evidence before positive state: claim، fee/disclosure و purpose/consent باید reference قابل‌ردگیری داشته باشند.
3. Role-aware: first-party seller و marketplace/third-party seller یک role نیستند؛ role mutation نیاز به recomputation دارد.
4. Lifecycle explicit: cancellation/refund fields جدا از checkout success‌اند.
5. No AI legal conclusion: AI می‌تواند missing fields یا contradictions را flag کند، اما state حقوقی نهایی یا interpretation را جعل نمی‌کند.

Stateهای غیرموفق را حفظ کن: UNKNOWN، UNVERIFIED، STALE، REVIEW_REQUIRED، HOLD، INSUFFICIENT_EVIDENCE و REVOKED.

توضیح عمیق: چرا هر Dimension باید مستقل بماند

Claim و disclosure. راهنمای رسمی FTC برای تبلیغات/بازاریابی آنلاین یادآوری می‌کند که truth-in-advertising standards در فضای آنلاین هم مطرح‌اند و disclosureهای material باید طوری ارائه شوند که مصرف‌کننده بتواند آن‌ها را ببیند و بفهمد. اما این guidance ایالات متحده، universal rule engine برای MAKNOW نیست. در معماری، نتیجه این است که claim و disclosure باید evidence و jurisdiction boundary صریح داشته باشند؛ نه اینکه صرفاً یک banner وجود داشته باشد.

Price و mandatory fees. نمایش headline price و نمایش fee اجباری دو evidence dimension جداست. اگر fee از offer screen به مرحلهٔ نهایی منتقل شود، UI ممکن است هنوز technically valid باشد، ولی price_display_state و mandatory_fee_state باید دوباره بررسی شوند. «checkout succeeded» repair نیست.

Consent و privacy purpose. NIST Privacy Framework یک ابزار داوطلبانه برای مدیریت privacy risk است و برای فهم roleها در data-processing ecosystem مفید است؛ قانون نیست و obligation مشخص یک jurisdiction را تعیین نمی‌کند. اگر purpose از fulfillment-only به fulfillment + marketing تغییر کرد، consent/privacy evidence قبلی نباید خودکار reuse شود.

Seller/marketplace role. role روی workflow و review routing اثر می‌گذارد. اگر third-party seller وارد شود، matrix باید seller_role و marketplace_role را دوباره تعیین کند و evidence مرتبط را update کند. وجود capability فنی برای marketplace proof of obligation نیست.

Cancellation/refund. lifecycle obligations باید fields مستقل داشته باشند. اگر cancellation path یا refund policy نامعلوم است، positive release state نباید از checkout completion استنتاج شود.

Policy version و legal basis. legal_basis_ref بدون version/effective date خطرناک است. stale evidence باید STALE/HOLD بسازد. اگر interpretation بین منابع یا jurisdictionها conflict دارد، route باید human/qualified review باشد.

FACT / INFERENCE / DESIGN. FTC/NIST factهای محدود خودشان را می‌دهند. اینکه این dimensionها را جدا نگه داریم یک inference معماری برای auditability است. schema، state labels و review routing دقیق MAKNOW design authority هستند.

مثال کارشده: دو Jurisdiction، یک Fee Conflict و یک Purpose Boundary

Baseline synthetic را در نظر بگیر. OFFER-COURSE-41 روی SURFACE-WEB-CHECKOUT قرار دارد. در JUR-A-DEMO claim evidence و disclosure reference حاضر است؛ fee اجباری از اولین offer view قابل مشاهده است؛ consent purpose فقط fulfillment است و review هنوز بسته نشده. در JUR-B-DEMO legal interpretation عمداً REVIEW_REQUIRED است. بنابراین bounded result کل case REVIEW_REQUIRED است—نه به‌خاطر bug، بلکه چون unresolved authority evidence را صادقانه نگه داشته‌ایم.

جدول MKN-026-T1 سه سناریو را کنار هم می‌گذارد: baseline، fee moved late و transfer با third-party seller + jurisdiction جدید. یک row «compliant=yes» ندارد؛ تصمیم از evidence columns ساخته می‌شود.

Mutation 1: mandatory fee از offer screen به final checkout منتقل می‌شود ولی disclosure evidence update نمی‌شود. نتیجه باید HOLD باشد، چون mandatory_fee_state/disclosure_prominence با behavior جدید سازگار نیست.

Mutation 2: purpose به fulfillment + marketing تغییر می‌کند ولی consent evidence همان fulfillment-only می‌ماند. نتیجه HOLD است؛ privacy notice یا checkbox ظاهری این contradiction را repair نمی‌کند.

Mutation 3: third-party seller اضافه می‌شود و سیستم roleهای first-party قبلی را reuse می‌کند. state باید fail-closed بماند تا seller/marketplace evidence و review route بازسازی شوند.

برای اجرای deterministic fixture: lab://MKN-026/MKN-026-LAB1.

Failure Modes: shortcutهایی که False Confidence می‌سازند

Generic compliance flag. یک is_compliant=true بدون matrix dimensions evidence را نابود می‌کند. validator باید این shortcut را reject کند.

Late fee but old disclosure proof. behavior عوض شده اما disclosure reference/version قبلی نگه داشته شده است. این stale evidence است.

Purpose expansion without consent update. marketing به purpose اضافه می‌شود ولی consent state تغییر نمی‌کند. نتیجه positive نمی‌تواند بماند.

Old legal basis reused for new jurisdiction. JUR-C-DEMO اضافه می‌شود اما legal_basis_ref متعلق به JUR-A-DEMO است. این identity mismatch است، نه reuse مجاز.

Seller-role mutation ignored. first-party به marketplace تبدیل می‌شود اما role fields ثابت می‌مانند. workflow باید HOLD/REVIEW_REQUIRED شود.

Satisfaction or implementation as proof. checkout conversion، user satisfaction یا «فلان platform این feature را دارد» proof of legal compliance نیست.

AI declares lawful. مدل می‌تواند matrix را summarize یا missing evidence را پیدا کند، اما statement مثل «this flow is legally compliant» بدون qualified authority ممنوع است.

Review closed with unresolved evidence. review_state=APPROVED در حالی که legal basis یا consent evidence unknown است contradiction است و باید fail شود.

پل به معماری Experienced: Policy-as-Evidence، نه Policy-as-Oracle

در سیستم بزرگ‌تر، matrix می‌تواند از چند service تغذیه شود: catalog/pricing، checkout, consent registry، seller registry، policy repository و review workflow. نکته این است که هیچ service به‌تنهایی authority کامل ندارد.

یک معماری امن‌تر سه output دارد: observed behavior, evidence references, decision state. rule engine فقط deterministic contradictions را پیدا می‌کند—مثل fee moved but disclosure unchanged، purpose expanded but consent not updated، legal basis jurisdiction mismatch یا stale policy version. interpretation مبهم به queue human review می‌رود.

برای versioning، هر evidence reference باید حداقل source identity، version/effective date و audit event داشته باشد. در migration یا policy update، previous decision overwrite نمی‌شود؛ decision جدید با provenance جدید ساخته می‌شود تا reviewer بتواند ببیند کدام evidence تغییر کرد.

AI در این معماری assistant است: field extraction، diff، routing suggestion و completeness check. AI نباید authority بسازد، review owner جعل کند یا legal conclusion صادر کند.

جایگزین‌ها و Trade-offها

Boolean flag ساده و سریع است اما provenance و uncertainty را از بین می‌برد؛ برای release gate این درس ناکافی است.

Checklist فقط متنی برای onboarding خوب است اما اگر evidence refs/version/state نداشته باشد قابل replay نیست.

Hard-coded jurisdiction rules automation بالایی می‌دهند، ولی بدون freshness/versioning و qualified ownership به‌سرعت stale می‌شوند. این درس rule library حقوقی نمی‌سازد.

Evidence matrix + human review routing هزینهٔ بیشتری برای schema و workflow دارد، اما uncertainty و conflict را حفظ می‌کند و تصمیم را قابل audit می‌سازد؛ این گزینهٔ مرجع درس است.

External platform defaults می‌توانند implementation hint بدهند، ولی local authority نیستند. platform support باید نهایتاً یک evidence input باشد، نه permission.

Stop/pivot condition: اگر team نتواند jurisdiction، role، evidence version و review owner را برای decision بازسازی کند، release state باید ضعیف‌تر شود، نه اینکه با score یا confidence مدل پوشانده شود.

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

Guided. baseline fixture را باز کن. برای هر row فقط این سؤال‌ها را جواب بده: jurisdiction چیست؟ seller/marketplace role چیست؟ claim/price/disclosure evidence کجاست؟ consent purpose چیست؟ cancellation/refund refs چیست؟ legal basis و policy version کدام‌اند؟ review owner/state چیست؟ سپس bounded state را تعیین کن. اگر یک dimension decisive ناقص است، positive state ممنوع است.

Repair. mutation fee_late_without_disclosure_update را اجرا کن. فقط fieldهای تغییرکرده را مشخص کن و minimal repair را بنویس: behavior evidence و disclosure evidence باید هم‌نسخه شوند؛ «add warning text» بدون authority/evidence کافی نیست.

Independent. fixture purpose expansion را بدون نگاه به baseline state حل کن. explain کن چرا fulfillment-only consent برای marketing purpose oracle نیست.

Experienced. transfer را اجرا کن: third-party seller و jurisdiction جدید اضافه می‌شوند. از صفر seller_role, marketplace_role, privacy purpose, cancellation/refund, legal basis و review route را بازسازی کن. baseline decision label را reuse نکن.

Verification: چه چیزی واقعاً Proof محسوب می‌شود؟

Lab آفلاین JSON/CSV است و هیچ network، API key، tenant یا customer data ندارد. producer testها باید دست‌کم این‌ها را ثابت کنند: baseline با unresolved qualified review به REVIEW_REQUIRED می‌رسد؛ late fee، purpose expansion بدون consent update، seller-role mismatch، new-jurisdiction/old-legal-basis، missing claim evidence، stale policy version، generic boolean shortcut، AI legal conclusion، missing review owner و approval-with-unknown-evidence همگی fail-closed می‌شوند؛ transfer درست به review state مستقل می‌رسد.

این testها فقط منطق synthetic evidence contract را ثابت می‌کنند. آن‌ها ثابت نمی‌کنند که یک checkout واقعی در کشور خاص قانوناً compliant است، source حقوقی کامل است، counsel review انجام شده، یا policy خارجی آینده تغییر نخواهد کرد.

Verification انسانی باید بتواند bounded decision را از files و fields مرئی بازسازی کند؛ hidden chain-of-thought مدل evidence نیست.

Assessment و Transfer

S1 Retrieval: مرز MKN-026 را توضیح بده و یک non-goal نام ببر. S2 Application: baseline synthetic را به Matrix & Evidence Ledger کامل تبدیل کن و state را از evidence استخراج کن. S3 Diagnosis: mandatory fee را از first offer screen به final checkout منتقل کن؛ دقیق بگو کدام field/state invalid می‌شود و minimal repair چیست. S4 Transfer: همان learning product را با third-party seller و jurisdiction جدید بازسازی کن؛ seller/marketplace role، disclosure، privacy purpose، cancellation/refund و review obligations را از evidence جدید recompute کن.

Rubric پنج dimension blocking دارد: identity/contract، exact evidence binding، negative evidence، bounded decision و transfer. هر پاسخ که implementation success یا generic checklist را به proof of legal compliance تبدیل کند fail است.

منابع، Freshness و مرز ادعا

FTC — Online Advertising and Marketing https://www.ftc.gov/business-guidance/advertising-marketing/online-advertising-marketing FACT محدود: truth-in-advertising standards در online commerce هم مطرح‌اند و material disclosures باید به‌صورت قابل‌توجه/قابل‌فهم ارائه شوند. مرز: guidance ایالات متحده است و universal compliance oracle برای همهٔ jurisdictionها یا MAKNOW نیست.

NIST — Privacy Framework https://www.nist.gov/privacy-framework FACT محدود: Privacy Framework ابزار داوطلبانه برای شناسایی/مدیریت privacy risk در محصولات، خدمات و data-processing ecosystem است. مرز: قانون نیست و obligation jurisdiction-specific را تعیین نمی‌کند. صفحهٔ فعلی NIST همچنین کار روی Privacy Framework 1.1 را نشان می‌دهد؛ بنابراین version/freshness باید ثبت شود.

منابع رسمی در 2026-09-13 دوباره بررسی شدند. claimهای legal/policy current باید حداکثر تا 2026-11-12 یا زودتر پس از تغییر material دوباره qualify شوند؛ privacy-framework practice claim نیز حداکثر تا 2027-01-15 یا زودتر پس از تغییر material بازبینی شود. هر canonical change بعد از acceptance نیازمند version جدید است.

سؤال پایانی: در commerce flow شما کدام shortcut بیشترین false confidence را می‌سازد—compliant=true، fee disclosure دیرهنگام، reuse consent، reuse legal basis یا reliance on AI—and کدام evidence field دقیقاً آن را افشا می‌کند؟

python run_checks.py fixtures/baseline.json
python run_checks.py fixtures/fee_late_without_disclosure_update.json
python run_checks.py transfer/transfer_fixture.json