CS357: Foundations of Artificial Intelligence - The Project Thread: A Semester-Long Multidisciplinary Project
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
- 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)
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 6.0) |
| Team Charter | A short, signed team contract stating your team’s norms, roles, decision rules, conflict repair process, and accountability procedures. A living document: re-read at every check-in, revised at midterm. | Charter activity (week 1.1); every check-in; 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 (proposal week 11; sprints weeks 12 to 14) |
| 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 Overview assignment’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 |
| wk5.0 | Peer review round 1 | Brief drafts are exchanged across teams for SQR review; first private intra-team check-in goes to the instructor. | Structured Peer Review activity |
| wk6.0 | Stakeholder Brief due | 2-3 page brief, revised after peer review: the issue in the stakeholder’s own terms, the disciplines involved, a problem statement an agent system could address. | Stakeholder Brief |
| wk6.0 → wk9.1 | Literature Review | Phase 1 (individual annotated bibliographies) due wk8.0; Phase 2 (team synthesis) due wk9.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.0 | Peer review round 2 | Second private intra-team check-in to the instructor, now with the confidential peer pulse (below). | 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 |
| wk12 → wk14 | Sprints | Build in sprints with rotating roles, runnable increments, and evaluation updates. | Track pages |
| wk14.0 → wk14.1 | Gallery walk + peer review round 3 | Walk each other’s work with SQR cards at the wk14.0 studio; the third private intra-team check-in follows at wk14.1, reflecting on what the gallery walk surfaced. | Track pages |
| wk15.0 | Demo Day | Technical demo, a non-technical stakeholder-facing segment, and a disseminable artifact — the team’s deliberate adjourning: final reflection, contribution statements, and your professional portfolio artifact close the thread. | 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, contribution statements, and your professional portfolio artifact (pinned repo, project story, drafted post) are the adjourning ritual — the team ends by each member naming what they can now claim. |
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 Charter: A Signed Team Contract
Your team’s first deliverable is not technical — it is a contract, in the style of the team contracts used in WPI’s project-based curriculum: a short document, drafted together at the wk1.1 charter activity and signed by every member by wk2.0, that turns “we’ll figure it out” into commitments you can point to later. The charter must cover seven things:
- Norms and values. Three to five concrete, behavioral norms — not “communicate well” but “if you will miss a deadline, say so in the channel at least 24 hours out.” Start from your survey answers: the pet peeves and “what matters most” answers your members choose to share are the raw material.
- Meeting cadence with a rotating agenda-owner. When and where the team meets (built from your overlapping survey windows), and who owns the agenda — a role that rotates each week, so no one person becomes the team’s default manager. The agenda-owner posts the agenda before the meeting and confirms notes exist after it.
- Rotating roles, with responsibilities in writing. The POGIL roles you already use in class — Manager, Recorder, Presenter, Reflector — carry directly into project work. The charter states, in a sentence each, what each role owes the team that week, and records the rotation schedule (weekly through wk8, per sprint after; see the Playbook below). Rotation is a charter commitment, not a suggestion.
- Communication channels and response-time expectations. Which channel is for what (decisions vs. logistics vs. drafts), and how quickly a teammate is owed a reply (e.g., 24 hours on weekdays, no expectation after 9pm). Most “my teammate is ignoring me” conflicts are actually unstated response-time mismatches.
- Decision-making process. How the team decides when it disagrees — consensus with a fallback vote, Manager breaks ties, “disagree and commit” with a revisit date — and the standing rule that every non-trivial decision lands in the decision log.
- A conflict repair process. Name friction early, while it is still small; raise it inside the team first, using the move your charter names (many teams use the SQR framing: a strength, a question, a risk — about the situation, not the person); and escalate to the instructor as backstop, not as first resort. Going to the instructor is never a betrayal — but the repair skill you are here to practice lives in the step before that.
- Psychological-safety ground rules. Concrete commitments that make it safe to speak up: questions are never mocked, mistakes reported early are thanked, disagreement is addressed to the work. This is not team-building decoration — Edmondson (1999) found that this one condition, the ability to speak up without punishment or humiliation, accounts for much of the variability between high- and low-performing teams.
Every member signs. And the charter is a living document: your team re-reads it at each intra-team check-in (below), asks “does this still describe us?”, and files a formal revision at the wk8.0 revisit. A charter that never changes is a charter nobody is reading.
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. The two role sets are deliberately different: the activity roles (Manager/Recorder/Presenter/Reflector) rotate within POGIL class sessions, while the project roles (Coordinator/Builder/Evaluator/Scribe) rotate across the sprint weeks.
- Weekly through wk8, so every member holds every role at least once before the final project begins.
- Per sprint during the sprint weeks (wk12 → wk14), 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.
Intra-Team Check-Ins 1-3
Three times in the semester — wk5.0, wk10.0, and wk14.1 — your team pauses for a structured check-in. Each check-in carries 3 points, assessed within Class Activities and Participation — enough to make it a real commitment, small enough that the check-in itself, not the score, is the point. Every check-in has the same two parts:
- A short team progress report, signed by all members: what shipped since the last milestone, what is next, and the current risks. Three sections, half a page, honest. The signatures matter — signing a report you know is rosy is the small version of every engineering-ethics case study you will ever read.
- A confidential individual team-health pulse to the instructor: a few private sentences on how the team is working for you — not a report on your teammates, but on your experience. Is your voice landing? Is your workload fair? Is there anything you cannot raise in the room? This channel exists precisely for the things psychological safety has not yet made sayable; it is read only by the instructor and never quoted back.
The three check-ins are timed to the Tuckman map above, and each has a stage-specific focus:
| Check-In | When | Tuckman Transition | Team Focus |
|---|---|---|---|
| 1 | wk5.0 | Storming → Norming | Surface the differing values and work styles the first real disagreements have exposed, and set (or reset) ground rules. Re-read the charter: which norm has been hardest to keep? |
| 2 | wk10.0 | Norming → Performing | Audit the mechanics: are roles actually rotating, or has the team quietly specialized? Is anyone under-loaded or over-loaded? Fix it now, before the sprints amplify it. |
| 3 | wk14.1 | Performing → Adjourning | Look back deliberately: capture what this team learned about collaboration — the norms that worked, the repair that succeeded, the thing you would put in your next team’s charter on day one. |
Each team progress report answers three stage-specific prompts alongside the standard shipped/next/risks sections:
- Check-In 1 (storming into norming): (a) Name one place where two members’ working styles or standards differed — what ground rule did you set or reset in response? (b) Which charter norm has been hardest to keep, and what will you change? (c) Name one thing a teammate did that made it safer to speak up.
- Check-In 2 (norming into performing): (a) Role-rotation audit: list who has held each role so far — where has the team quietly specialized? (b) Workload audit: where is effort unbalanced, and what is the rebalancing plan for the sprints? (c) What shorthand or rhythm has this team developed that should be codified in the charter revision?
- Check-In 3 (performing into adjourning): (a) What would you put in your next team’s charter on day one, based on this team? (b) Name one repair that succeeded — a conflict or slippage the team actually recovered from, and how. (c) What will each member claim, with evidence, on Demo Day and beyond?
The confidential peer pulse (Check-Ins 2 and 3). At the second and third check-ins, the individual pulse adds a short structured section, adapted from the CATME behaviorally-anchored peer-evaluation dimensions (see the research base above): rate yourself and each teammate from 1 to 5 on (1) contributing to the team’s work, (2) interacting with teammates, (3) keeping the team on track, (4) expecting quality, and (5) having relevant knowledge and skills — with one sentence of evidence for any rating of 2 or below. Three commitments about how this is used: it is read only by the instructor; it is never mechanically averaged into anyone’s grade; and it informs the individual-contribution component of the final project grade and triggers a coaching conversation when self- and peer-ratings diverge sharply. It is a health instrument, not a weapon.
At every check-in, the team re-reads its charter against its actual behavior. The charter is a living document; the check-ins are where it lives.
Why So Much Process?
Because the process is the pedagogy. Standups, decision logs, rotating roles, signed reports, and check-ins are graded not despite being overhead but because they are the curriculum: the project is the vehicle for learning collaborative inquiry, not the destination. Any of you could learn to build an agent system alone; what you cannot learn alone is how to find a problem with a stakeholder, hold a team together through storming, disagree productively, and repair a working relationship — and those skills live entirely in the process. The artifact you demo in week 15 will be obsolete in a year. The way your team produced it will not.
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 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: everyone completes the same 6 labs, 3 written assignments, and 1 team final project, and every one of them offers directions you choose inside it — 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?
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) |