Project-based Learning و Just-in-Time Instruction

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

هر پروژه‌ای Project Based Learning نیست و هر quiz کوتاهی هم JiTT نیست. مسئله‌ی مهندسی این درس ساختن یک loop است که در آن خود پروژه فرصت evidence واقعی بسازد، یک signal کوتاه قبل از تصمیم بعدی learner نشان دهد چه چیزی نیاز به support دارد، و instruction فقط همان‌جا و همان‌قدر وارد شود که evidence توجیه می‌کند. Artifact پروژه evidence اصلی competence می‌ماند؛ تمام‌کردن support مساوی mastery نیست.

خروجی اصلی Project/JiTT Learning Loop Plan v1 است؛ باید نشان دهد تصمیم بعدی پروژه چیست، milestone چه evidenceای می‌سازد، چرا support لازم است یا نیست، revision چه چیزی را عوض کرده و در transfer چه چیزی واقعاً قابل حمل است.

مرز درس

MKN-002 مالک loop پروژه/JiTT است. MKN-001 درباره Instructional Design برای افراد باتجربه است و MKN-003 مالک competency taxonomy و prerequisite graph. این درس از target_competency_id استفاده می‌کند اما taxonomy را بازتعریف نمی‌کند.

سه مرز: project completion ≠ mastery، support completion ≠ mastery و پاسخ درست pre-step ≠ evidence پروژه.

مدل ذهنی: Project → Signal → Support → Decision → Evidence → Revision

از یک تصمیم واقعی داخل پروژه شروع کنید. هر milestone باید evidence_opportunity مشخص داشته باشد. درست قبل از تصمیم بعدی، یک prompt کوچک می‌تواند misconception یا blocker را آشکار کند. اگر signal actionable است، JIT instruction محدود با support_reason صریح انتخاب می‌شود؛ اگر competence مستقل قبلاً با evidence بسته شده، support اضافی نباید تزریق شود.

بعد از عمل learner، checkpoint باید Artifact واقعی پروژه را ببیند، revision history را ثبت کند و وقتی evidence ناقص یا متناقض است state غیرموفق را حفظ کند.

قرارداد ۱۵ بُعدی Loop

Plan این فیلدها را نگه می‌دارد: project، driving problem، target competency، milestone، evidence opportunity، pre-step prompt، response reference، misconception signal، JIT instruction، support reason، checkpoint state، revision cycle، public/reviewable output، transfer variant و exit evidence.

learner_response_ref diagnostic evidence است؛ evidence_opportunity می‌گوید پروژه چه چیزی را می‌تواند نشان دهد؛ checkpoint_state نتیجه‌ی checkpoint است؛ exit_evidence دلیل خروج از درس است. این‌ها جای یکدیگر را نمی‌گیرند.

چرا warm-up درست نمی‌تواند Artifact غلط را نجات دهد؟

فرض کنید learner درست می‌گوید event ID باید stable باشد، اما در schema واقعی روی retry دوباره identity تولید می‌کند. pre-step نشان می‌دهد توضیح لفظی بهتر شده، ولی artifact نشان می‌دهد تصمیم درست اجرا نشده است. Loop باید contradiction را نگه دارد و learner را به revision بفرستد، نه success.

برعکس، اگر Artifact پروژه از قبل competence مستقل را نشان داده، اضافه‌کردن JIT فقط چون یک lesson آماده داریم personalization نیست؛ intervention اضافه است. support باید همیشه به gap حل‌نشده trace شود.

مثال پایه

Project: اضافه‌کردن observability event schema به یک سرویس کوچک. Driving problem: retryها eventهای duplicate و مبهم ساخته‌اند. Milestone MS-SCHEMA باید schema و example event قابل review تولید کند. پاسخ pre-step، event identity را با delivery timestamp قاطی می‌کند؛ signal SIG-ID-TIME، support کوتاه JIT-ID-01 را فعال می‌کند که stable identity را از retry/delivery metadata تفکیک می‌کند.

learner schema را revise می‌کند و checkpoint Artifact واقعی را بررسی می‌کند. اگر identity پایدار و retry metadata جدا باشد، state می‌تواند EVIDENCE_CLOSED شود و output همراه revision history باقی می‌ماند.

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

1. Dessert project: آموزش تمام شده و پروژه فقط تزئین بعدی است.
2. Completion-as-mastery: پایان پروژه را mastery همه‌ی competencyهای درگیر فرض می‌کند.
3. Quiz oracle: پاسخ درست pre-step، artifact متناقض را می‌پوشاند.
4. Support بدون دلیل: JIT چون در catalog وجود دارد inject می‌شود، نه چون evidence لازم دارد.
5. Milestone بدون evidence: فعالیت وجود دارد ولی خروجی قابل review ندارد.
6. Revision amnesia: final artifact هست اما مسیر fail→repair قابل بازسازی نیست.
7. Transfer copying: پروژه دوم همان support plan قبلی را بدون recomputation می‌گیرد.

Support، No-support و Escalation

قبل از یک تصمیم پروژه سه outcome معتبر داریم: Support وقتی signal traceable gap محدود را نشان می‌دهد؛ No-support وقتی evidence مرتبط قبلاً مستقل بسته شده؛ و Hold/Escalate وقتی signal مبهم یا متناقض است و ادامه‌دادن false confidence می‌سازد.

این stateها را در یک score مصنوعی ادغام نکنید. دلیل next action و evidence لازم برای تغییر آن باید دیده شود.

پل به Production

در محصول واقعی، project/milestone definition را از learner attempt جدا کنید. response ref و artifact/checkpoint evidence را versioned یا append-only نگه دارید. هر JIT decision باید signal و rule همان لحظه را reference کند. revision cycle نباید failure قبلی را پاک کند.

در transfer، این lesson event schema خاصی را اجبار نمی‌کند. اگر پروژه‌ی دوم telemetry قبلی را ندارد، evidence path را از واقعیت‌های قابل مشاهده‌ی جدید بسازید؛ نبود schema را به negative mastery تبدیل نکنید.

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

Baseline را با هر ۱۵ فیلد بسازید. سپس هر بار فقط یک mutation اعمال کنید: پاسخ pre-step را درست کنید ولی artifact غلط بماند؛ evidence opportunity را حذف کنید ولی milestone activity را نگه دارید؛ بعد از evidence مستقل support اضافه کنید.

برای تمرین مستقل همان target competency را به domain پروژه‌ای دیگر بدون event schema ببرید. مشخص کنید کدام evidence قبلی transfer می‌شود، کدام instruction حذف می‌شود و کدام support به‌دلیل context جدید دوباره برمی‌گردد.

Evidence قابل Verify

پنج سؤال: آیا driving problem معنادار است؟ آیا هر milestone evidence opportunity واقعی دارد؟ آیا JIT به signal تشخیصی trace می‌شود؟ آیا checkpoint از artifact پروژه می‌آید نه completion support؟ آیا revision و transfer از evidence visible قابل بازسازی‌اند؟

Lab آفلاین فقط داده synthetic دارد. کمبود evidence باید HOLD، UNKNOWN، INCONCLUSIVE یا REVIEW_REQUIRED بماند و به success تبدیل نشود.

ارزیابی و Transfer

Assessment شامل boundary retrieval، ساخت baseline، diagnosis حالت correct-response/wrong-artifact و انتقال به domain دوم است. transfer حق ندارد JIT plan baseline را کپی کند؛ باید از evidence پروژه‌ی جدید recompute شود.

اگر evidence competence قبلی واقعاً portable است، بخشی از instruction می‌تواند حذف شود. اگر پروژه‌ی جدید تصمیم context-specific تازه‌ای دارد، support می‌تواند دوباره ظاهر شود بدون اینکه evidence قبلی پاک شود.

منابع و تازگی

FACT: PBLWorks، PBL را کار ممتد برای تحقیق و پاسخ به مسئله/پرسش اصیل، درگیرکننده و پیچیده توصیف می‌کند. FACT: راهنمای Vanderbilt، JiTT را استفاده از پاسخ‌ها/quizهای قبل از جلسه برای تشخیص نقاط دشوار و تنظیم activity بعدی توضیح می‌دهد. INFERENCE: قرار دادن signal درست قبل از تصمیم اصیل پروژه می‌تواند support را به نیاز واقعی نزدیک کند و پروژه را source اصلی evidence نگه دارد. DESIGN: milestone-evidence map، support reason، revision history، typed hold و changed-context transfer در این درس authority محلی MAKNOW هستند.

Freshness check: 2026-09-14. بازبینی بعدی تا 2027-01-15 یا زودتر در صورت تغییر معنادار منبع.