Competency Taxonomy و Prerequisite Graph

مسئله‌ی واقعی

فهرست درس‌ها و ترتیب نمایش آن‌ها یک competency model نیست. اگر «درس A قبل از درس B» را به‌طور خودکار prerequisite فرض کنیم، یک جابه‌جایی editorial می‌تواند مسیر یادگیری را بی‌دلیل باز یا بسته کند. هدف این درس ساخت Competency Taxonomy & Prerequisite Graph Contract v1 است تا identity مهارت، رابطه‌ی جهت‌دار، نوع edge و evidence لازم برای closure صریح و قابل audit باشند.

خروجی باید بتواند توضیح دهد «چرا این مسیر باز است؟»، «چرا بسته است؟» و «کدام evidence می‌تواند edge را ببندد؟» بدون تکیه به ترتیب صفحه.

مرز درس

MKN-003 مالک taxonomy و prerequisite graph است. MKN-002 درباره طراحی تجربه‌ی پروژه/JIT است و MKN-004 درباره تاریخچه‌ی mastery؛ این lesson هیچ‌کدام را جذب نمی‌کند.

سه اصل مرزی: content order ≠ competency dependency، edge ≠ mastery، و equivalence ≠ identity merge.

مدل ذهنی: Node + Typed Edge + Closure

هر competency یک identity پایدار در یک framework دارد. هر dependency یک edge مستقل با edge_id، جهت prerequisite → child، edge_type، strength، evidence condition و version است. closure یک state مشتق‌شده از evidence است، نه ویژگی دائمی خود edge.

برای unknown یا dispute از stateهای typed استفاده می‌کنیم؛ سیستم نباید خلأ evidence را به «satisfied» تبدیل کند.

قرارداد ۱۶ بُعدی

Artifact اصلی این فیلدها را نگه می‌دارد: framework، competency، statement، taxonomy level، edge، type، prerequisite، child، strength، evidence condition، closure، equivalent evidence، bridge، cycle، version و provenance.

competency_id و edge_id باید پایدار باشند. statement قابل ویرایش است اما identity نباید با تغییر متن عوض شود. version باید تغییر semantics رابطه یا statement را قابل ردیابی کند.

چرا ترتیب و شباهت متن authority نیستند؟

ترتیب محتوا برای UX و pedagogy مفید است، اما dependency باید edge صریح داشته باشد. تغییر ترتیب lesson بدون تغییر graph نباید prerequisite را عوض کند.

دو statement شبیه هم نیز لزوماً یک competency نیستند. در import یک framework خارجی، identityهای متفاوت حفظ می‌شوند و alignment/equivalence به‌صورت reference ثبت می‌شود. اگر equivalence صرفاً از شباهت متن حدس زده شده باشد، closure باید HOLD بماند.

CASE برای exchange استاندارد competency frameworkها، itemها و associationها سازوکار می‌دهد؛ این lesson semantics محلی hard/recommended/bridge و closure را جداگانه تحت authority MAKNOW تعریف می‌کند.

مثال پایه

فرض کنید CMP-FUNC پیش‌نیاز سخت CMP-TEST است. edge EDGE-101 جهت CMP-FUNC → CMP-TEST دارد و شرط closure آن evidence مستقل از competency پایه است. learner evidence معتبر دارد؛ پس state می‌تواند ROUTE_AVAILABLE_HARD_CLOSED باشد.

حالا فقط lessonها را در UI جابه‌جا کنید. چون edge تغییر نکرده، dependency تغییر نمی‌کند. در transfer، competency خارجی EXT-FUNC-A wording مشابه دارد اما ID متفاوت است؛ با association بررسی‌شده می‌تواند برای یک edge recommended معادل evidence بدهد، بدون merge کردن IDها.

خطاهای پرتکرار

1. Display-order inference: ترتیب صفحه را graph فرض می‌کند.
2. Direction blindness: A→B و B→A را معادل می‌گیرد.
3. Hard-edge inflation: completion یا activity ضعیف را evidence کافی برای hard prerequisite می‌گیرد.
4. Text-similarity merge: competencyهای دو framework را فقط به‌خاطر متن شبیه یکی می‌کند.
5. Cycle blindness: cycle سه‌گرهی را route معتبر می‌داند.
6. Version amnesia: semantics edge عوض می‌شود ولی version/provenance ثابت می‌ماند.

Hard، Recommended، Equivalent و Bridge

HARD_PREREQUISITE تا evidence معتبر بسته نشود route را block می‌کند. RECOMMENDED advisory است و نبود آن می‌تواند route را باز نگه دارد اما gap را visible کند. equivalent evidence فقط وقتی معتبر است که relation و provenance آن governed باشد. BRIDGE مسیر repair/آماده‌سازی است، نه جعل closure.

همه‌ی این‌ها policy محلی‌اند؛ CASE صرفاً representation/interoperability mechanism می‌دهد.

پل به پیاده‌سازی production

در production، node و edge را versioned نگه دارید، graph را در هر release cycle برای self-loop و cycle بررسی کنید و closure را از learner evidence جدا materialize کنید. تغییر direction/type باید edge fingerprint جدید بسازد و closure قبلی را برای recomputation علامت بزند.

اگر framework خارجی import می‌شود، mapping table جدا از canonical identities نگه دارید تا migration یا لغو equivalence بدون rewriting history ممکن باشد.

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

ابتدا baseline hard edge را بسازید و ۱۶ فیلد را کامل کنید. سپس display order را برعکس کنید؛ state نباید عوض شود. بعد direction خود edge را برعکس کنید؛ closure قبلی دیگر oracle نیست و recompute لازم است.

در تمرین مستقل یک cycle سه‌گرهی بسازید، سپس hard edge را به recommended تبدیل کنید بدون policy equivalent؛ هر دو باید failure یا review state قابل توضیح بسازند.

چگونه verify کنیم؟

پنج سؤال: آیا identityها پایدار و distinct هستند؟ آیا edge جهت و type صریح دارد؟ آیا hard closure واقعاً به evidence معتبر trace می‌شود؟ آیا cycle detector graph را مستقل از display order می‌بیند؟ آیا equivalence/bridge provenance قابل بازسازی دارد؟

Lab آفلاین تمام ورودی‌ها و ruleها را نشان می‌دهد و هیچ tenant یا learner واقعی را تغییر نمی‌دهد.

ارزیابی و Transfer

ارزیابی شامل boundary retrieval، ساخت baseline، diagnosis reversed edge و cycle، و transfer به framework دوم است. در transfer، baseline closure ممنوع است: identityها باید جدا بمانند، association جدید باید trace شود و recommended edge از evidence جدید دوباره محاسبه شود.

اگر فقط wording شبیه است یا equivalence reviewer/provenance ندارد، نتیجه HOLD_UNVERIFIED_EQUIVALENCE است.

منابع و تازگی

FACT: 1EdTech CASE 1.1 یک روش استاندارد برای exchange استانداردها، competencies، skills و learning outcomes تعریف می‌کند و competency/itemها را با شناسه‌های دیجیتال و associationهای قابل تبادل مدل می‌کند. INFERENCE: version کردن identity/direction/type/evidence condition، prerequisite graph را auditپذیرتر از inference از course order می‌کند. DESIGN: hard/recommended semantics، cycle policy، closure state و bridge/equivalence policy در این درس authority محلی MAKNOW هستند.

منابع: 1EdTech CASE 1.1 Specification Portal و Introduction to CASE؛ freshness check: 2026-09-14، review due: 2027-01-15 یا زودتر در صورت تغییر معنادار.