Matching, Fairness و Explainability

یک Ranking ظاهراً خوب هنوز می‌تواند تصمیم ناامن بسازد

یک matcher برای کارآموزیِ پولی از skill evidence تأییدشده، زمان تکمیل دوره، امتیاز portfolio و یک سیگنال استنباطی «communication style» از مصاحبهٔ ضبط‌شده استفاده می‌کند. مدل یک متقاضی را بالا rank می‌کند. متقاضی دیگری درخواست مسیر accessible جایگزین برای مصاحبهٔ ویدیویی دارد. Aggregate accuracy هم خوب به نظر می‌رسد؛ پس تیم محصول وسوسه می‌شود score را مستقیماً به تصمیم تبدیل کند.

این evidence کافی نیست. Ranking می‌تواند از نظر عددی خوب باشد ولی feature بی‌ارتباط با شغل، proxy risk، false-negative متفاوت در یک slice، assessment غیرقابل‌دسترس یا explanation بدون evidence را پنهان کند.

در این درس Fair Matching Decision & Explanation Record v1 را می‌سازید: eligibility را از ranking جدا می‌کند، هر feature را به source و job-relevance evidence وصل می‌کند، policy مربوط به sensitive attribute و proxy risk را visible نگه می‌دارد، accommodation و alternative-assessment را حفظ می‌کند، uncertainty و slice/error review را ثبت می‌کند و برای outcome پراثر، human review را authority نهایی نگه می‌دارد.

قاعدهٔ مرکزی: score فقط evidence دربارهٔ خروجی model است؛ authority برای adverse career decision نیست.

مناسب برای: مهندسان learning platform، matching/recommendation، تیم data/product و reviewerهای governance. خارج از scope: تصمیم استخدام واقعی، استنباط ویژگی‌های محافظت‌شده، اعلام compliance حقوقی، یا ارزیابی فرد واقعی با fixture این درس.

جهت درس و مرز مالکیت

MKN-019 فقط outcome مربوط به Matching, Fairness و Explainability را مالک است. prerequisiteهای فریز‌شده MKN-017 (hard) و MKN-018 (soft) هستند. MKN-018 استخراج role/competency و job-skill را مالک است و MKN-020 event taxonomy را؛ این درس از evidence محدود آن‌ها استفاده می‌کند ولی outcome آن‌ها را جذب نمی‌کند.

مسیر Foundation با field map و یک case کارآموزی synthetic شروع می‌شود. مسیر Repair اولین evidence dimension خراب را جدا می‌کند و فقط همان gate را rerun می‌کند. مسیر Experienced باید feature admissibility، slice، explanation، accommodation، uncertainty و human escalation را بدون پنهان‌کردن در یک «fairness score» دفاع کند.

Checkpointها: F1 تفاوت eligibility/ranking و یک non-goal؛ F2 رد feature‌ای که job-relevance evidence آن حذف شده حتی اگر accuracy ثابت باشد؛ F3 recompute کامل وقتی matcher برای پروژهٔ low-stakes learning community استفاده می‌شود.

مدل ذهنی: criteria → evidence مجاز → score محدود → fairness/error review → reason → human decision

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

opportunity criteria → eligibility evidence → feature admissibility/job relevance → score + uncertainty → reviewed slices and error evidence → reason codes + evidence refs → accommodation/alternative path → human review → match/defer/reject + appeal/correction trail

Eligibility می‌گوید آیا rule مستقل و قابل‌بازرسی برقرار است. Ranking بین candidateهای eligible یا potentially eligible ترتیب ایجاد می‌کند. اگر این دو یکی شوند، یک signal ضعیف ranking می‌تواند بی‌صدا تبدیل به exclusion rule شود.

Feature فقط چون accuracy را بهتر کرده admissible نیست. باید feature_source_ref، job_relevance_basis، proxy_risk و policy روشن برای sensitive attributes داشته باشد. اگر candidate مسیر accessible دیگری خواست، نبودن interview-derived signal نباید negative evidence تلقی شود.

Non-success stateها بخشی از design هستند: HUMAN_REVIEW_REQUIRED، HOLD_JOB_RELEVANCE_EVIDENCE، HOLD_PROXY_RISK، HOLD_ACCOMMODATION_PATH، HOLD_FAIRNESS_SLICE_REVIEW، HOLD_EXPLANATION_EVIDENCE، HOLD_AUTONOMOUS_ADVERSE_DECISION، HOLD_UNCERTAINTY، HOLD_PROVENANCE، HOLD_SENSITIVE_ATTRIBUTE_POLICY و HOLD_INSUFFICIENT_EVIDENCE.

قرارداد پایه: بیست evidence dimension پیش از تصمیم bounded

dimensionهای فریز‌شده: match_case_id، opportunity_ref، eligibility_rule_ref، feature_id، feature_source_ref، job_relevance_basis، proxy_risk، accommodation_path، model_version، score، rank، uncertainty_label، slice_definition، outcome_metric، error_metric، fairness_review_state، reason_code، reason_evidence_ref، human_review_state و provenance.

Invariantهای اصلی:

1. Eligibility و ranking جدا هستند. feature ranking نباید eligibility جدید بسازد.
2. Feature decisive lineage دارد. ID، source، job relevance و model version ثبت می‌شوند.
3. Proxy risk visible می‌ماند. signal ظاهراً خنثی در صورت relevance نامعلوم یا proxy risk حل‌نشده block/escalate می‌شود.
4. Sensitive-attribute policy صریح است. سیستم برای explanation یا decision واقعی protected/sensitive trait را استنباط نمی‌کند.
5. Accommodation penalty نیست. مسیر alternative assessment باید وجود داشته باشد و missing inaccessible signal نباید standing را کم کند.
6. Score/rank همراه uncertainty است. دقت عددی بالا مساوی certainty تصمیم نیست.
7. Fairness review به slice/failure mode مرتبط نگاه می‌کند. aggregate accuracy نباید error materially different را پنهان کند.
8. Reason code به evidence bind می‌شود. «مدل شما را fit ضعیف‌تری می‌داند» explanation کافی نیست.
9. Human review gate واقعی است. adverse high-impact result صرفاً با threshold مدل final نمی‌شود.
10. Appeal/correction و provenance recoverable هستند. reviewer باید model/evidence/policy دقیق را بازسازی کند.

توضیح عمیق: راهنمای fairness نسخهٔ universal threshold نیست

NIST AI RMF. منابع جاری NIST همچنان trustworthiness را با characteristicهایی مثل valid/reliable، accountable/transparent، explainable/interpretable، privacy-enhanced و fair with harmful bias managed توضیح می‌دهند. NIST همچنین می‌گوید AI RMF 1.0 voluntary است و در حال revision قرار دارد. پس MAKNOW آن را risk-management boundary می‌گیرد، نه certification عدالت یک matcher.

EEOC و AI/ADA. منابع رسمی EEOC همچنان هشدار می‌دهند ابزارهای الگوریتمی employment ممکن است افراد دارای disability را اشتباه screen out کنند و reasonable accommodation می‌تواند لازم باشد. در case این درس، ناتوانی در یک modality غیرقابل‌دسترس نباید evidenceِ ناتوانی در job capability تلقی شود.

Inference MAKNOW. explanation قابل‌بررسی باید eligibility/ranking reason و uncertainty را به evidence وصل کند. Fairness review نیز باید slice و failure mode materially relevant را بررسی کند، نه اینکه global accuracy را معادل fairness بداند. انتخاب metric/slice/threshold context-dependent است.

Design authority MAKNOW. feature allowlist، proxy rule، impact class، threshold review، jurisdiction mapping، reason-code vocabulary، accommodation workflow و escalation trigger همگی policy داخلی‌اند؛ NIST/EEOC product authority یا legal verdict تولید نمی‌کنند.

مثال‌های حل‌شده

مثال A — baseline کارآموزی

فرصت به دو competency فنی verified نیاز دارد. Matcher از verified skill evidence، portfolio quality، course completion time و interview-derived communication style استفاده می‌کند. سه مورد اول source روشن دارند؛ signal ارتباطی job relevance ضعیف و proxy risk بالاتری دارد. یک applicant هم alternative non-video assessment درخواست می‌کند.

Record درست applicant را حذف نمی‌کند، missing video را صفر نمی‌گذارد و score را decision نمی‌گیرد. Feature مشکوک را review/exclude می‌کند، accommodation path را ثبت می‌کند، score/rank/uncertainty را visible نگه می‌دارد و روی HUMAN_REVIEW_REQUIRED می‌ایستد.

مثال B — accuracy ثابت ولی evidence حذف شده

فرض کنید aggregate accuracy بعد از حذف سند job relevance یک feature تغییر نکند. Performance model ثابت است ولی evidence contract خراب شده؛ نتیجه HOLD_JOB_RELEVANCE_EVIDENCE است. Accuracy نمی‌تواند دلیل استفاده از feature را جایگزین کند.

مثال C — false-negative متفاوت در یک slice

اگر یک slice با governance مناسب error materially different نشان دهد، آن را زیر global accuracy پنهان نکنید. slice_definition، outcome/error metric و limitationها را ثبت کنید و state را HOLD_FAIRNESS_SLICE_REVIEW کنید تا علت، data adequacy، threshold یا alternative assessment بررسی شود.

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

• score مستقیم adverse result می‌سازد → HOLD_AUTONOMOUS_ADVERSE_DECISION
• job-relevance evidence گم است ولی feature به‌خاطر accuracy می‌ماند → HOLD_JOB_RELEVANCE_EVIDENCE
• proxy risk حل‌نشده است → HOLD_PROXY_RISK
• missing inaccessible signal به penalty تبدیل می‌شود → HOLD_ACCOMMODATION_PATH
• slice error materially different نادیده گرفته می‌شود → HOLD_FAIRNESS_SLICE_REVIEW
• narrative fluent ولی بدون evidence ref است → HOLD_EXPLANATION_EVIDENCE
• uncertainty پنهان شده → HOLD_UNCERTAINTY
• sensitive-attribute policy missing/violated است → HOLD_SENSITIVE_ATTRIBUTE_POLICY
• provenance ناقص است → HOLD_PROVENANCE
• baseline employment state به context جدید کپی می‌شود → HOLD_BASELINE_ORACLE_REUSE

Alternative و trade-off؛ نه یک fairness number

Eligibility rule-based + ranking model. Eligibility inspectable می‌ماند ولی ranking هنوز feature/fairness governance می‌خواهد. مزیتش این است که hard constraint در score مخفی نمی‌شود.

Eligibility rule-based + بدون automated ranking. audit ساده‌تر است ولی scalability پایین‌تر می‌شود و rule انسانی هم می‌تواند unfair باشد. Human-only خودکار fair نیست.

Model ranking + human review queue. فقط وقتی مفید است که reviewer evidence، uncertainty، reason code، accommodation و appeal را ببیند. Rubber-stamp review کافی نیست.

Slice metric. می‌تواند error difference را آشکار کند ولی sample کوچک، label quality، selection bias، lawful access و multiple comparison می‌تواند نتیجه را INCONCLUSIVE کند. در این حالت state را قوی‌تر نکنید.

Explanation. Feature attribution یا متن model برای debugging مفید است؛ اما decision reason باید به criterion/evidence واقعی bind باشد. Fluent text proof عدالت نیست.

پل مسیر Experienced: سه تفکیک حیاتی

اول prediction quality را از decision legitimacy جدا کنید. Accuracy/AUC/ranking quality نمی‌گوید feature برای این opportunity مجاز یا relevant است یا accommodation رعایت شده.

دوم fairness-risk measurement را از fairness verdict جدا کنید. Slice metric evidence است و assumptionهای sampling/policy دارد؛ trigger investigation است، نه certification جهانی.

سوم model explanation را از decision reason جدا کنید. اولی mechanism/model را توضیح می‌دهد؛ دومی criterion/evidence مربوط به outcome را برای reviewer/user روشن می‌کند.

Stop condition: اگر job relevance، accommodation، proxy risk، slice/error، uncertainty، reason evidence، human review یا provenance decisive ناقص باشد، record نمی‌تواند final adverse state بگیرد.

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

Guided. lab://MKN-019/MKN-019-LAB1 را باز کنید. baseline synthetic را بخوانید و eligibility rule، feature source، job relevance، proxy risk، accommodation، model version، score/rank/uncertainty، slice/error evidence، reason code/evidence، human review و provenance را verify کنید. بالاترین state baseline فقط HUMAN_REVIEW_REQUIRED است؛ lab هیچ تصمیم employment واقعی را auto-final نمی‌کند.

Repair. هر بار فقط یک mutation: job-relevance evidence را حذف کنید ولی accuracy را ثابت بگذارید؛ accommodation را حذف کنید؛ reason code evidence-bound را با generic narrative عوض کنید. کوچک‌ترین dimension خراب باید state را عوض کند.

Independent. Transfer fixture را بدون دیدن baseline decision label از صفر بسازید. Matcher حالا برای contributor recommendation در یک learning community کم‌ریسک استفاده می‌شود. impact، feature، fairness review، explanation و escalation را recompute کنید؛ workflow استخدام را کپی نکنید.

Verification evidence؛ reviewer چه چیزی را باید بازسازی کند؟

Reviewer باید فقط از record بتواند پاسخ دهد:

1. opportunity و eligibility rule چه بودند؟
2. چه featureهایی وارد ranking شدند و source/job relevance آن‌ها چیست؟
3. کدام feature به‌خاطر proxy risk/relevance block یا escalate شد؟
4. accommodation لازم بود؟ missing inaccessible signal penalty شد یا نه؟
5. کدام model/version score/rank را داد و uncertainty چیست؟
6. کدام slice/error بررسی شد و limitation چیست؟
7. reason codeها چه هستند و به کدام evidence ref وصل‌اند؟
8. human review انجام شده و appeal/correction traceable است؟
9. provenance model/evidence/policy دقیق را recover می‌کند؟

اگر پاسخ decisive گم باشد، state باید non-success بماند. Verification یعنی reproducible evidence trail، نه بازتولید hidden model reasoning.

Assessment و Transfer

S1 — retrieval: boundary MKN-019 و یک non-goal را توضیح دهید. S2 — application: Fair Matching Decision & Explanation Record v1 را برای fixture کارآموزی بسازید. S3 — diagnosis: job-relevance evidence یک feature را حذف کنید درحالی‌که aggregate accuracy ثابت است؛ dimension خراب و repair حداقلی را نام ببرید. S4 — transfer: matcher را برای low-stakes learning-community project بازطراحی کنید و impact/features/review/explanation/escalation را از evidence جدید recompute کنید.

Blocking misconception: «اگر model دقیق باشد، score آن خودکار fair، explainable و مجوز decision است.»

AI می‌تواند synthetic evidence را organize و deterministic check را اجرا کند؛ حق ندارد job relevance بسازد، protected trait استنباط کند، accommodation evidence جعل کند، compliance حقوقی اعلام کند یا human reviewer را در adverse career decision جایگزین کند.

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

• NIST AI RMF / AIRC — FACT: characteristicهای جاری trustworthiness شامل explainable/interpretable و fair with harmful bias managed هستند. AI RMF 1.0 framework منتشرشده است و NIST اعلام کرده revision در جریان است. این منبع fairness certificate یا threshold MAKNOW نمی‌دهد.
• EEOC AI/ADA — FACT، محدود به حوزهٔ حقوقی آمریکا: منابع فعلی خطر screen-out افراد دارای disability و ضرورت accommodation در contextهای covered را یادآوری می‌کنند. Workflow جهانی compliance تعریف نمی‌کنند.
• Inference MAKNOW: explanation باید reason را به evidence/uncertainty bind کند و fairness review باید failure modeهای materially relevant را ببیند.
• Design MAKNOW: feature admissibility، proxy policy، slice/threshold، reason code، accommodation، human escalation و jurisdiction mapping authority داخلی‌اند.

Freshness در 2026-09-13 بررسی شد. موعد re-review: 2027-01-15 یا زودتر در صورت تغییر material در NIST/EEOC، employment-law interpretation، fairness risk یا explanation practice. Accepted bytes بی‌صدا mutate نمی‌شوند؛ تغییر freshness به version/checkpoint جدید نیاز دارد.