Mentor Quality و Escalation Operations

چرا «فعال بودن» مساوی «کیفیت Mentor» نیست؟

فرض کن یک Mentor در داشبورد عالی به نظر می‌رسد: تعداد پاسخ‌ها زیاد است، زمان پاسخ پایین است و امتیاز رضایت هم بالاست. اما در نمونه‌ی بازبینی‌شده، یک توصیه‌ی فنی بدون شواهد کافی داده شده، دو reviewer بر سر یک بُعد rubric اختلاف دارند و دو شکایت learner هنوز resolution قابل‌ردیابی ندارند. اگر فقط activity را نگاه کنیم، سیستم می‌تواند همان Mentor را «عالی» اعلام کند؛ اگر فقط یک score کلی بسازیم، اختلاف و ریسک را پنهان می‌کنیم.

هدف این درس ساختن Mentor Quality Review, Calibration & Escalation Operations Ledger v1 است: نمونه‌ی تعامل باید provenance داشته باشد؛ sampling policy و rubric نسخه‌دار باشند؛ score به dimension و evidence وصل شود؛ disagreement و conflict حذف نشوند؛ issueهای safety/policy/competence نوع‌بندی شوند؛ escalation دارای severity، owner، acknowledgment و resolution evidence باشد؛ coaching تاریخچه را پاک نکند؛ و سیگنال خودکار فقط advisory بماند تا تصمیم consequential توسط انسان مجاز بسته شود.

خروجی این درس یک «امتیاز Mentor» نیست. خروجی، یک قرارداد عملیاتی قابل‌ممیزی است که می‌تواند با اطمینان بگوید REVIEW_REQUIRED، HOLD، INSUFFICIENT_EVIDENCE یا در شرایط محدود ACTIVE_BOUNDED چرا انتخاب شده است.

مناسب برای: طراحان learning platform، تیم‌های mentor/reviewer operations، QA و کسانی که باید تصمیم‌های کیفیت را از evidence بازسازی کنند. مناسب نیست برای: رتبه‌بندی مخفی افراد، تصمیم HR خودکار، یا استفاده از داده‌ی واقعی learner بدون مجوز.

مسیر یادگیری و مرز درس

اگر تازه‌کار هستی، اول vocabulary و جدول فیلدها را بساز و بعد baseline را اجرا کن. اگر در یک gate شکست خوردی، repair route فقط همان evidence dimension را جدا می‌کند. اگر باتجربه‌ای، از conflicting evidence شروع کن و مجبور شو distinction میان activity، quality، outcome و risk را دفاع کنی.

این درس مالک quality review + calibration + escalation operations است. MKN-028 فقط context-sharing لازم را به‌عنوان prerequisite می‌آورد و MKN-030 portability/package را بعداً می‌گیرد. این درس مجوز حقوقی صادر نمی‌کند، داده‌ی زنده را افشا نمی‌کند و تصمیم production/HR واقعی نمی‌گیرد. داده‌های Lab کاملاً synthetic و offline هستند.

سه checkpoint داریم: F1 مرز را بازگو کن؛ F2 یک shortcut نامعتبر را با evidence رد کن؛ F3 در transfer، تصمیم را با rubric جدید از صفر بساز. baseline answer هرگز oracle نیست.

مدل ذهنی: از interaction تا resolution، بدون قاطی‌کردن activity با quality

جریان اصلی این است:

interaction snapshot → governed sample → rubric-versioned review → evidence-bound dimension scores → reviewer disagreement/calibration → typed issue classification → escalation owner + acknowledgment → resolution/corrective action → follow-up evidence → human closure

در یک lane جدا، activity metrics مثل تعداد پاسخ، session یا satisfaction باقی می‌مانند. آن‌ها می‌توانند signal یا sampling input باشند، اما خودشان quality verdict نیستند. این جداسازی همان جایی است که Caliper مفید است: Caliper زبان و metric profile برای activity data می‌دهد، نه rubric کیفیت Mentor.

سه نوع authority را جدا نگه دار: FACT (مثلاً Caliper یا AI RMF چه می‌گویند)، INFERENCE (چرا evidence review و escalation لازم است)، و DESIGN (rubric، severity matrix، SLA و clearance policy محلی MAKNOW). اگر این سه را مخلوط کنی، یک standard بیرونی به‌اشتباه تبدیل به مجوز تصمیم داخلی می‌شود.

قرارداد پایه‌ی داده و state

حداقل فیلدهای تصمیمی عبارت‌اند از: mentor_ref، interaction_id، interaction_snapshot_hash، review_sample_id، sampling_policy_version، rubric_version، dimension_id، reviewer_ref، review_score، evidence_ref، disagreement_state، calibration_round، conflict_state، unsupported_advice_flag، policy_issue_flag، escalation_id، severity، escalation_reason، escalation_owner، acknowledged_at، resolution_state، resolution_ref، corrective_action_ref، followup_due، appeal_or_review_ref و audit_event_id.

قانون مهم: score بدون rubric_version و evidence_ref فقط عدد است. resolution بدون resolution_ref فقط برچسب است. coaching بدون follow-up evidence clearance نیست. disagreement هم خطای داده نیست؛ اگر reviewerها اختلاف دارند باید state آن حفظ شود و calibration round نشان دهد چه چیزی تغییر کرده است.

Stateهای غیرموفق را واقعی نگه دار: UNKNOWN برای ناشناخته، STALE برای evidence/rubric قدیمی، DISPUTED برای اختلاف unresolved، REVIEW_REQUIRED برای تصمیمی که انسان باید ببندد، HOLD برای contract شکسته، و INSUFFICIENT_EVIDENCE برای evidence ناکافی.

طراحی review، calibration و escalation

Sampling: sample باید قابل‌تکرار و قابل‌توضیح باشد. sampling_policy_version مشخص می‌کند تعامل چگونه وارد review شده؛ cherry-pick کردن تعامل‌های خوب یا بد، evidence را منحرف می‌کند. activity signal می‌تواند برای prioritization استفاده شود، اما sample selection باید ثبت شود.

Rubric: هر dimension معنی، evidence expectation و scale محدود دارد. وقتی rubric عوض می‌شود، score قدیمی نباید با label «current» حمل شود. re-score فقط روی governed sample و با نسخه‌ی جدید انجام می‌شود؛ تصمیم قبلی تاریخچه است نه چیزی که overwrite شود.

Calibration: اختلاف reviewer باید visible باشد. calibration round می‌تواند تعریف dimension یا interpretation را اصلاح کند، اما نباید disagreement قبلی را حذف کند. calibration_delta توضیح می‌دهد چه چیزی نسبت به دور قبل تغییر کرده است.

Escalation: issue را type کن؛ مثلاً unsupported advice، policy issue، learner risk یا competence gap. severity و owner باید جدا از sentiment باشند. acknowledgment ثابت می‌کند escalation دیده شده؛ resolution evidence ثابت می‌کند بسته‌شدن justified است. satisfaction score نمی‌تواند جای resolution_ref را بگیرد.

Automation: مدل می‌تواند interactions را خلاصه یا anomaly را prioritize کند، اما اگر signal مستقیماً Mentor را penalize یا clear کند، human accountability شکسته است. NIST AI RMF برای workflowهای AI-assisted روی governance/risk management مفید است، اما authority rubric و escalation همچنان محلی است.

مثال کارشده: Mentor پرکار با escalation باز

Fixture پایه Mentor M-17 را دارد. activity بالاست و satisfaction مثبت، ولی sample S-204 به interaction snapshot ثابت متصل است و در rubric RQ-7 برای dimension evidence_grounding امتیاز پایین دارد. reviewer دوم با شدت مشکل اختلاف دارد، و unsupported_advice_flag=true است. escalation ESC-91 با severity HIGH به owner مشخص assign و acknowledge شده، اما resolution_state=OPEN است.

نتیجه‌ی bounded: ESCALATED_REVIEW_REQUIRED. چرا؟ چون review evidence traceable است و escalation contract هم معتبر است، اما resolution هنوز وجود ندارد. activity بالا هیچ‌کدام از این facts را خنثی نمی‌کند.

در جدول MKN-029-T1 baseline، mutation و transfer را کنار هم ببین. برای اجرای deterministic از lab://MKN-029/MKN-029-LAB1 استفاده کن. مهم است که Lab تصمیم نهایی را در fixture prefill نمی‌کند؛ ruleها visible هستند و learner باید submission را بسازد.

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

1. Rubric drift: review با RQ-7 انجام شده ولی record با RQ-8 current نشان داده می‌شود بدون re-score → HOLD.
2. Satisfaction-as-resolution: escalation با satisfaction بالا CLOSED شده ولی resolution evidence ندارد → HOLD.
3. Lost snapshot: بعد از disagreement، interaction snapshot حذف یا hash آن گم شده → HOLD چون review دیگر reproducible نیست.
4. Auto-penalty: model signal مستقیم state Mentor را SUSPENDED می‌کند بدون human authority → HOLD.
5. No owner/ack: escalation severity دارد ولی owner یا acknowledgment ندارد → HOLD.
6. Coaching = clearance: corrective action ثبت شده ولی follow-up evidence وجود ندارد → HOLD یا REVIEW_REQUIRED، نه clearance.
7. Activity proxy: پاسخ زیاد یا session زیاد به‌عنوان quality score استفاده می‌شود → evidence misuse؛ review state را تغییر نمی‌دهد.

Repair همیشه کوچک‌ترین dimension خراب را هدف می‌گیرد؛ هیچ repairی با ساختن evidence جعلی مجاز نیست.

پل برای learner باتجربه: quality system را مثل یک تصمیم قابل بازپخش طراحی کن

به‌جای یک dashboard نهایی، به event-sourced decision فکر کن: interaction snapshot، sample inclusion، rubric version، reviewer evidence، disagreement، escalation transition و resolution هرکدام immutable audit event دارند. state فعلی projection این history است، نه جایگزین آن.

برای scale، سه lane نگه دار: telemetry lane برای activity، review lane برای quality evidence، و governance lane برای escalation/appeal. Join میان آن‌ها با ID و provenance انجام می‌شود، نه با یک score ترکیبی. این طراحی اجازه می‌دهد analyst activity trends را ببیند، reviewer quality را بسنجد و owner تصمیم consequential را ببندد بدون اینکه مسئولیت‌ها در هم حل شوند.

Trade-off اصلی هزینه‌ی review است. sampling کمتر ارزان‌تر است ولی blind spot بزرگ‌تر می‌شود؛ sampling بیشتر coverage را بالا می‌برد ولی latency و reviewer load را زیاد می‌کند. پاسخ درست یک weighted score مخفی نیست؛ policy نسخه‌دار با stop/pivot condition است.

گزینه‌ها و trade-offها

همه‌چیز را review کن: coverage زیاد، هزینه و latency بالا. برای محیط‌های کم‌حجم ممکن است قابل‌قبول باشد، اما scale نمی‌کند. Random sampling: bias را کم می‌کند اما rare high-risk cases ممکن است کم دیده شوند. Risk-prioritized sampling: efficiency بهتر، ولی مدل/heuristic prioritization باید advisory و قابل‌ممیزی بماند تا خودش punishment engine نشود. Satisfaction-triggered review: signal مفید است ولی sentiment quality evidence نیست و ممکن است Mentor درست اما سخت‌گیر را بد نشان دهد. Automated scoring: برای triage و consistency check مفید؛ برای consequential closure بدون human review مناسب نیست.

هیچ گزینه‌ای ذاتاً «بهترین» نیست. انتخاب باید sample coverage، severity exposure، reviewer capacity، dispute rate، follow-up burden و authority boundary را explicit کند. هر جا evidence ناکافی است، state را ضعیف‌تر انتخاب کن.

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

تمرین هدایت‌شده: baseline را باز کن. ابتدا activity fields را کنار بگذار. snapshot hash، sampling policy، rubric version، dimension، reviewer evidence و escalation owner/ack را پیدا کن. سپس decision را بدون نگاه‌کردن به label از rules استخراج کن. بعد fixture satisfaction_closed.json را اجرا کن و دقیقاً بگو کدام field باعث HOLD شده است.

تمرین repair: در stale_rubric.json فقط mismatch نسخه را اصلاح کن؛ هیچ field دیگری را تغییر نده. دوباره check را اجرا کن و ببین آیا state از HOLD به state قوی‌تری می‌رود یا evidence دیگری هنوز مانع است.

تمرین مستقل: transfer fixture rubric را به RQ-8 می‌برد و coaching تکمیل شده است. sample governed را با rubric جدید re-score کن، تصمیم قدیمی را history نگه دار، follow-up evidence را bind کن و اجازه نده activity یا model summary خودکار clearance بسازد. نتیجه باید از fixture جدید محاسبه شود، نه از baseline.

evidence package قابل قبول چیست؟

حداقل باید identity Mentor و interaction، snapshot hash، sample/policy version، rubric/dimension، reviewer/evidence/score، disagreement/calibration، issue flags، escalation/severity/reason، owner/ack، resolution reference، corrective action، follow-up، appeal/re-review و audit event قابل‌ردیابی باشند.

Producer tests mutationهای اصلی را مستقل اجرا می‌کنند. learner path فقط ruleها، fixtureها و submission template را می‌بیند؛ evaluator producer در مسیر learner منتشر نمی‌شود. این تفکیک مهم است تا starter skill را pre-solve نکند.

پذیرش evidence باید reproducible باشد: یک reviewer انسانی باید بتواند از همین package بفهمد چرا state انتخاب شده، بدون دسترسی به hidden chain-of-thought یا summary مدل. HOLD و REVIEW_REQUIRED failure سیستم نیستند؛ stateهای صادقانه‌اند.

ارزیابی و transfer

چهار سؤال summative در derived_text/assessment/questions.json هستند: S1 مرز درس، S2 ساخت baseline ledger، S3 تشخیص rubric-version mutation، و S4 transfer بعد از calibration و coaching.

پنج rubric dimension blocking هستند: identity/contract، exact evidence binding، negative evidence، bounded decision و transfer. اگر learner بگوید «چون satisfaction بالا است escalation بسته است» یا «مدل quality را high گفته پس clear»، assessment fail می‌شود حتی اگر باقی فیلدها درست باشند.

در transfer، RQ-8 یک dimension را تغییر می‌دهد. فقط governed sample را re-score کن؛ old decision را حذف نکن؛ coaching completion را با follow-up evidence جدا کن؛ و اگر human closure هنوز pending است، state باید HUMAN_CLEARANCE_REVIEW_REQUIRED باقی بماند. baseline decision را کپی نکن.

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

1. 1EdTech Caliper Analytics برای capture/labeling سازگار learning activity و metric profileها استفاده می‌شود. این منبع quality rubric یا escalation threshold برای Mentor تعریف نمی‌کند.
2. NIST AI Risk Management Framework برای governance و مدیریت ریسک workflowهای AI-assisted مرجع رسمی است. AI RMF 1.0 با توابع Govern/Map/Measure/Manage مبناست و NIST در حال بازنگری آن است؛ بنابراین هر استفاده‌ی operational باید freshness را دوباره بررسی کند.
3. sampling policy، rubric، severity، SLA، coaching، appeal و clearance authority در این درس MAKNOW DESIGN هستند، نه الزام بیرونی.

این دو منبع در 2026-09-13 بازبینی شدند. claimهای practice-evolving باید حداکثر تا 2027-01-15 یا زودتر از آن در صورت تغییر مادی guidance دوباره qualification شوند. package پذیرفته‌شده silently rewrite نمی‌شود؛ update نیازمند version جدید است.

پرسش پایانی: در سیستم خودت کدام shortcut بیشتر false confidence می‌سازد—activity volume، satisfaction، automated score، یا «coaching completed»—و دقیقاً کدام evidence field آن را افشا می‌کند؟