Private Mentor/Reviewer Context Sharing

چرا ارسال «کل پروفایل learner» یک shortcut خطرناک است؟

یک Mentor برای بررسی برنامهٔ debugging فقط به آخرین assessment و دو artifact پروژه نیاز دارد. سیستم فعلی، برای راحتی، کل پروفایل learner را می‌فرستد: private noteها، career data، تاریخچه‌های نامرتبط و هر چیزی که «شاید مفید باشد». این طراحی سه خطا را هم‌زمان پنهان می‌کند: هدف اشتراک‌گذاری مشخص نیست، کمینه‌سازی fieldها قابل‌اثبات نیست، و وقتی دسترسی revoke می‌شود معلوم نیست packageهای قبلی واقعاً نامعتبر شده‌اند یا نه.

در این درس یک Purpose-Bound Mentor Context Share Grant & Provenance Envelope v1 می‌سازیم. هر Share باید purpose، reviewer/mentor مجاز، basis/authorization، requested و approved scope، دلیل minimum-necessary برای هر field، redaction، source snapshot غیرقابل‌تغییر، زمان صدور/انقضا/revoke، سیاست onward sharing و access/audit event داشته باشد. annotationهای Mentor در lane جدا می‌مانند و هیچ‌وقت به‌عنوان source fact داخل canonical learner record نوشته نمی‌شوند.

هدف این درس «بیشتر داده دادن به Mentor» نیست؛ هدف، ساختن یک قرارداد اشتراک‌گذاری محدود و audit-friendly است که وقتی evidence ناقص یا دسترسی لغو شده، صادقانه HOLD، REVOKED، REVIEW_REQUIRED یا INSUFFICIENT_EVIDENCE را نگه دارد.

مناسب برای: مهندسان learning platform، طراحان review/mentor workflow، privacy/security reviewers و QA. مناسب نیست برای: نتیجه‌گیری حقوقی، استفاده از دادهٔ واقعی learner بدون authorization، یا تغییر live canonical records.

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

مسیر foundation با field map و baseline شروع می‌شود. مسیر repair فقط اولین evidence dimension شکسته را جدا می‌کند. مسیر experienced باید trade-off میان convenience، least privilege، auditability و revocation را دفاع کند، بدون اینکه یک score مصنوعی بسازد.

MKN-028 فقط مالک private mentor/reviewer context sharing است. MKN-027 تجربهٔ authoring/editor را به‌عنوان prerequisite نرم می‌آورد و MKN-029 quality/escalation را بعد از این درس می‌گیرد. این درس legal basis واقعی را اختراع نمی‌کند، policy محلی را از NIST استنتاج نمی‌کند و هیچ access واقعی صادر نمی‌کند.

سه checkpoint داریم: F1 مرز را بازیابی کن؛ F2 یک shortcut را با field/state مشخص رد کن؛ F3 در transfer دو grant مستقل را بعد از revoke یکی از purposeها از صفر recompute کن.

مدل ذهنی: Context Share یک projection موقت است، نه کپی پروفایل

جریان پیشنهادی:

review purpose → reviewer authorization → minimum-necessary field selection → redaction → immutable source snapshot → time-bound context grant → access log + separate annotations → expiry/revocation

canonical learner record در این مسیر تغییر نمی‌کند. Context package یک projection از snapshot است که برای purpose خاص ساخته شده و lifecycle مستقل دارد. اگر purpose عوض شود، scope قبلی خودکار بزرگ نمی‌شود. اگر grant revoke شود، cache/download/package قدیمی باید invalid شود. اگر annotation ساخته شود، provenance آن باید reviewer/mentor و source snapshot را نشان دهد، اما annotation source fact نیست.

سه authority class را جدا نگه دار: FACT (مثلاً NIST چه می‌گوید)، INFERENCE (چرا projection محدود و audit log منطقی است)، و DESIGN (field classها، expiry window، role matrix و revocation behavior در MAKNOW).

قرارداد پایه: identity، scope، provenance و state

فیلدهای کلیدی شامل context_share_id، learner_ref، purpose، mentor_or_reviewer_ref، role، authorization_ref، consent_or_basis_ref، requested_scope، approved_scope، field_id، field_class، minimum_necessary_reason، redaction_rule، source_record_ref، source_snapshot_hash، snapshot_created_at، annotation_ref، annotation_author، grant_state، issued_at، expires_at، revoked_at، onward_share_state، download_state، access_event_id و audit_event_id هستند.

چهار invariant عملی:

1. Purpose-bound: هر field باید به purpose فعلی وصل باشد؛ trust در شخص جای purpose-specific authorization را نمی‌گیرد.
2. Snapshot-bound: هر package باید به hash یک snapshot مشخص وصل شود؛ «آخرین داده» بدون snapshot identity provenance نیست.
3. Annotation-separated: observation یا inference Mentor در annotation lane است و canonical source را overwrite نمی‌کند.
4. Time/revocation-bound: expires_at بعد از issuance را نمی‌توان بدون authorization جدید کش داد؛ revoke باید packageهای مشتق‌شده را هم بی‌اعتبار کند.

Stateهای non-success را واقعی نگه دار: UNKNOWN، UNVERIFIED، STALE، REVOKED، REVIEW_REQUIRED، HOLD و INSUFFICIENT_EVIDENCE.

طراحی دقیق Grant، Redaction و Audit

Purpose و Authorization. ابتدا task را یک جملهٔ قابل‌آزمون کن؛ مثلاً «review debugging plan برای assessment A-91». سپس role و authorization reference را bind کن. اگر reviewer مجاز به grading است، این authorization به‌صورت ضمنی coaching یا career review را باز نمی‌کند.

Minimum necessary. requested scope ورودی است، approved scope خروجی gate است. هر field یک minimum_necessary_reason دارد. اگر career profile برای debugging review لازم نیست، حذف می‌شود حتی اگر reviewer trusted باشد.

Redaction. redaction فقط حذف field نیست؛ map باید بگوید کدام field چرا حذف/ماسک شد. اگر source snapshot شامل private note است ولی package آن را ندارد، provenance هنوز می‌تواند snapshot hash را نگه دارد بدون اینکه متن private note را افشا کند.

Snapshot isolation. package روی snapshot ثابت ساخته می‌شود. canonical record ممکن است بعداً تغییر کند، ولی reviewer باید بتواند بفهمد چه نسخه‌ای دیده است. annotation نیز به snapshot ref متصل می‌شود، نه اینکه canonical record را تغییر دهد.

Expiry/Revocation. grant و package lifecycle را جدا از canonical record نگه دار. expiry از ابتدا authorization شده است. extension یعنی grant جدید یا revision traceable. revoke باید access token، package state و cache eligibility را محدود کند و audit event بسازد.

Onward sharing. default = DENIED. فقط authorization صریح می‌تواند recipient/scope جدید را باز کند. forward کردن package به reviewer دیگر با این استدلال که «هم‌تیمی است» یک scope expansion است.

Audit. هر issuance/access/revoke باید event داشته باشد. audit log محتوای private را تکرار نمی‌کند؛ identity، action، actor، package/grant ref، timestamp و outcome را ثبت می‌کند.

مثال کارشده: debugging review با scope محدود

Baseline learner L-204، reviewer REV-42 و purpose برابر DEBUGGING_PLAN_REVIEW دارد. reviewer درخواست recent_assessment، دو project artifact، private mentor note و career profile می‌کند. authorization AUTH-77 فقط review فنی را پوشش می‌دهد. gate دو field نامرتبط را حذف می‌کند و approved scope را به assessment + artifacts محدود می‌سازد. هر field دلیل minimum-necessary دارد؛ private note/career data در redaction map با reason ثبت می‌شوند.

source snapshot SNAP-204-A دارای hash ثابت است. grant CTX-204-DBG-01 در 13 سپتامبر صادر می‌شود و 15 سپتامبر منقضی می‌شود. onward sharing = DENIED. access event و audit event ثبت می‌شوند. Mentor annotation در ANN-77 به snapshot اشاره می‌کند ولی canonical learner record را تغییر نمی‌دهد.

نتیجهٔ synthetic baseline ACTIVE_BOUNDED است: نه به این معنا که یک disclosure واقعی قانونی شده، بلکه به این معنا که fixture تمام gateهای design contract را پاس می‌کند. جدول MKN-028-T1 و lab://MKN-028/MKN-028-LAB1 همین تصمیم را قابل replay می‌کنند.

Failure modeهایی که باید fail-closed شوند

1. Full-profile convenience: career data به grant فعال اضافه می‌شود بدون تغییر purpose → HOLD با SCOPE_EXCEEDS_PURPOSE.
2. Silent expiry extension: expires_at بعد از issuance طولانی می‌شود بدون authorization/revision جدید → HOLD.
3. Revoked but cached: grant revoke است ولی package cached هنوز accessible است → HOLD و package باید invalid شود.
4. Annotation contamination: inference Mentor به canonical learner record نوشته می‌شود → HOLD؛ annotation باید جدا شود.
5. Missing authorization/basis: scope ظاهراً کم است، اما authority reference موجود نیست → INSUFFICIENT_EVIDENCE یا HOLD.
6. Missing snapshot provenance: package وجود دارد ولی source snapshot hash ندارد → replay و audit ممکن نیست.
7. Onward share by trust: recipient جدید به‌خاطر team membership اضافه می‌شود بدون authorization صریح → HOLD.
8. No access event: package معتبر است اما usage قابل‌ممیزی نیست → decision نباید success کامل شود.

repair باید کوچک‌ترین dimension شکسته را اصلاح کند؛ هرگز evidence یا authorization اختراع نکن.

پل پیشرفته: Context package را capability موقت مدل کن

برای سیستم بزرگ، grant را شبیه capability محدود در نظر بگیر: subject، purpose، scope، source snapshot، temporal bounds و policy state. package فقط materialization این capability است. این نگاه مانع می‌شود export فایل، permission واقعی را تعریف کند.

سه store منطقی مفید است: canonical store برای source facts، context package store برای projectionهای purpose-bound، و annotation store برای derived reviewer notes. Join میان آن‌ها فقط با stable ref/provenance انجام می‌شود. revoke لازم نیست canonical history را پاک کند؛ کافی است capability/package state را invalidate کند و access path را ببندد.

در multi-reviewer workflow هر reviewer grant مستقل دارد. اشتراک learner یکی است، ولی purpose و scopeها union نمی‌شوند. یک authorization فعال برای grading نباید revoke شدن coaching را خنثی کند یا برعکس.

الگوهای جایگزین و trade-offها

Full profile + role access: ساده و سریع، اما scope drift و audit ambiguity بالاست. Dynamic field projection: least privilege بهتر، اما نیازمند field classification و rule maintenance است. Prebuilt review bundles: عملیات آسان، ولی stale package و over-broad template خطرناک است. Short-lived signed package: revocation/expiry واضح‌تر، اما download/caching policy باید صریح باشد. No-download browser view: leakage سطح فایل کمتر، ولی همچنان authorization، screenshot/export و audit مسئله‌اند.

هیچ pattern خودکار «privacy compliant» نیست. هزینهٔ reviewer، latency، explainability، revocation propagation و retention را کنار هم ببین. وقتی evidence قانونی/سیاستی نامشخص است، state ضعیف‌تر انتخاب کن و به qualified reviewer ارجاع بده.

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

تمرین هدایت‌شده: baseline را باز کن. برای هر requested field بنویس: purpose link، field class، minimum reason، approve/redact. سپس snapshot hash، issued/expires، onward share و access event را bind کن. بدون نگاه به decision label، gate_rules.py را اجرا و نتیجه را توضیح بده.

تمرین repair: fixture unrelated_career_scope.json را بررسی کن. فقط field نامعتبر را حذف نکن؛ توضیح بده چرا purpose فعلی آن را پشتیبانی نمی‌کند و چه authorization جدیدی برای purpose جدید لازم می‌شود.

تمرین مستقل: fixture transfer دو grant دارد: coaching اختیاری revoke شده، grading هنوز فعال است. هر grant را جدا recompute کن، packageهای affected را invalidate کن و نشان بده grading reviewer scope جدیدی از coaching authorization نمی‌گیرد.

Starter هیچ final answer prefilled ندارد. oracle فقط visible rules + fixture evidence است.

Verification: چه چیزی واقعاً باید اثبات شود؟

برای baseline، artifact باید نشان دهد: identityهای share/learner/reviewer، purpose، authorization/basis، requested و approved scope، field reasons/redactions، snapshot hash، annotation separation، issuance/expiry/revoke state، onward-share state و access/audit event.

Lab دوازده test producer دارد. success baseline، scope expansion، expiry extension، revoked cache، annotation contamination، missing authorization، missing snapshot، unauthorized onward share، missing access log، missing minimum-necessary reason و دو transfer check پوشش داده می‌شوند. هر mutation decisive باید fail-closed باشد.

این verification اثبات نمی‌کند disclosure واقعی با قانون خاصی سازگار است یا production access control امن است؛ فقط contract design و deterministic fixture را اثبات می‌کند.

ارزیابی و transfer

S1 مرز و non-goal را می‌سنجد. S2 ساخت baseline envelope را می‌خواهد. S3 scope expansion نامرتبط را diagnose می‌کند. S4 transfer را از صفر recompute می‌کند.

در transfer، learner purpose OPTIONAL_COACHING را revoke می‌کند. grant مربوط به GRADING_REVIEW هنوز authorization مستقل دارد. نتیجه باید MIXED_ACTIVE_REVOKED باشد: coaching package revoked/invalidated، grading package active bounded، audit history هر دو حفظ، و هیچ scope union رخ نمی‌دهد. اگر grading reviewer career field جدید بگیرد چون coaching reviewer قبلاً آن را داشته، transfer باید HOLD شود.

پنج rubric dimension blocking هستند: identity/contract، evidence binding، negative evidence، bounded decision و transfer. baseline answer oracle نیست.

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

1. NIST Privacy Framework یک ابزار داوطلبانه برای شناسایی و مدیریت privacy risk است. این framework به‌خودی‌خود disclosure مشخص learner را authorize نمی‌کند. در 2026، NIST همچنان PF 1.1 را در مسیر update/Initial Public Draft نگه داشته است.
2. NIST SP 800-53 Rev. 5 خانواده‌های Access Control و Audit and Accountability را در catalog کنترل‌ها دارد؛ این guidance مجوز حقوقی اشتراک learner context نیست.
3. ساختار grant، field classها، expiry/revocation behavior، onward-share default و annotation separation در این درس MAKNOW DESIGN هستند.

منابع رسمی در 2026-09-13 دوباره بررسی شدند. ادعاهای practice-evolving باید تا 2027-01-15 یا زودتر پس از تغییر مهم guidance بازبینی شوند. package پذیرفته‌شده silent rewrite نمی‌شود؛ تغییر canonical نیازمند version جدید است.

پرسش پایانی: در workflow فعلی شما کدام shortcut خطرناک‌تر است—full profile، expiry بلند، onward share، یا annotation داخل canonical record—و دقیقاً کدام field آن را آشکار می‌کند؟