Module 12: Capstone Guide — From Campus Problem to Evaluated AI Solution

Learning Objectives

By the end of this module, you will be able to:

1. Select and scope a defensible capstone problem — Apply stakeholder access, ethics, evaluability, and differentiation criteria; produce a problem statement that survives advisor scrutiny.

2. Translate needs into requirements and non-goals — Write functional and non-functional requirements, explicit non-goals, and success metrics linked to user outcomes and Module 09 evaluation plans.

3. Architect a small, shippable AI-assisted system — Combine retrieval, guardrails, human oversight, and non-AI components (UI, data pipeline, policy) appropriate to institutional constraints.

4. Execute a milestone plan spanning discovery, design, prototype, hardening, evaluation, and showcase — With artifacts suitable for portfolio and graduate school narratives.

5. Report with academic integrity — Integrate process appendices, citation discipline (Module 03), and limitations sections aligned with open science norms.

Deep Concept Explanation: Academic Context, Research Methodologies, and Capstone Framing

12.1 What “capstone” means in this track

The capstone is not a toy notebook exercise. It is a bounded, demonstrable system that reduces a real friction for people you can observe or interview—typically campus or community contexts—using AI only where it earns its place, with evaluation and governance treated as first-class deliverables.

Methodologically, the capstone mirrors a mini thesis or HCI systems paper: problem motivation, related work (lightweight), design rationale, implementation sketch, evaluation, limitations, ethics. Even if you do not submit to a venue, write as if you might—clarity improves.

12.2 Problem selection: decision matrix

Reject ideas that require scraping private data, surveillance, academic dishonesty facilitation, or high-stakes autonomous decisions about individuals without governance.

12.3 Discovery phase: mixed methods

Use interviews (semi-structured), contextual inquiry, or artifact analysis (forms, PDFs, policies). For each session, record consent, anonymization plan, and limits on AI transcription (PII policies).

Synthesize into:

• Pain themes with frequency notes.
• Current workarounds (competitive substitutes).
• Non-negotiable constraints (legal, FERPA-like, accessibility).

12.4 Requirements engineering

Functional requirements — User-visible capabilities (“answer questions with citations to corpus X”).

Non-functional — Latency targets, uptime expectations, privacy (no PII storage), accessibility (keyboard nav, contrast).

Non-goals — Explicitly exclude v1 scope creep (mobile app, multilingual, full LMS integration) unless time permits.

Trace requirements to test cases and demo script steps.

12.5 Architecture patterns that work for student RAG

• Corpus of authorized documents; refresh pipeline documented.
• Retriever (hybrid BM25 + embeddings often robust).
• Generator with citation forcing and grounding checks (Module 09).
• Human review queue for low-confidence answers (optional but strong).
• Logging with redaction.

Avoid black-box “chat everything” without corpus boundaries.

12.6 Milestone roadmap (typical 4–6 weeks)

1. Discovery — Problem brief, risks, stakeholder map.
2. Design — Requirements, architecture, data inventory, ethics appendix.
3. Prototype — Core loop on sample data; happy path demo.
4. Hardening — Errors, tests, security pass, ops notes.
5. Evaluation — Golden set, human rubric sample, failure taxonomy.
6. Showcase — Demo video, poster, short paper; reproducible repo tag.

Adjust cadence for your syllabus; preserve order, not fixed durations.

12.7 Evaluation integration (Module 09)

Capstone quality hinges on honest evaluation:

• 25–40 curated queries including adversarial and policy-edge cases.
• Automated checks (must_contain, forbidden phrases) plus human rubric on stratified sample.
• Report limitations: what you did not test, model versions, corpus date.

12.8 Threat modeling lite (STRIDE-inspired)

Identify spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege analogs for your app. Example: prompt injection against RAG; leaked API keys; abusive content generation.

Mitigations: input filters, output policies, rate limits, secrets management.

12.9 Academic integrity for capstone reports

• Cite market and policy claims (Module 03).
• Disclose AI use in drafting; verify all technical claims against your repo.
• Never fabricate user quotes or pilot results.

12.10 Portfolio and graduate school narrative

Prepare a 150–250 word story: problem, your role, technical hook, evaluation result, ethical consideration, what you’d do next. Recruiters and committees want coherence, not buzzwords.

12.11 Team dynamics and accountability

Use Module 11 process pack: RACI, DoD, review norms. Capstone conflict often arises from unequal contribution; address with visible task board and weekly scope negotiation.

12.12 Accessibility and equity

Plan for keyboard use, screen reader basics on web demos, color contrast, and language level appropriate to users. Document known gaps honestly.

12.13 Reproducibility statement

Even with closed APIs, provide: pinned dependencies, frozen prompts, model names and dates, golden set, and instructions to rerun smoke tests.

12.14 Showcase formats

• Live demo with backup recording.
• Poster with QR to repo.
• Short paper (4–6 pages) mirroring IMRAD-style systems sections.

12.15 Post-capstone continuity

Archive repo, write maintainer notes, list known tech debt, and suggest next experiments for future teams.

12.16 Synthesis

The capstone proves you can frame, build, evaluate, and communicate responsibly—not merely prompt a model.

12.17 Integration with formal assessment

When your syllabus ties the capstone to a letter grade, map rubric rows explicitly to artifacts: problem brief, repo, evaluation report, demo, and individual reflection. Maintain a contribution log (Module 11) so instructors can distinguish team from individual mastery. If your program requires a public poster session, prepare two explanations: a 30-second hook for passers-by and a 3-minute technical walkthrough for judges. Anticipate questions on data rights, failure modes, and what you would not ship—answers here signal professional maturity more than feature breadth.

12.18 Longitudinal learning

After submission, archive a personal “lessons learned” note (not necessarily graded): which risks materialized, which estimates were wrong, and which skills you will train next (e.g., frontend, statistics, stakeholder interviews). This note becomes raw material for interview STAR stories and graduate school statements of purpose.

12.19 Positioning against related systems (mini related-work)

Even if you do not write a full literature review, include two pages mapping academic and product neighbors: prior campus tools, commercial LMS plugins, and research papers on similar tasks. AI can suggest candidates; you verify each with a read abstract + skim methods minimum. State differentiation as a falsifiable claim (“We provide citations to corpus X; baseline chatbots do not.”).

12.20 IRB / ethics decision tree (practical)

Ask: Are you collecting identifiable data from living humans about themselves? Are you intervening or observing normally occurring behavior for research purposes beyond class? If yes/uncertain, contact your IRB or ethics office early. For class-only critiques of public systems with no PII, document why human-subjects review is not triggered—consult your instructor template. Never substitute a blog post for actual campus policy.

12.21 Individual contribution statement (graded teams)

Write 250–400 words specifying: modules you authored, PRs merged, evaluation work, stakeholder interviews conducted, and AI assistance boundaries you followed. Align claims to Git history and meeting notes. This document reduces grading disputes and mirrors authorship contribution statements in journals.

12.22 Demo video as reproducibility artifact

Record 1080p, clear audio, and closed captions when possible. Show live query plus on-screen citation to corpus. Upload unlisted link + checksum note in README. Judges use videos when live demos fail—treat video as first-class deliverable, not backup fluff.

12.23 Poster rubric alignment

Map poster sections to rubric rows: problem evidence, architecture, evaluation table, ethics, future work. Avoid wall of text; use QR to repo and one chart that encodes your primary result. Peer-review posters with Module 09 calibration in mind: would a skeptical professor believe the metric?

12.24 Data retention and teardown plan

State how long you keep logs, how you delete pilot user data, and who can access backups. Capstones that ignore deletion may violate FERPA-like norms even in pilots.

12.25 Open questions section (scholarly tone)

List three questions your work does not answer—scope, sample, instrument limits. This signals mature science thinking and differentiates you from marketing decks.

12.26 Integration with entrepreneurship track

If commercialization is plausible, attach a one-page BMC snapshot (Module 10) as appendix and note IP review status with your tech transfer office when required.

12.27 Accessibility checklist expansion

Beyond contrast: tab order on forms, captioning for media, plain-language summary paragraph on poster for non-experts. Document known gaps honestly.

12.28 Final synthesis

The capstone demonstrates end-to-end judgment: problem choice, system boundaries, evaluation credibility, and communication ethics. AI is optional machinery; your traceable decisions are the credential.

Code and Computational Examples

CE-1 Markdown: requirements snippet (extend for your project)

[object Object],
,[object Object], User can ask natural-language questions about [authorized corpus].
,[object Object], Answers include citations [document id + section anchor].
,[object Object], Admin can rebuild index via documented script.

,[object Object],
,[object Object], p95 latency < 5s on reference laptop for default queries
,[object Object], No long-term storage of user PII; logs redact emails
,[object Object], WCAG-oriented contrast for demo UI (document exceptions)

,[object Object],
,[object Object], Native mobile clients
,[object Object], Multilingual answers
,[object Object], Automated grading of student work

CE-2 Markdown: stakeholder map template

[object Object],

| Group | Interest | Influence | Engagement plan |
|-------|----------|-----------|-----------------|
| Primary users | | | |
| Gatekeepers (IT, admin) | | | |
| Affected non-users | | | |

,[object Object],
,[object Object], 

CE-3 YAML: capstone milestone tracker

[object Object], ,[object Object],
,[object Object],
  ,[object Object], ,[object Object], ,[object Object],
    ,[object Object], ,[object Object],
    ,[object Object],
      ,[object Object], ,[object Object], ,[object Object], ,[object Object],
      ,[object Object], ,[object Object], ,[object Object], ,[object Object],
  ,[object Object], ,[object Object], ,[object Object],
    ,[object Object], ,[object Object],
    ,[object Object],
      ,[object Object], ,[object Object], ,[object Object],
      ,[object Object], ,[object Object], ,[object Object],
  ,[object Object], ,[object Object], ,[object Object],
    ,[object Object], ,[object Object],
    ,[object Object],
      ,[object Object], ,[object Object], ,[object Object], ,[object Object],
  ,[object Object], ,[object Object], ,[object Object],
    ,[object Object], ,[object Object],
    ,[object Object],
      ,[object Object], ,[object Object], ,[object Object], ,[object Object],
      ,[object Object], ,[object Object], ,[object Object],

CE-4 Python: capstone “health check” script idea

[object Object], __future__ ,[object Object], annotations

,[object Object], pathlib ,[object Object], Path


,[object Object], ,[object Object],(,[object Object],) -> ,[object Object],[,[object Object],]:
    required = [
        ,[object Object],,
        ,[object Object],,
        ,[object Object],,
        ,[object Object],,
    ]
    missing = [name ,[object Object], name ,[object Object], required ,[object Object], ,[object Object], (root / name).exists()]
    ,[object Object], missing


,[object Object],
,[object Object],
,[object Object],

CE-5 JSON: demo script machine-readable

[object Object],
  ,[object Object],[object Object], ,[object Object],[object Object],
  ,[object Object],[object Object], ,[object Object],
    ,[object Object],[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object],[object Object],
    ,[object Object],[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object],[object Object],
    ,[object Object],[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object], ,[object Object],[object Object],
  ,[object Object],[object Object],
  ,[object Object],[object Object], ,[object Object],[object Object],[object Object],
,[object Object],

CE-6 Markdown: ethics appendix template

[object Object],

,[object Object],
,[object Object], 

,[object Object],
,[object Object], 

,[object Object],
,[object Object], 

,[object Object],
,[object Object], 

CE-7 Python: simple evaluation summary aggregator (toy)

[object Object], __future__ ,[object Object], annotations

,[object Object], dataclasses ,[object Object], dataclass


,[object Object],
,[object Object], ,[object Object],:
    name: ,[object Object],
    passed: ,[object Object],
    total: ,[object Object],


,[object Object], ,[object Object],(,[object Object],) -> ,[object Object],:
    num = ,[object Object],(r.passed ,[object Object], r ,[object Object], runs)
    den = ,[object Object],(r.total ,[object Object], r ,[object Object], runs)
    ,[object Object], num / den ,[object Object], den ,[object Object], ,[object Object],


runs = [EvalRun(,[object Object],, ,[object Object],, ,[object Object],), EvalRun(,[object Object],, ,[object Object],, ,[object Object],)]
,[object Object],(,[object Object],)

CE-8 Markdown: limitations section boilerplate (adapt)

[object Object],
,[object Object], Small sample sizes in user feedback; not statistically generalizable.
,[object Object], Corpus current as of [date]; policy changes may stale answers.
,[object Object], Closed API; exact reproduction may differ with model updates.
,[object Object], Human ratings from student raters; potential bias toward familiar domain.

CE-9 Bash: release tag for judges

git tag -a capstone-submission -m ,[object Object],
git push origin capstone-submission

CE-10 Text: poster section outline

Title + team
Problem (1 figure)
Approach (architecture mini-diagram)
Demo QR
Key result (metric + chart)
Ethics/limitations (bullet)
Future work

CE-11 Markdown: individual contribution statement template

[object Object],

,[object Object],  
,[object Object],  

,[object Object],
,[object Object], PRs authored (links or numbers):
,[object Object], Modules / packages owned:

,[object Object],
,[object Object], Interviews conducted (count; role of interviewee anonymized):
,[object Object], User tests facilitated:

,[object Object],
,[object Object], Golden set items authored:
,[object Object], Human rubric sessions run:

,[object Object],
,[object Object], Tools and stages:
,[object Object], Verification practices:

,[object Object],
,[object Object], Hardest technical judgment call:
,[object Object], What I would redo with more time:

CE-12 Python: simple rubric-to-CSV export for poster judging

[object Object], __future__ ,[object Object], annotations

,[object Object], csv
,[object Object], dataclasses ,[object Object], dataclass


,[object Object],
,[object Object], ,[object Object],:
    name: ,[object Object],
    max_points: ,[object Object],


CRITERIA = [
    PosterCriterion(,[object Object],, ,[object Object],),
    PosterCriterion(,[object Object],, ,[object Object],),
    PosterCriterion(,[object Object],, ,[object Object],),
    PosterCriterion(,[object Object],, ,[object Object],),
    PosterCriterion(,[object Object],, ,[object Object],),
]


,[object Object], ,[object Object],(,[object Object],) -> ,[object Object],:
    ,[object Object], ,[object Object],(path, ,[object Object],, newline=,[object Object],, encoding=,[object Object],) ,[object Object], f:
        w = csv.writer(f)
        w.writerow([,[object Object],, *[c.name ,[object Object], c ,[object Object], CRITERIA], ,[object Object],])
        w.writerow([,[object Object],, *[,[object Object], ,[object Object], _ ,[object Object], CRITERIA], ,[object Object],])


write_blank_scoresheet(,[object Object],)

Practice Exercises

1. Problem triage — Write three problem candidates; score each on the 6-criterion matrix; pick one with written rationale.

2. Stakeholder interview guide — Ten questions with probes; include two questions that surface non-AI workarounds.

3. Threat modeling — STRIDE-style list of twelve threats; map mitigations to engineering tasks.

4. Metric stack — Define north-star, two guardrails, and one quality metric tied to a rubric (Module 09).

5. Requirements traceability — Table mapping requirement IDs to tests and demo steps.

6. 90-second elevator — Record; transcribe; cut jargon until a first-year understands problem and pilot result.

7. Related work mini-review — Five sources with DOIs; two sentences each on gap your capstone addresses (verify opens).

8. Peer review swap — Exchange kickoff packages; use rubric below; revise once.

Mini-Project: Capstone Kickoff Package (Formative)

Deliverables

1. Problem brief (1 page) — Hypothesis, evidence quotes or observations (anonymized), competitors/substitutes.

2. Architecture diagram — Hand-drawn scanned is fine; show data flow and human oversight.

3. 4-week sprint plan — Owners per milestone; dependencies; demo dates.

4. Risk & ethics appendix (1 page) — Data rights, consent, harms, mitigations.

5. Evaluation plan stub — Intended golden set themes, human rubric dimensions, known limitations.

6. Repo skeleton — README, LICENSE, .env.example, empty eval/ with README explaining intent.

Alignment — Cross-check detailed rubric in ../projects/capstone.md if present in your course repo.

Summative rubric fragment (instructor-facing)

Key Takeaways

Academic integrity

The capstone is a signature of your judgment. Disclose AI assistance; verify every claim; never invent users or metrics.

Stakeholders first

Technology choices serve documented needs. If you cannot access users, say so and justify proxies transparently.

Evaluation is not optional

A demo without measurement is theater. Pair qualitative insight with structured tests.

Reproducibility and humility

Model APIs change; corpora drift. Date-stamp, version-pin, and limitation-write with the confidence of a serious researcher.

Further resources

• Course ../projects/capstone.md — full specification if provided.
• Modules 08 (RAG/memory depth), 09 (evaluation), 11 (process).
• IRB or ethics board if human subjects beyond normal class activity.
• Campus innovation center, library scholarly communication, IT security.

Final checklist

• Problem brief approved by mentor
• Architecture + data rights documented
• Eval plan + golden themes drafted
• Threat model + mitigations
• Repo skeleton with disclosure
• Demo fallback assets prepared

References and Cross-Modules

• Module 01 — socio-technical framing.
• Module 03 — writing and citation for final report.
• Module 10 — problem validation and BMC prior to build.
• Module 11 — delivery discipline throughout.