Module 25: Portfolio, Feedback, and Final Project

Teaching Deck

Learning Objectives

  • Curate technical artifacts that demonstrate end-to-end capability
  • Write reflective commentary linking decisions, errors, and growth
  • Integrate peer/mentor feedback into a revised final portfolio
  • Present a coherent research identity and next-step plan

Session Outcomes

  • Learners can complete the module capability target.
  • Learners can produce one evidence-backed artifact.
  • Learners can state one limitation or uncertainty.

Agenda (60 min)

  • 0-10 min: Frame and model
  • 10-35 min: Guided practice
  • 35-50 min: Debrief and misconception correction
  • 50-60 min: Competency check + exit ticket

Capability Target

Submit a capstone portfolio that proves technical capability, communicates decision quality, and demonstrates iterative growth through feedback. Operationally: every artifact carries a caption naming the competency it proves and what a reviewer can check, the portfolio distinguishes what you did from what you were given, and at least one artifact shows a version that was wrong alongside the correction and the reason.

Concept Focus

1) Portfolio as evidence architecture

  • Technical: artifacts should be organized by competency claims, not chronology. Six well-captioned artifacts covering distinct competencies outperform fifteen that cluster on one. Where two artifacts prove the same thing, keep the stronger and cut the other; the cut is itself evidence of judgment.
  • Plain language: group work by what it proves you can do.
  • Misconception guardrail: more artifacts make a stronger portfolio.

Core Workflow

  • Define the competency claims first, in writing, then ask what evidence each requires. Working the other way round produces a folder of what you happen to have.
  • Select artifacts against those claims, cutting duplicates and keeping the version that shows the most judgment rather than the most polish.
  • Write one four-line evidence caption per artifact, checking that line three names something a stranger can verify.
  • Add reflection notes on decisions, errors, and revisions, naming the alternative not taken in each case.
  • Run the permission and provenance check across every artifact, and pin dataset versions.
  • Run peer or mentor review with a stated decision, criterion, stage, and deadline for each artifact you send.
  • Revise, record what changed and why in a visible revision log, and publish the package with a README that tells a two-minute reader where to start.

60-Minute Run-of-Show

  • 00:00-08:00 | Portfolio quality exemplar
  • Show one strong and one weak portfolio side by side, including a strong one that contains a documented error. Ask which one the room would trust with a dataset.
  • 08:00-20:00 | Competency-claim mapping
  • Learners write claims before selecting artifacts. Circulate asking "what would falsify this claim?" to force claims specific enough to be checked.
  • 20:00-34:00 | Artifact curation and caption drafting
  • Four-line captions, with line three enforced. Any caption that cannot name a verifiable item is returned rather than discussed.
  • 34:00-46:00 | Feedback exchange round
  • Each learner sends one artifact with a stated decision, criterion, stage, and deadline. Reviewers must answer the stated question before offering anything else.
  • 46:00-56:00 | Revision planning
  • Convert feedback into a dated revision list ordered by how much each change alters what the portfolio proves, not by how easy it is.
  • 56:00-60:00 | Final submission checklist
  • Permission check, dataset versions pinned, README present, contribution statements written.

Misconceptions to Watch

  • Misconception guardrail: more artifacts make a stronger portfolio.
  • Misconception guardrail: describing what you enjoyed about a project counts as reflection.
  • Misconception guardrail: a final version is stronger evidence when the earlier drafts are removed.
  • Misconception guardrail: a good artifact speaks for itself and needs no caption.
  • Misconception guardrail: asking a narrow question wastes the reviewer's expertise.
  • Misconception guardrail: work you did yourself is automatically yours to publish.

Studio Activity

Scenario: You are preparing your final portfolio for a competitive research opportunity. Assume the reviewer spends two minutes on the first pass and opens exactly one artifact.

Activity Output Checklist

  • Evidence-linked artifact submitted.
  • At least one limitation or uncertainty stated.
  • Revision point captured from feedback.

Assessment Rubric

  • Minimum pass: portfolio claims are evidence-backed; reflection identifies at least one meaningful revision loop; feedback is incorporated with clear changes; contributions in group work are stated explicitly.
  • Strong performance: demonstrates cross-module synthesis and transfer, highlights uncertainty and correction with technical maturity, communicates a future growth plan with concrete milestones, and includes at least one artifact whose earlier wrong version is shown alongside the correction and its reason.
  • Common failure to flag: artifact dump with weak competency mapping, reflection limited to narrative without analytical depth, and minimal response to peer critique. Also flag portfolios where every caption line three is missing, since that is the difference between a folder and evidence.

Exit Ticket

Choose one artifact and write its four lines: one competency claim it supports, what you did versus what you were given, one thing a reviewer can verify and where, and one limitation with the revision you would make next.

References (Instructor)

  • Program portfolio templates and competency rubrics.

Teaching Materials

  • Module page: /modules/module25/
  • Slide page: /modules/slides/module25/
  • Worksheet: /assets/worksheets/module25/module25-activity.md