Vetting و Test Job

تست سخت، لزوماً تست خوب نیست

سه نفر برای یک نقش تولید محتوای تبلیغاتی وارد Test Job می‌شوند. نفر اول brief نسخه 3 را می‌گیرد، نفر دوم یک فایل متفاوت با قیدهای اضافه می‌بیند و هیچ version ثبت نمی‌شود، نفر سوم خروجی بسیار زیبا تحویل می‌دهد اما constraint اصلی conversion را رعایت نمی‌کند. اگر فقط «کیفیت ظاهری» یا یک نمره نهایی را ذخیره کنیم، نمی‌فهمیم دقیقاً چه قابلیتی سنجیده شده، آیا شرایط قابل‌مقایسه بوده و کدام evidence واقعاً از تصمیم پشتیبانی می‌کند. خروجی این درس Vetting Test-Job Evidence Matrix v1 است.

مرز مالکیت این درس

COM-022 فقط طراحی و ارزیابی یک vetting/test-job محدود را مالک است. تعریف Talent Profile و سابقه capability متعلق به COM-021 است؛ اینکه فرد بعداً چه assignment و مسئولیتی می‌گیرد متعلق به COM-023 است. این درس نه استخدام واقعی انجام می‌دهد، نه درباره worker status یا قانون همه کشورها حکم می‌دهد، نه payment یا production assignment را تغییر می‌دهد.

مدل ذهنی: از role شروع کن، نه از «تست جذاب»

ترتیب درست این است:

role requirements → bounded test design → equivalent brief → work sample → rubric evidence → reviewer conflict/adverse-signal check → human decision or HOLD

شش سؤال را همیشه جدا نگه دار: چه قابلیتی لازم است؟ کدام task آن را می‌سنجد؟ آیا instruction/زمان/tool واقعاً قابل‌مقایسه‌اند؟ rubric قبل از scoring چه بوده؟ reviewer چه authority/conflictی دارد؟ و آیا evidence به‌اندازه کافی قوی هست که فقط پرونده را به تصمیم انسانی برساند؟

FACT، INFERENCE و DESIGN را مخلوط نکن

FACT: راهنمای رسمی EEOC در آمریکا، sample job taskهایی مثل performance test، simulation، work sample و realistic job preview را از انواع ابزارهای selection می‌داند. همان راهنما روی job-related بودن و validation مناسب برای position/purpose تأکید می‌کند و درباره discrimination، adverse impact و accommodation هشدار می‌دهد. INFERENCE: برای audit بهتر، capability target، instruction version، rubric version، reviewer و negative evidence باید از verdict نهایی جدا ثبت شوند. DESIGN: stateهای READY_FOR_HUMAN_DECISION, HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, BLOCKED و قواعد fail-closed این درس طراحی MAKNOW هستند. این stateها قانون یا واژگان EEOC نیستند.

قرارداد ۲۱بُعدی Vetting Matrix

1) identity: case، role، candidate و test

vetting_case_id, role_or_assignment_id, candidate_id و test_job_id باید روشن باشند. بدون role binding، یک score زیبا ولی بی‌ربط می‌تواند به‌اشتباه تبدیل به evidence استخدامی شود.

2) scope و capability targets

task_scope باید کوچک، قابل‌تحویل و متناسب با capability واقعی نقش باشد. capability_targets می‌گوید دقیقاً چه چیزی سنجیده می‌شود. هر rubric dimension باید به یکی از این targetها برگردد؛ «سلیقه شخصی reviewer» capability نیست مگر از قبل تعریف و توجیه شده باشد.

3) instruction، timebox، tools و adjustment

instructions_version, timebox و allowed_tools شرایط اجرای تست را بازسازی‌پذیر می‌کنند. equivalence یعنی تفاوت‌های مادی پنهان نباشند؛ به معنی یکسان‌سازی کورکورانه نیازهای دسترسی نیست. accessibility_adjustments باید امکان adjustment مناسب را ثبت کند بدون اینکه جزئیات حساسِ غیرضروری وارد evidence عمومی شود.

4) compensation/policy boundary

compensation_policy_ref باید روشن کند این Test Job تحت کدام سیاست compensation/contracting انجام می‌شود. اگر applicability، worker status یا jurisdiction مبهم است، سیستم نباید حدس بزند: HOLD و escalation انسانی/حقوقی لازم است.

5) rubric باید قبل از taste بیاید

rubric_version و rubric_dimensions قبل از scoring قفل می‌شوند. score_evidence باید نشان دهد هر نمره از کدام observable evidence آمده است. اگر reviewer بعداً بگوید «این رنگ را دوست ندارم» ولی aesthetic preference در rubric نبوده، آن نظر می‌تواند feedback باشد اما حق ندارد score رسمی را مخفیانه عوض کند.

6) reviewer، conflict و adverse signal

reviewer_id و reviewer_role مشخص می‌کنند چه کسی ارزیابی کرده است. conflict_state اختلاف reviewerها یا conflict of interest را نگه می‌دارد. adverse_signal هم برای نشانه‌هایی است که نیازمند بررسی انسانی‌اند؛ وجود چنین سیگنالی به‌تنهایی proof discrimination یا proof unfairness نیست، اما پاک‌کردنش از evidence مجاز نیست.

7) decision و retention

decision_state باید قدرتی بیشتر از evidence نداشته باشد. READY_FOR_HUMAN_DECISION یعنی پرونده از نظر evidence آماده بررسی انسان است؛ به معنی hire/accept نیست. retention_rule و evidence_ref نیز مشخص می‌کنند چه چیزی، تا چه زمانی و با چه provenanceای نگه داشته می‌شود.

مثال‌های کاری

۱. baseline معتبر → READY_FOR_HUMAN_DECISION

هر سه candidate یک brief versioned با capability targets یکسان، timebox و tools روشن می‌گیرند. adjustment لازم ثبت می‌شود، rubric قبل از submission معلوم است، reviewer conflict ندارد و score فقط از rubric evidence می‌آید. پرونده می‌تواند برای تصمیم انسانی آماده شود.

۲. instruction متفاوت و بدون version → HOLD

یکی از candidateها constraint اضافه‌ای گرفته است اما سیستم هنوز همه را instructions_version=v3 نشان می‌دهد. مقایسه قابل‌اعتماد نیست. اول تفاوت را version کن، materiality آن را بررسی کن و در صورت لزوم re-test یا normalized review انجام بده.

۳. taste خارج از rubric → HOLD

خروجی conversion constraint را رعایت کرده، اما reviewer صرفاً به‌دلیل پسند شخصی رنگ، score را کم می‌کند. تا زمانی که scoring دوباره به rubric declared برنگشته، verdict bounded نیست.

۴. role عوض شده ولی score قبلی reuse می‌شود → STALE

یک creative test شاید برای performance marketer جدید job-relevant نباشد. identity و audit history می‌توانند بمانند، اما test/rubric/score باید متناسب با role جدید بازطراحی شوند.

۵. reviewer conflict حل‌نشده → DISPUTED

دو reviewer روی یک rubric dimension با evidence متفاوت به نتایج متضاد رسیده‌اند. اختلاف باید visible بماند و resolution rule اعمال شود؛ میانگین‌گیری خودکار جای حل conflict را نمی‌گیرد.

۶. compensation یا jurisdiction نامعلوم → HOLD

سیستم نمی‌تواند با یک checkbox فنی تعیین کند test job از نظر compensation یا worker status در همه کشورها مجاز است. policy/legal applicability باید توسط authority انسانی مناسب تعیین شود.

failure modeهای رایج

• «چون همه تست داده‌اند، پس تست منصفانه است»؛ در حالی که instruction یا tools متفاوت بوده‌اند.
• سختی task را با job relevance اشتباه می‌گیریم.
• یک score واحد را به‌عنوان proof عمومیِ قابلیت‌های آینده reuse می‌کنیم.
• rubric را بعد از دیدن output تغییر می‌دهیم.
• preference خارج از rubric را داخل score می‌چپانیم.
• adjustment را حذف می‌کنیم تا record «یکدست» به نظر برسد.
• reviewer conflict یا adverse signal را پشت average score پنهان می‌کنیم.
• compensation/jurisdiction ambiguity را با حدس پر می‌کنیم.
• READY_FOR_HUMAN_DECISION را با hire/accept خودکار یکی می‌گیریم.

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

Portfolio-only: friction کمی دارد، اما شرایط تولید و capabilityهای موردنیاز role جدید را همیشه نشان نمی‌دهد. Bounded work sample + rubric: evidence مستقیم‌تر و قابل‌ممیزی‌تر می‌دهد، ولی هزینه طراحی، compensation/policy review و reviewer calibration دارد. Large speculative project: ممکن است «واقعی» به نظر برسد، اما scope، fairness، compensation و leakage ارزش کاری را سخت‌تر می‌کند؛ برای این outcome انتخاب ضعیفی است. Automated ranking: برای triage عددی مفید است، اما human decision authority و negative evidence را نباید حذف کند.

پل برای فرد باتجربه: ۱۵ سؤال critical

آیا role روشن است؟ test واقعاً به capabilityهای role وصل است؟ scope محدود است؟ instruction version دارد؟ تفاوت مادی بین candidateها ثبت شده؟ timebox روشن است؟ tools مجاز روشن‌اند؟ adjustment record حداقلِ لازم را حفظ کرده؟ compensation policy ref موجود است؟ rubric از قبل version شده؟ هر score evidence دارد؟ reviewer و role او معلوم است؟ adverse signal حذف نشده؟ conflict state روشن است؟ و decision فقط پرونده را به human review می‌رساند، نه اینکه از یک تست «حقیقت نهایی» بسازد؟

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

ابتدا baseline fixture را با هر ۲۱ فیلد کامل کن. بعد چهار mutation را اجرا کن: instruction متفاوت بدون version، preference خارج از rubric، پاک‌کردن adjustment record و reuse score برای role جدید. برای هر mutation فقط سه چیز بنویس: کدام evidence شکست، state جدید چیست، و کوچک‌ترین repair قابل‌دفاع چیست. سپس همین منطق را روی یک role متفاوت اجرا کن و test را از نو انتخاب کن.

evidence قابل‌قبول

حداقل evidence قابل‌قبول شامل case/role/candidate/test identity، capability targets، instruction version، timebox، rubric version/dimensions، reviewer identity، score evidence، adverse signal، conflict state، decision state و evidence reference است. compensation policy، allowed tools، adjustment و retention نیز باید به‌اندازه‌ای ثبت شوند که تصمیم قابل بازسازی باشد. hidden reasoning، سلیقه ثبت‌نشده یا score بدون provenance جای evidence را نمی‌گیرد.

Assessment و transfer

برای قبولی باید چهار چیز را نشان دهی: مرز COM-022، baseline matrix کامل، diagnosis یک instruction mismatch و transfer به role جدید. در transfer، score قبلی oracle نیست. فقط evidenceای حمل می‌شود که واقعاً role-independent است؛ relevance، task، rubric و score برای role جدید دوباره ساخته می‌شوند. success در این درس یعنی READY_FOR_HUMAN_DECISION، نه تصمیم خودکار درباره انسان.

منابع و freshness

• U.S. EEOC — Employment Tests and Selection Procedures. در 2026-09-15 دوباره بررسی شد. صفحه همچنان sample job tasks/work samples را در selection procedures می‌آورد و روی job-relatedness/validation، discrimination/adverse impact و accommodation تأکید دارد: https://www.eeoc.gov/laws/guidance/employment-tests-and-selection-procedures
• این منبع راهنمای فنی EEOC درباره قوانین فدرال آمریکا است و خودش هم تصریح می‌کند متن، به‌تنهایی force of law مستقل ندارد. برای کشور، قرارداد یا worker status دیگر باید authority حقوقی مرتبط بررسی شود.
• state vocabulary و rules این درس MAKNOW DESIGN هستند. منبع EEOC آن‌ها را تعریف نکرده است.
• claimهای legal/policy-current تا 2026-11-02 یا زودتر پس از تغییر مادی منبع دوباره بررسی می‌شوند.