Talent Profile و Capability Evidence

1) مسئله: پروفایل استعداد با مدرک توانمندی یکی نیست

پروفایل حرفه‌ای خیلی راحت به یک «بیوی بازاریابی» تبدیل می‌شود: فرد می‌گوید در ویدئوی محصول، تبلیغات پولی و تحلیل داده قوی است؛ چند نمونه‌کار، یک badge و چند نظر هم کنار آن قرار می‌گیرد. مشکل اینجاست که این چیزها هم‌ارز نیستند. ادعا، مشاهده، مدرک تأییدشده و نظر داور باید جدا بمانند.

هدف این درس ساخت Talent Capability Evidence Profile v1 است؛ پروفایلی که برای هر capability نشان دهد چه چیزی ادعا شده، چه مدرکی وجود دارد، چه کسی آن را صادر یا بررسی کرده، در چه contextی دیده شده، چقدر تازه است، چه تعارضی دارد و برای assignment فعلی چقدر مرتبط است.

قاعدهٔ مرکزی: کامل‌بودن ظاهری پروفایل هرگز یک ادعای بدون شاهد را به قابلیت تأییدشده تبدیل نمی‌کند.

2) مرز درس

COM-021 مالک «پروفایل قابلیت و شواهد آن» است. COM-020 onboarding را پوشش می‌دهد و COM-022 vetting/test job را. این درس نه hiring verdict می‌دهد، نه قرارداد زنده می‌بندد و نه credential را به‌تنهایی معادل صلاحیت برای assignment می‌گیرد.

3) مدل ذهنی: Claim → Evidence → Verification → Context → Relevance

یک capability را با یک label کلی مثل «Advanced Analytics» ذخیره نکن. آن را به زنجیرهٔ قابل‌ردیابی تبدیل کن:

1. Claim — چه کسی چه قابلیتی را ادعا می‌کند؟
2. Evidence object — شاهد دقیق چیست و locator آن کجاست؟
3. Issuer / reviewer — چه کسی مدرک را صادر یا مشاهده کرده؟ نقش او چیست؟
4. Verification — چگونه صحت یا اصالت همان evidence بررسی شده؟
5. Context + level — قابلیت در چه محیط و سطحی مشاهده شده؟
6. Date + freshness — شاهد مربوط به چه زمانی است و هنوز قابل‌اتکاست؟
7. Scope limit — این شاهد چه چیزی را ثابت نمی‌کند؟
8. Assignment relevance — برای assignment جاری مرتبط است یا نه؟
9. Conflict — آیا شاهد تازه‌تر یا معتبر دیگری آن را نقض می‌کند؟

4) وضعیت‌ها را با هم قاطی نکن

در این درس بین وضعیت‌های capability فرق می‌گذاریم:

• CLAIMED: صرفاً ادعا شده است.
• OBSERVED: در یک context مشخص مشاهده شده، اما الزاماً مستقل یا تأییدشده نیست.
• VERIFIED: evidence و issuer/reviewer لازم برای همان claim بررسی شده‌اند.
• CONFLICTED: شواهد معتبر با هم ناسازگارند.
• STALE: مدرک قدیمی یا context آن دیگر برای تصمیم جاری معتبر نیست.
• NOT_RELEVANT: ممکن است مدرک درست باشد، ولی به assignment جاری ربط ندارد.

این وضعیت‌ها «امتیاز اعتماد» نیستند. مخصوصاً CONFLICTED را با میانگین‌گیری حذف نکن.

5) W3C چه چیزی به ما می‌دهد و چه چیزی نمی‌دهد؟

W3C Verifiable Credentials Data Model v2.0 یک مدل برای بیان مجموعه‌ای از claimها از سوی issuer درباره subject ارائه می‌کند و برای دادهٔ credential ماشین‌قابل‌بررسی طراحی شده است. خانوادهٔ VC 2.0 در ۱۵ مه ۲۰۲۵ به W3C Recommendation رسید. این برای ما یک الگوی خوبِ provenance و issuer/holder/verifier است، اما W3C نمی‌گوید یک credential به‌تنهایی فرد را برای assignment ما مناسب می‌کند.

در سپتامبر ۲۰۲۶، v2.0 همچنان Recommendation است و v2.1 نیز به‌صورت Working Draft منتشر شده است. پس نسخه و status منبع را دقیق ثبت کن؛ Working Draft را خودکار جای Recommendation جا نزن.

6) مثال پایه

فرض کن Talent T-21 سه claim دارد: Product Video، Paid Social و Analytics.

• Product Video: دو نمونه‌کار دارد، ولی ۳ سال قدیمی‌اند و context آن‌ها studio-controlled است.
• Paid Social: یک badge خوداظهاری دارد و issuer مستقلی ندارد.
• Analytics: یک reviewer note از پروژه‌ای واقعی دارد، اما vertical آن با assignment جدید متفاوت است.

نتیجهٔ درست یک label واحد مثل «Strong Creator» نیست. باید هر capability جداگانه محاسبه شود. ممکن است Product Video = STALE، Paid Social = CLAIMED و Analytics = OBSERVED/PARTIAL باشد. سپس assignment relevance جداگانه تعیین می‌شود.

7) shortcutهای خطرناک

Shortcut A — badge یعنی VERIFIED

غلط است. اگر issuer، evidence object یا verification method نداریم، state را ارتقا نمی‌دهیم.

Shortcut B — portfolio خوب یعنی مناسب هر assignment

غلط است. یک نمونه‌کار می‌تواند واقعی و قوی باشد ولی برای context جدید NOT_RELEVANT یا STALE باشد.

Shortcut C — تعارض را با average score حل کنیم

غلط است. اگر credential یک capability را تأیید کند اما work sample تازه خلاف آن را نشان دهد، باید CONFLICTED ثبت شود تا reviewer علت اختلاف را بررسی کند.

8) Evidence Contract

حداقل فیلدهای این درس عبارت‌اند از: talent_id, capability_id, capability_label, claim_type, evidence_id, evidence_type, evidence_locator, issuer_or_reviewer, issuer_role, verification_method, observed_context, observed_level, evidence_date, freshness_state, scope_limit, assignment_relevance, conflict_state, privacy_visibility, owner, evidence_ref.

فیلدهای بحرانی بدون مقدار معتبر نباید به VERIFIED یا تصمیم مثبت منجر شوند.

9) Conflict handling

وقتی دو evidence با هم تضاد دارند:

1. هر دو را نگه دار؛ evidence منفی را حذف نکن.
2. recency، context، issuer/reviewer و verification method هر کدام را مقایسه کن.
3. تا حل تعارض state را CONFLICTED / DISPUTED نگه دار.
4. فقط capability مرتبط با تعارض را متوقف کن؛ کل talent را بدون دلیل رد نکن.
5. assignment decision را دوباره محاسبه کن.

10) آزمایش عملی

در Lab یک fixture آفلاین می‌بینی. evaluator از تو می‌خواهد برای هر رکورد state محدود تولید کنی. mutationهای مهم:

• حذف issuer از یک evidence؛
• استفادهٔ مجدد از نمونه‌کار قدیمی بعد از تغییر context assignment؛
• تبدیل self-claim به VERIFIED بدون evidence object؛
• پنهان‌کردن observation متناقض.

انتظار سیستم این نیست که حتماً پاسخ مثبت بدهی؛ انتظار این است که شواهد ناکافی را به UNKNOWN/HOLD/PARTIAL/DISPUTED/STALE تبدیل کنی.

11) تمرین انتقال

یک credential تازه و قابل‌اعتبارسنجی، capability «Analytics» را تأیید می‌کند؛ همزمان یک work sample بسیار تازه نشان می‌دهد capability «Paid Social» در context جدید ضعیف است. پروفایل را از نو محاسبه کن. credential جدید نباید contradiction capability دیگر را پاک کند و نتیجهٔ assignment باید فقط بر evidence مرتبط تکیه کند.

12) چک‌لیست تصمیم

قبل از اینکه capability را برای assignment قابل‌اتکا بدانی، بپرس:

• claim دقیقاً چیست؟
• evidence object مستقل داریم؟
• issuer/reviewer مشخص و مناسب است؟
• verification method ثبت شده؟
• context و level روشن است؟
• evidence تازه است؟
• scope limit چیست؟
• assignment relevance واقعاً برقرار است؟
• evidence متناقضی وجود ندارد؟
• privacy visibility و owner مشخص‌اند؟

اگر پاسخ یکی از موارد بحرانی نامعلوم است، state مثبت نساز.

13) جمع‌بندی

پروفایل استعداد خوب یک صفحهٔ تبلیغاتی نیست؛ دفتر شواهد قابل‌ردیابی برای capabilityهاست. ادعا و شاهد را جدا کن، provenance را نگه دار، تازگی و context را ثبت کن، تعارض را مخفی نکن و relevance را برای هر assignment دوباره بسنج. خروجی این درس یک Talent Capability Evidence Profile v1 است که از تصمیم انسانی پشتیبانی می‌کند، نه اینکه آن را جایگزین کند.

منابع و تازگی

• W3C, Verifiable Credentials Data Model v2.0 — Recommendation, 15 May 2025.
• W3C News, Verifiable Credentials 2.0 family — 15 May 2025.
• Freshness recheck: 2026-09-15. وجود VC Data Model v2.1 Working Draft ثبت شد؛ این وضعیت، Recommendation بودن v2.0 را لغو نمی‌کند.