CS357: Foundations of Artificial Intelligence - The Project Thread: A Semester-Long Multidisciplinary Project (0 Points)
Purpose, Task, and Criteria
Purpose: To practice, over a full semester, the professional cycle of problem finding, multi-disciplinary research, collaborative intervention, and multi-audience communication, and to make your own learning visible along the way using the Ursinus Open Questions.
Task: Complete the semester-long sequence of thread milestones with your standing POGIL team, from the formation survey and charter through the stakeholder brief, literature review, final-project proposal, sprints, and Demo Day.
Criteria: Every milestone is evaluated on three dimensions — approach (was the work deliberate and grounded?), professionalism and process (did the team follow its playbook?), and product (does the artifact serve its audience?); see the rubric below for the full breakdown.
Assignment Goals
The goals of this assignment are:- To identify and research an issue, question, or practical problem in partnership with a real stakeholder outside computer science (Goal 11)
- To develop a multi-disciplinary understanding of that problem and explore how it could be addressed (Goal 12)
- To collaborate on a standing team, governed by a charter, to develop a strategic intervention that constructively addresses the issue (Goal 13)
- To communicate effectively with a variety of audiences — technical peers, non-technical stakeholders, and the public — through multiple modalities (Goal 14)
- To use the Ursinus Open Questions to assess the learning process throughout the semester, describing new understandings and specific areas of growth and skill development (Goal 15)
Background Reading and References
Please refer to the following readings and examples offering templates to help get you started:- Kuh, G. D. (2008). High-Impact Educational Practices: What They Are, Who Has Access to Them, and Why They Matter. Washington, DC: Association of American Colleges and Universities.
- Shulman, L. S. (2005). Pedagogies of Uncertainty. Liberal Education, 91(2), 18-25.
- Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350-383.
- Tuckman, B. W. (1965). Developmental Sequence in Small Groups. Psychological Bulletin, 63(6), 384-399.
- Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge: Cambridge University Press.
- TILT Higher Ed: Transparency in Learning and Teaching framework
- CATME Smarter Teamwork (research-based team formation and peer evaluation tools)
- AAC&U VALUE Rubrics (Teamwork, Problem Solving, and Integrative Learning)
The Assignment
This page is the hub for the Project Thread: a semester-long, project-based learning arc that runs underneath everything else in CS357. The thread carries no points of its own — every milestone is graded on its own assignment page — but it is the map that shows how the pieces connect: how a survey in week 0 becomes a team, how a team becomes a charter, how a conversation with a real stakeholder becomes a literature review, and how all of it converges on your final project and Demo Day.
The project is the vehicle, not the destination. What this course is actually teaching through the thread is a process: how to find a problem worth solving, how to understand it from more than one discipline’s point of view, how to work on a team that stays healthy under pressure, and how to communicate what you built to people who do not share your training. Project-based learning of this kind is one of the most consistently effective educational experiences documented in the literature (Kuh, 2008, names it among the high-impact practices), precisely because it forces you to work on problems whose answers are not in the back of the book — what Shulman (2005) calls the pedagogies of uncertainty. Uncertainty is a feature here, not a bug: your stakeholder’s problem will be messy, your team will disagree, and your first plan will be wrong. The thread exists so that none of those moments is a crisis. And you will not learn these practices by being told about them: a team becomes a working community by doing real work together, at the edge of its competence, alongside people who are learning the same craft — what Lave and Wenger (1991) call situated learning in a community of practice. The thread is that community’s calendar.
Key Concepts
| Term | Plain-English Definition | Where You Will Meet It |
|---|---|---|
| Project Thread | The semester-long sequence of connected team milestones that culminates in the final project. Each milestone feeds the next. | This page; every milestone links back here |
| Stakeholder | A real person or office outside computer science whose problem your project addresses — a campus office, a local organization, or faculty/students in another discipline. | The Stakeholder Brief (week 2.1 to 4.1) |
| Team Charter | A short, signed document stating your team’s norms, decision rules, conflict protocol, and accountability procedures. Revisited and revised at midterm. | Charter activity (week 1.1); revisit (week 8.0) |
| Psychological Safety | The shared belief that a team is safe for interpersonal risk-taking — asking a naive question, admitting a mistake, disagreeing with the group — without being punished or embarrassed (Edmondson, 1999). | The working norm for every team meeting |
| Tuckman Stages | The observed sequence most teams pass through: forming, storming, norming, performing, adjourning (Tuckman, 1965). Storming is normal, expected, and survivable. | The stage map below; the charter activity |
| SQR Card | A structured peer-review card: one Strength with evidence, one genuine Question, one Risk with a suggested mitigation. | Peer review exchanges (weeks 5, 11, 14) |
| Sprint | A short, fixed-length build cycle ending in a runnable increment, an updated evaluation, and a retrospective. | Final project (weeks 11 to 15) |
| Open Questions | The four questions at the center of the Ursinus curriculum: What should matter to me? How should we live together? How can we understand the world? What will I do? | Every milestone’s reflection prompts (Goal 15) |
| Primary Author | The named team member responsible for drafting and defending one section of a team document. Every student is primary author of at least one section of every team document. | Every team deliverable |
| AI-Use Disclosure | A short statement, attached to every milestone, of what (if anything) was AI-assisted, with what tool, and how the team verified it. | Every milestone submission |
Notation: week numbers are written wkN.M, meaning week N, class meeting M (so wk4.1 is the second class meeting of week 4).
The Semester Map
Two views of the same thread — a table for scanning, then a narrative for reading. Every artifact below has its own assignment or activity page; this table is the authoritative sequence.
| When | Milestone | What Happens | Where |
|---|---|---|---|
| wk0.0 → wk1.0 | Team Formation Survey (individual) | You tell the instructor your availability, deadline style, energy patterns, and interests. Teams are formed from this data. | Team Formation Survey |
| wk1.1 | Teams announced | Standing POGIL teams for the semester are posted. | In class |
| wk1.1 → wk2.0 | Team Charter | In-class charter activity (building on the warmup’s pre-draft); the signed charter is due wk2.0. All members sign. | Team Charter and Norms activity |
| wk2.1 | Stakeholder Brief kickoff | Speed-dating topic-generation round in class; teams identify a real stakeholder outside CS. | Stakeholder Brief |
| wk4.1 | Stakeholder Brief due | 2-3 page brief: the issue in the stakeholder’s own terms, the disciplines involved, a problem statement an agent system could address. | Stakeholder Brief |
| wk5.0 | Peer review round 1 | Briefs are exchanged across teams for SQR review; first private intra-team check-in goes to the instructor. | Structured Peer Review activity |
| wk5.0 → wk7.1 | Literature Review | Phase 1 (individual annotated bibliographies) due wk6.1; Phase 2 (team synthesis) due wk7.1. | Literature Review |
| wk8.0 | Charter revisit | Midpoint: the team re-reads its charter, discusses what held and what did not, and files a revision. | Team Charter and Norms activity |
| wk9.1 | Final project tracks handed out | Choose one of three tracks: Custom Agent Team, Responsible AI Audit, or Open-Source Agent. | Track pages |
| wk10 | Peer review round 2 | Second private intra-team check-in to the instructor. | Structured Peer Review activity |
| wk11.0 | Proposal due | The proposal integrates the Stakeholder Brief and Literature Review; cross-team SQR critique at wk11.0/11.1. | Track pages |
| wk11 → wk14 | Sprints | Build in sprints with rotating roles, runnable increments, and evaluation updates. | Track pages |
| wk14 | Gallery walk + peer review round 3 | Walk each other’s work with SQR cards; third private intra-team check-in. | Track pages |
| wk15.0 | Demo Day | Technical demo, a non-technical stakeholder-facing segment, and a disseminable artifact. | Track pages |
The same map, as a story. In week 0 you fill out a short survey, and by the second meeting of week 1 you have a team formed for compatibility of schedules and working styles. Your first job as a team is not technical: it is to write down, and sign, how you will treat each other. Then you go find a real problem — not one invented for a class, but one a real stakeholder outside computer science will describe to you in their own words. You spend the middle weeks understanding that problem the way scholars do: reading, annotating, and synthesizing sources from at least two disciplines. At the midpoint you stop and ask whether your charter still describes your actual team, and you fix it if it does not. Only then — nine weeks in, with a grounded problem and a healthy team — do you choose a final project track and propose an intervention. The last five weeks are sprints, peer review, and rehearsal, ending at Demo Day, where you show your work three ways: to technical peers, to your stakeholder, and to the public.
Where Your Team Will Be, and When: The Tuckman Map
Tuckman (1965) observed that small groups reliably pass through recognizable developmental stages. Knowing the map does not let you skip the hard parts, but it turns “our team is broken” into “our team is in week 6, right on schedule.” Here is the same idea twice: first as a table, then as advice.
| Tuckman Stage | Thread Weeks (typical) | What It Feels Like | What To Do About It |
|---|---|---|---|
| Forming | wk0 - wk2 | Polite, careful, a little vague. Everyone agrees with everyone. | Use the structure: the survey, the charter activity, and the get-to-know protocol exist to accelerate this stage honestly. |
| Storming | wk3 - wk7 | First real disagreements — over the stakeholder choice, over who is doing the work, over standards. This usually surfaces during the Brief and Literature Review. | Do not panic and do not go silent. Run the charter’s conflict protocol. Storming is a stage, not a verdict (Tuckman, 1965). |
| Norming | wk8 - wk10 | The team develops its own shorthand and rhythms. Roles feel natural. | This is exactly why the charter revisit is scheduled at wk8.0 — codify what you actually learned to do. |
| Performing | wk11 - wk14 | Sprints run themselves; the team self-corrects without drama. | Lighten the scaffolding (see the Playbook below) and spend the saved energy on the product. |
| Adjourning | wk15 | Demo Day, submission, and the end of the team. Often bittersweet. | Close deliberately: the final reflection and contribution statements are the adjourning ritual. |
In prose: expect the beginning to feel easy and the middle to feel hard. The single most common team failure mode in a semester project is treating the first real conflict (usually around weeks 3-7) as evidence that the team is broken, and responding by disengaging. The charter’s conflict protocol, the psychological-safety norm below, and the scheduled wk8.0 charter revisit are all placed where they are because that is where teams need them.
Psychological Safety Is the Working Norm
Edmondson (1999) defines psychological safety as a team’s shared belief that the team is safe for interpersonal risk-taking, and found that teams with it learn faster because members surface problems, questions, and mistakes early instead of hiding them. In this course, psychological safety is not an aspiration; it is the operating requirement for every team activity:
- Questions are contributions. “I don’t understand our problem statement” said in week 3 is worth more than the same sentence said in week 12.
- Mistakes are data. The thread’s assessment philosophy (below) grades approach and process alongside product precisely so that reporting a failure honestly is never the losing move.
- Disagreement is a protocol, not a fight. Your charter names the procedure; the peer review activity teaches the repair moves.
- Feedback is specific and about the work. SQR cards and check-in forms are structured so that feedback names artifacts and behaviors, never persons and character.
The Team Playbook
The playbook is your team’s operating system. The structure is deliberately heavier early (forming and storming stages, wk1-8) and lighter later (norming and performing, wk9-15): scaffolding comes down as the team demonstrates it no longer needs it.
Standups
Open every team meeting (and post to your team channel between meetings, twice weekly through wk8, then at your discretion) with the three-line standup. Each member answers, in writing or out loud:
Since last time I: ...
Before next time I will: ...
I am blocked by / worried about: ...
The third line is the one that matters — it is the psychological-safety line. A standup where nobody is ever blocked is a standup where nobody is being honest.
Decision Log
Every non-trivial team decision gets one row in a running DECISIONS.md (or shared document). Format:
| Date | Decision | Alternatives Considered | Why | Primary Author | Revisit When |
|---|---|---|---|---|---|
| 2026-09-18 | Stakeholder: campus sustainability office | Local food bank; Bio dept lab group | Best access + clear agent-shaped problem | (member name) | If interview access falls through |
The decision log is what the “approach” rubric dimension reads. It also ends the “wait, why did we do it this way?” argument in week 13 — you look it up.
Meeting Agenda and Notes Discipline
- Through wk8: every meeting has a written agenda posted before the meeting and notes posted after (the POGIL Recorder owns this). Notes capture decisions, action items with owners and dates, and open questions.
- After wk8: agendas may be a single line, but decisions and action items are still logged. Sprint retrospectives always get full notes.
POGIL Role Rotation Cadence
Roles (Manager, Recorder, Presenter, Reflector in activities; Coordinator, Builder, Evaluator, Scribe in the final project) rotate:
- Weekly through wk8, so every member holds every role at least once before the final project begins.
- Per sprint from wk11 on, documented in the contribution statements.
Rotation is not optional and not tradeable: the point is that everyone practices every job, including the ones they would not volunteer for.
Assessment Philosophy
Three commitments govern how everything on the thread is graded:
- Milestones are evaluated on approach, professionalism/process, and product — in that order of emphasis early on. Early milestones weight the how heavily; the final project weights the what more. A team that interviews thoughtfully, logs its decisions, and reports honestly will outscore a team with a slicker artifact and no visible process.
- Your final-project grade combines team output, individual contribution, and individual understanding. The team’s artifact earns a team score; your contribution statement, primary-author sections, check-in record, and role-rotation history earn an individual contribution score; and your ability to explain and defend the work (in reflections, discussions, and Demo Day questions) earns an individual understanding score. Riding along is not a strategy, and neither is doing everything yourself.
- Authorship and AI use are always visible. Every team document names a primary author for each section — every student is primary author of at least one section of every team document — and every milestone carries an AI-use disclosure: what was AI-assisted, with what tool, and how the team verified the output. Disclosed, verified AI assistance is a professional practice; undisclosed AI assistance is an integrity violation.
Reflection: The Open Questions Run Through Everything (Goal 15)
Every thread milestone ends with reflection prompts keyed to the four Ursinus Open Questions. You will answer them in your Reflection Notebook, and by Demo Day you will have a semester-long record of your own growth to draw on. The standing mapping:
| Open Question | How It Shows Up on the Thread |
|---|---|
| What should matter to me? | Choosing a stakeholder and problem worth a semester of your attention; deciding what your project will refuse to do. |
| How should we live together? | The charter, psychological safety, conflict repair, and honest peer review — the entire teamwork strand. |
| How can we understand the world? | The literature review’s multi-disciplinary lens; what counts as evidence in CS versus in your stakeholder’s discipline. |
| What will I do? | The intervention you build, the skills you can now name, and what you will carry into the work you do after this course. |
How This Course Is Designed for Learner Agency
The structure of CS357 is deliberate choice architecture, in the spirit of Universal Design for Learning: you choose 5 labs from the 19 offered, 3 written assignments from the 7 offered, and 1 final-project track from 3 — so you can steer toward the work that matches your background, interests, and the stakeholder problem your team adopts, without any path being the “remedial” one. The Project Thread’s milestones are the shared spine everyone travels; the choices surround it. Reflection and expression admit multiple formats throughout (prose, diagrams, recorded demos where noted), presentations address more than one audience by design, and the transparency framing on each assignment (Purpose / Task / Criteria, per TILT) exists so that no one has to guess what “good” looks like. If a format barrier is getting between you and demonstrating what you know, say so — there is almost always an equivalent route.
Reflection Prompts
At each milestone you will find prompts keyed to these questions on that milestone’s page. To start the notebook now, answer in your first entry:
- What should matter to me? — What kind of problem would you be proud to spend a semester on, and why that one?
- How should we live together? — Describe the best team you have ever been on. What made it work, and what would it take to recreate that on purpose?
- How can we understand the world? — Name a discipline outside CS whose way of seeing problems you respect. What does it notice that CS tends to miss?
- What will I do? — What is one specific skill you want to be able to claim, with evidence, by Demo Day?
Submission
In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:- Describe what you did, how you did it, what challenges you encountered, and how you solved them.
- Please answer any questions found throughout the narrative of this assignment.
- If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
- Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
- Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
- Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
- Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
- Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).
Assignment Rubric
| Description | Pre-Emerging (< 50%) | Beginning (50%) | Progressing (85%) | Proficient (100%) |
|---|---|---|---|---|
| Approach (applied at every thread milestone; points are awarded on the individual milestone pages, not here) (35%) | The milestone artifact shows no evidence of a deliberate approach — decisions are unexplained and the work does not build on prior thread milestones | An approach is described but is generic; the artifact does not connect to the stakeholder, the literature, or the team's stated problem | The approach is deliberate and mostly connected — the artifact builds on prior milestones and cites its sources, with minor gaps in how alternatives were considered (Goals 11, 12) | The approach is deliberate, documented, and cumulative — the artifact names the alternatives that were considered and why they were rejected, grounds its claims in the Stakeholder Brief and Literature Review, and shows a multi-disciplinary understanding of the problem it addresses (Goals 11, 12) |
| Professionalism and Process (applied at every thread milestone; points are awarded on the individual milestone pages, not here) (35%) | There is no evidence of team process — no meeting notes, no decision log, no role rotation, and missing signatures | Some process artifacts exist but are incomplete — the decision log has gaps, signatures are missing from a progress report, or the AI-use disclosure is absent | The Team Playbook is followed with minor lapses — standups, decision log, meeting notes, role rotation, all-member signatures, and an AI-use disclosure are present, but one element is thin or late (Goal 13) | The Team Playbook is followed consistently — standup notes and the decision log are current, POGIL roles rotate on schedule, every progress report carries every member's signature, each team document names a primary author per section, and the AI-use disclosure states specifically what was AI-assisted and how it was verified (Goal 13) |
| Product (applied at every thread milestone; points are awarded on the individual milestone pages, not here) (30%) | The artifact is missing or does not meet the milestone's stated requirements | The artifact meets some requirements but would not be usable by its intended audience without significant rework | The artifact meets the milestone requirements and is appropriate for its intended audience, with minor gaps in polish or accessibility (Goal 14) | The artifact meets all milestone requirements and communicates effectively with its intended audience — it is complete, well-organized, honest about its limitations, and would be presentable to the stakeholder as-is (Goal 14) |
Please refer to the Style Guide for code quality examples and guidelines.