Project-based Learning & Just-in-Time Instruction

The real problem

A project is not automatically Project Based Learning, and a warm-up quiz is not automatically Just-in-Time Teaching. The engineering problem is to build a loop in which an authentic project creates evidence opportunities, a short signal exposes what the learner needs before the next project decision, and support is selected only for that need. The project artifact remains the competence evidence; finishing support does not become mastery.

The owned artifact is Project/JiTT Learning Loop Plan v1. It must explain what project decision comes next, what evidence the milestone can produce, why support is or is not needed, what changed after revision, and what survives transfer.

Lesson boundary

MKN-002 owns the project/JiTT loop. MKN-001 owns experience-aware instructional design, while MKN-003 owns competency taxonomy and prerequisite-graph semantics. This lesson uses a target_competency_id but does not redefine the taxonomy.

Three boundaries matter: project completion ≠ mastery, support completion ≠ mastery, and pre-step correctness ≠ project evidence.

Mental model: project → signal → support → decision → evidence → revision

Start from the authentic decision the project requires. A milestone creates an evidence_opportunity. Immediately before the learner makes the next consequential project decision, a small prompt can reveal a misconception or blocker. If the signal is actionable, select bounded JIT instruction with an explicit support_reason; if evidence already shows independent competence, do not inject redundant support.

After the learner acts, evaluate the project artifact at the checkpoint, record revision history and preserve typed non-success states when evidence is missing or contradictory.

The 15-dimension loop contract

The plan records: 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 and exit evidence.

The fields are separate on purpose. learner_response_ref is diagnostic evidence. evidence_opportunity says what the project can show. checkpoint_state summarizes the checkpoint result. exit_evidence is what justifies leaving the lesson. None can be silently substituted for another.

Why a correct warm-up cannot rescue a wrong artifact

Suppose the learner correctly says that an event ID should be stable, but then implements a schema that regenerates identity on retry. The pre-step signal says the misconception may be resolved verbally; the artifact says the decision was not executed correctly. The loop must preserve that contradiction and route to revision instead of declaring success.

Conversely, if the project artifact already demonstrates independent competence, adding more JIT support just because the system has a lesson available is not personalization; it is unnecessary intervention. The support decision must remain traceable to an unresolved need.

Worked baseline

Project: add an observability event schema to a small service. Driving problem: retries currently create ambiguous duplicate events. Milestone MS-SCHEMA must produce a reviewable schema and example events. A pre-step response confuses event identity with delivery timestamp, so signal SIG-ID-TIME selects JIT-ID-01: a short contrast between stable identity and retry/delivery metadata.

The learner revises the schema, then the checkpoint inspects the actual artifact. If identity is stable and retry metadata is separate, the checkpoint can become EVIDENCE_CLOSED; the output and revision record remain attached to the decision.

Common failure modes

1. Dessert project: instruction is completed first and the project merely decorates it.
2. Completion-as-mastery: finishing the project is treated as proof for every competency it touched.
3. Quiz oracle: a correct pre-step response overrides contradictory project evidence.
4. Support without reason: JIT content is injected because it exists, not because evidence calls for it.
5. Evidence-free milestone: a milestone is an activity checkpoint but produces nothing reviewable.
6. Revision amnesia: the final artifact exists but the change from failed evidence to repair cannot be reconstructed.
7. Transfer copying: the second project inherits the baseline support plan without recomputation.

Support, no-support and escalation

There are three legitimate outcomes before a project decision. Support when a traceable signal exposes a bounded gap. No support when relevant evidence is already independently closed. Hold/escalate when the signal is ambiguous, missing or contradicted and the next project action would otherwise create false confidence.

Do not compress these into a single score. The design must preserve why the next action was selected and what evidence would change it.

Production implementation bridge

In a learning platform, model project/milestone definitions separately from learner attempts. Store response references and artifact/checkpoint evidence as append-only or versioned records. A JIT decision should reference both the signal and the support rule used at that moment. Revision cycles should preserve prior failed artifacts rather than replacing history.

For event-driven systems, do not require a specific telemetry schema in this lesson. If the second project lacks the previous event schema, rebuild the evidence path from the new observable facts rather than treating missing telemetry as negative mastery.

Guided and independent practice

Build the baseline loop using all 15 fields. Then mutate only one dimension at a time: make the pre-step answer correct while the artifact stays wrong; remove the evidence opportunity while keeping the milestone activity; add support after independent evidence is already closed.

For independent practice, move the same target competency into a different project domain with no event schema. Decide which earlier evidence transfers, which support disappears, and which support returns because the new context changes the next authentic decision.

Verification evidence

Verify five things: the project has a meaningful driving problem; every milestone has a real evidence opportunity; JIT support traces to a diagnostic signal; checkpoint state comes from the project artifact rather than support completion; and revision/transfer can be reconstructed from visible evidence.

The offline lab uses synthetic records only. Missing evidence stays HOLD, UNKNOWN, INCONCLUSIVE or REVIEW_REQUIRED instead of being converted into success.

Assessment and transfer

Assessment requires boundary retrieval, construction of a baseline loop, diagnosis of the correct-response/wrong-artifact shortcut, and transfer to a second domain. The transfer answer cannot copy the baseline JIT plan. It must recompute from new project evidence.

If prior competency evidence is genuinely portable, some instruction can disappear. If the new project introduces a context-specific decision not covered by that evidence, support can reappear without erasing the earlier evidence.

References and freshness

FACT: PBLWorks describes PBL as extended work investigating and responding to an authentic, engaging and complex problem/question/challenge. FACT: Vanderbilt teaching guidance describes JiTT as using pre-class responses or quizzes to identify difficulties and tailor subsequent activities. INFERENCE: placing diagnostic signals immediately before authentic project decisions can keep support close to need while preserving project work as evidence. DESIGN: milestone evidence mapping, support-reason fields, revision history, typed holds and changed-context transfer are MAKNOW local design authority.

Freshness checked 2026-09-14. Recheck by 2027-01-15 or earlier if the cited guidance materially changes.