CS357: Foundations of Artificial Intelligence - Stakeholder Brief (100 Points)

Purpose, Task, and Criteria

Purpose: To ground your semester project in a real problem owned by a real person outside CS, and to understand that problem through the disciplines it actually lives in, not only through ours.

Task: Anchor your team in a real community partner (from the course partner roster shared in class, or an approved stakeholder group), conduct a prepared listen-and-learn interview, and write a 2-3 page brief with six required sections that frames the problem in the stakeholder's own terms.

Criteria: I grade this on the issue in the stakeholder's own terms, at least two disciplinary perspectives that actually interact, a documented professional interview, and an account of what you do not yet know. 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 by finding a real stakeholder outside computer science and learning their problem in their own terms (Goal 11)
To develop a multi-disciplinary understanding of the problem, naming the disciplinary perspectives involved and how each frames what a solution would mean (Goal 12)
To conduct a professional, well-prepared, listen-and-learn stakeholder interview with appropriate consent and follow-up etiquette
To translate a stakeholder's account into a problem statement that an agent system could address, honestly scoped by what the team does not yet know

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Project Thread (semester map, team playbook, and assessment philosophy)
Structured Peer Review: the SQR protocol used at the brief exchange
Shulman, L. S. (2005). Pedagogies of Uncertainty. Liberal Education, 91(2), 18-25.

The Assignment

In this Project Thread milestone, your team finds a real stakeholder outside computer science, interviews them, and writes a 2-3 page Stakeholder Brief that states their problem in their own words.

A stakeholder is a real person or office who owns the problem: they experience it, they would benefit from progress on it, and they can tell you when you have misunderstood it.

The brief ends in a problem statement: one paragraph, traceable to the interview, that names a problem an agent system could address without committing to a design. Along the way you describe the disciplines the problem lives in. A discipline is a field of study or practice, such as education, accounting, ecology, or public health, with its own way of deciding what counts as evidence and what “solved” means.

I identify the community partners: campus offices and local organizations who have agreed to talk with student teams. I share the roster in class before the kickoff rather than publishing it on the website. Your team anchors its brief in one real partner from that roster, or, while the roster is pending, in a concrete named stakeholder group your team identifies and I approve.

This brief does more work later in the semester than any other early deliverable. It anchors your Literature Review. It becomes the stakeholder-needs section of your Final Project proposal on any of the three tracks. And it seeds the partner-facing artifact your team presents at Demo Day, so the understanding you build here is understanding you hand back to a real person.

The point of this milestone is a professional skill CS courses rarely practice: problem finding before problem solving. Real problems do not arrive as specs. They arrive as a person describing a frustration, in the vocabulary of their own field, with the important constraints unstated. Sitting in that uncertainty without rushing to a solution is what Shulman (2005) calls a pedagogy of uncertainty. It is also the difference between building something and building something useful.

Timeline

This is a team assignment with one individual gate in the middle, and the order matters more here than in anything else this term. The course schedule is the authority on every date; this table names the phases and the order they happen in.

Phase	What happens	When
1. Kickoff	I hand out the assignment in class and you run the speed-dating round that generates candidate problems.	See the course schedule.
2. Stakeholder contact	Your team claims a roster partner (or I approve a self-identified one) and sends a first message.	The day of the kickoff; see the course schedule.
3. Interview	A prepared, listen-and-learn conversation with consent recorded and a follow-up message sent.	In the first week of the milestone; see the course schedule.
4. Individual problem statement	Each member writes half a page alone, without AI, and submits it individually.	After the interview and before team drafting; bring it to the MCP: Connecting Agents to Tools and Your Obsidian Vault session. See the course schedule.
5. Team brief draft	The team writes the 2-3 page brief and the interview packet, with any tools and with disclosure.	Before the peer exchange; see the course schedule.
6. Peer exchange and revision	Teams swap drafts in class using SQR cards, then revise and submit.	At the RAG Quality: Chunking and Measuring Retrieval session; the revised brief is due by the date in the course schedule.

Time budget. The milestone spans a little over three weeks on purpose, but the interview has to happen in the first week, because your individual statement is written after it. Scheduling the interview is the long pole: a person has to answer you, and you do not control that lead time. Start on it the day the assignment is handed out.

Key Concepts

Term	Plain-English Definition	Where It Appears
Stakeholder	A real person or office, outside computer science, who owns the problem: they experience it, they would benefit from progress on it, and they can tell you when you have misunderstood it. Usually a community partner from the course roster shared in class.	Phase 2
Listen-and-learn stance	An interview posture in which your goal is to understand, not to pitch. You ask probing questions, you follow up, you listen for the problem behind the stated problem, and you do not propose solutions in the first meeting.	Phase 3
The problem in the stakeholder’s own terms	The issue as the stakeholder describes it, in their vocabulary, before any translation into CS language. Captured with quotes.	Brief section 2 (Phase 5)
Disciplinary perspective	A field’s characteristic way of framing the problem: what it notices, what it measures, what counts as evidence, what “solved” means.	Brief section 3 (Phase 5)
Problem statement	One paragraph, traceable to the interview, stating the problem an agent system could address, without committing to a design yet.	Brief section 4 (Phase 5)
Track fit	A short argument that the problem could support any of the three final-project tracks (build, audit, or open-source), keeping your options open until the final-project tracks are handed out.	Brief section 5 (Phase 5)
Known unknowns	The concrete things you would need to find out before proposing anything, the edge of your understanding.	Brief section 6 (Phase 5)

Before You Start

You need these in place before the kickoff:

Your team charter and roles from the Project Thread, including a Recorder and a decision log. The kickoff and the stakeholder choice both get logged there.
The partner roster, which I share in class. It is not on the website.
A way to reach me quickly (a one-sentence message on Teams is enough) to confirm a stakeholder choice or ask for an introduction.
The Structured Peer Review activity, read before the exchange session, so you know how SQR cards work.

Start the stakeholder contact this week. If nobody on your team knows a fitting partner, ask me. I will broker an introduction within one week of the request, and no team’s brief is blocked by the roster. What blocks teams is waiting until week two to discover they have nobody.

Why this matters. AI is not forbidden in this milestone; the team brief and the peer exchange are open, with disclosure. The individual draft in Phase 4 is the one unassisted step, and it is a gate I do enforce. It exists so that your team’s brief is a synthesis of several people’s actual understanding rather than several people editing one machine’s framing. You will notice the difference in the peer exchange, in both directions.

Phase 1: Generate Candidates at the In-Class Kickoff

Before any team commits to a stakeholder, we generate candidates together. Topics come out of conversation, not out of a solo brainstorm. In class, you run a speed-dating round: pairs of students rotate every four minutes, and in each pairing both people answer one question: “What is a problem you have personally seen in a campus office, a local organization, or another department, and who owns it?”

Do this.

Rotate through the speed-dating pairings. Answer the question yourself in each one and listen for the problems your partner names.

Have your team’s Recorder collect every candidate mentioned across all of your pairings.

Before class ends, short-list three candidates as a team and rank them on three questions:

Access: can you realistically get an interview before the individual statement is due?

Shape: could an agent system plausibly help?

Interest: does the domain match your team’s survey rankings?

Claim a roster partner if one fits (first come, logged in the decision log).

Checkpoint. Your decision log records the three-candidate ranking and the choice your team made. If the top candidate is not on the roster, it also records that you will clear it with me before first contact.

Phase 2: Identify a Real Stakeholder and Make Contact

Start with the partner roster. The partners on it have already been contacted and expect to hear from student teams, so anchoring your brief in a roster partner means your interview access is real, not hoped-for. Teams claim partners at the kickoff.

If the roster does not yet fit, do not wait. You have two other options:

If the roster is still being finalized, or your speed-dating round surfaced a stronger candidate, anchor in a concrete stakeholder group of your own: a named office or a specific organization with a person you can actually interview. Clear it with me before first contact.
If the roster does not yet name a partner that fits your team’s problem, draw immediately from the standing on-campus stakeholder list: Disability and Access Services, the library, the Office of Sustainability, the Center for Writing and Speaking, Community Engagement/UCARE, and Athletics operations. Any office that serves real users counts. Confirm your choice with me in one sentence on Teams.

If nothing on the roster or the standing list fits your team’s interests, ask. I will broker an introduction to a suitable partner within one week of the request.

Whether from the roster or self-identified, the stakeholder must be real and outside computer science. Good candidates:

Campus offices: sustainability, library, registrar, accessibility services, career services, admissions, facilities, dining
Local organizations: nonprofits, community centers, historical societies, food banks, small businesses, municipal offices
Another discipline on campus: faculty or students in biology, education, environmental studies, economics, art, health sciences, anyone with a research or operational problem outside CS

Not acceptable: another CS student or CS faculty member’s tooling problem, a hypothetical persona, or “students in general.” If your team is unsure whether a candidate qualifies, ask me before the interview.

Do this.

Pick your stakeholder from the roster, the standing list, or your own approved candidate, and log the choice in your decision log.

If the stakeholder is not from the roster, send me one sentence on Teams naming them, and wait for my confirmation before first contact.

Send one short, professional message to the stakeholder. Say who you are, what the course is, what you are asking for (a 30-minute conversation about a problem in their work, not a commitment of any kind), and when you can meet.

Copy me on the message if you want a credibility boost.

Propose meeting times inside the first week of the milestone, so the interview lands before the individual statement is due.

Watch out. A person has to answer you, and that is the one step in this milestone whose timing you do not control. Send the first message the day of the kickoff. If you have not heard back in a few days, send one polite follow-up and tell me, so I can help before the schedule slips.

Phase 3: Interview the Stakeholder

Understand before you invent. This milestone teaches you to see the issue from the stakeholder’s perspective (their pressures, their constraints, their definition of a good day) before your team generates a single solution idea. You are not visiting a partner to validate a project concept. You are there to learn what the problem feels like from inside their work. Ideation comes later, and it will be better for the wait.

The interview protocol has four steps. Your interview packet, which you attach to the brief as an appendix, documents each one.

Step 3.1: Prepare

Good interviews are researched before they happen. Read the stakeholder’s context first (their office’s public materials, the basics of their discipline) so that your questions show you did the work and so that the meeting time goes to what only they can tell you.

Do this.

Research the stakeholder’s context: their office’s public materials and their discipline’s basics.

Write at least six prep questions in advance. Good prep questions are open and concrete:

“Walk me through the last time this problem cost you an afternoon.”

“Who else is affected when this goes wrong?”

“What have you already tried, and what happened?”

“What would a good outcome look like, in your terms?”

“What should we read to understand your field’s view of this?”

“Is there data or paperwork this problem produces that we could see?”

Decide who interviews and who records. One member interviews while another records.

Step 3.2: Listen and Learn

In the meeting, your job is to understand. Do not pitch. Three ground rules:

The stakeholder does most of the talking. Follow-up questions (“can you say more about…?”) beat new questions.
Propose no solutions in the first meeting. A premature “we could just build an app that…” teaches the stakeholder to stop describing the problem.
Listen for the problem behind the stated problem. The first framing a stakeholder offers is often a symptom or an already-imagined fix (“we need a better spreadsheet”). Keep probing until you can hear the constraint underneath it (“no one can see who changed what, so nobody trusts the numbers”).

Quoted-with-permission language is what lets your brief present the issue in the stakeholder’s own terms rather than yours.

Do this.

Open with your prep questions, then follow the stakeholder’s answers with follow-up questions rather than moving to the next item on your list.

Capture direct quotes as they happen, and ask permission in the moment (“that’s a great way to put it; may we quote that in our writeup?”).

Keep notes that show who said what. The record should show the stakeholder talking more than the interviewers.

When you hear an already-imagined fix, ask what goes wrong today without it, and write down the constraint underneath.

Ask explicitly: “May we name you and your office in our course writeup, or would you prefer we describe you generically?” Record the answer and honor it in the brief. If they decline to be named, the brief still works; describe the role, not the person.

Do this.

Ask the consent question before the meeting ends.

Write the answer down in your notes, with the date, as the consent record.

Note separately which quotes you have permission to use.

Step 3.4: Follow Up

The follow-up message is your first accuracy check, and it keeps the door open for the rest of the semester.

Do this.

Within 48 hours, send a thank-you message.

Include a two-or-three sentence summary of the problem as you understood it, and ask them to correct anything you got wrong.

Save their confirmation (or correction) for the interview packet.

Paste into your submission. The interview packet, attached to the brief as an appendix:

the prep questions you wrote in advance (at least six)

your interview notes, showing who asked and who answered

the consent record: whether the stakeholder agreed to be named, and which quotes you may use

the follow-up exchange: your thank-you and summary, and the stakeholder’s confirmation or corrections

Phase 4: Write Your Own First Draft, Without AI

Bring to class. Your half-page unassisted problem statement comes with you to the MCP: Connecting Agents to Tools and Your Obsidian Vault session, written individually and without AI before your team drafts the brief. It is a calibration baseline, not a test, completion credit only. Your team’s brief draft then travels to the RAG Quality: Chunking and Measuring Retrieval session for the cross-team peer review round.

This statement is due individually after your interview and before your team begins drafting the brief in Phase 5; see the course schedule for the date. It is worth 3 points, assessed within Class Activities and Participation, on completion only.

This is a calibration exercise, not a test. It is not compared against your teammates’ drafts, it is not marked for quality, and nothing in it can lower your grade. It exists for two reasons, both of them yours:

It gives you something to bring. The standing thread principle is independent work before group work, the same reason the Literature Review’s annotated bibliographies are individual. A team synthesis is only a synthesis if there were several real contributions to reconcile. Teammates who each thought about the problem alone first will write a better brief than teammates who watched one person type.
It is a baseline you can point at. Later in the semester you will want to know what you can do unaided, because that is the only way to tell whether a tool is extending your judgment or substituting for it. Keep this draft. Re-read it at Demo Day.

Do this.

After your interview and before your team writes anything together, sit down by yourself with no AI assistance of any kind.

Write half a page: what you now believe the stakeholder’s real problem is, in your own words, and the one thing you are least sure about.

Stop there. No sources, no polish, no rewriting it later. A first honest attempt.

Bring it to class in whatever form you wrote it (typed, handwritten, or a photo of the page).

Paste into your submission. Submit the half-page statement individually via the LMS, in whatever form you wrote it. Because this one is unassisted by design, it carries no AI-use disclosure: there is nothing to disclose, and that is the point.

Phase 5: Write the Brief

Write 2-3 pages with the six sections below. Every section names its primary author, and every member is primary author of at least one section (the standing Project Thread rule). This phase is open to whatever tools you want, with disclosure.

Stakeholder context. Who they are (as consented), what their office or field does, and how this problem fits into their work.
The issue in the stakeholder’s own terms. Their framing, their vocabulary, at least two direct quotes or attributed close paraphrases. Resist translation; that comes later.
Disciplinary perspectives involved. At least two perspectives beyond CS. For each: what does this discipline notice about the problem, what would count as evidence, and what would “solved” mean? Name at least one point where the perspectives pull in different directions.
A problem statement an agent system could address. One paragraph, traceable to the interview. State the problem, not a design.
Candidate track fit. Two or three sentences per direction showing the problem could support all three directions of the Final Project: a built Custom Agent Team, a Responsible AI Audit of an existing or proposed system in this domain, or an Open-Source Agent artifact the stakeholder’s community could adopt. You are not choosing a track yet; you are proving the problem is rich enough to keep the choice open.
What you don’t yet know. Concrete open questions: missing facts, unverified assumptions, and things only the literature (or a second conversation) can answer. This section seeds your Literature Review.

Do this.

Start from the individual statements, not from a blank page or a prompt. Reconcile where they disagree; the disagreements usually point at section 6.

Assign a primary author to each section, and check that every member is primary author of at least one.

Write sections 1 and 2 from your interview notes and permitted quotes. If the stakeholder declined to be named, describe the role, not the person.

Write section 3 so that the two disciplines interact, not sit in separate paragraphs: say what each notices that the other misses, and where they pull against each other.

Write section 4 as one paragraph, and check that every claim in it traces back to something in the interview packet.

Write sections 5 and 6, then attach the interview packet as an appendix.

Record what, if anything, was AI-assisted, with what tool, and how the team verified it.

Paste into your submission. One PDF containing:

the 2-3 page brief with all six sections, primary author named per section

the interview packet appendix (prep questions, notes, consent record, follow-up exchange)

all team members’ typed signatures, re-affirming your charter

an AI-use disclosure: what, if anything, was AI-assisted, with what tool, and how the team verified it

Phase 6: Exchange Drafts and Revise

At the RAG Quality: Chunking and Measuring Retrieval session, teams exchange draft briefs in class for structured peer review using SQR cards (Strength / Question / Risk). The protocol, and how to give and receive this feedback well, is in the Structured Peer Review activity. The cycle is artifact -> peer review -> revise, and it repeats at the proposal and the gallery walk.

Do this.

Bring your team’s draft brief to the session.

Read the other team’s draft and write one SQR card: one Strength with evidence, one genuine Question, and one Risk with a suggested mitigation.

Collect the card written about your draft.

Revise the brief in response before the due date, so the revised version is what feeds the Literature Review.

Checkpoint. Your revised brief answers the Question on the card you received, or your team can say why it does not need to. The Risk is either mitigated in the revision or named in section 6 as an open question.

Deliverables

File or artifact	What it shows	Rubric row
Half-page unassisted problem statement, submitted individually via the LMS by the date in the course schedule	What you believed the stakeholder’s real problem was, unaided, after the interview	3 points, Class Activities and Participation, completion only
The 2-3 page brief (six sections, primary author named per section), in the team PDF via the LMS by the brief’s due date	The issue in the stakeholder’s own terms, the disciplinary perspectives and where they conflict, the problem statement, the track fit, and what you do not yet know	Problem Identification and Research Grounding (30); Multi-Disciplinary Understanding (30); Writeup, Process, and Submission (20)
Interview packet appendix (prep questions, notes, consent record, follow-up exchange)	That the interview followed the full protocol and the stakeholder confirmed your understanding	Interview Quality and Professionalism (20)
All team members’ typed signatures, re-affirming your charter	That every member stands behind the submission	Writeup, Process, and Submission (20)
AI-use disclosure (what, if anything, was AI-assisted, with what tool, and how the team verified it)	How the team used tools and checked their output	Writeup, Process, and Submission (20)
Reflection prompt answers, written individually	What changed in your understanding	Writeup, Process, and Submission (completeness)

Self-Check Before You Submit

The stakeholder is a real person or organization we could contact, not a persona.
The brief reports what they said, with quotes or specific paraphrase, not what we assumed they would say.
Every team member’s individual unassisted draft was written before team drafting began, and is included.
The problem is framed as their problem, in their terms, and would be recognizable to them.
Constraints they named are recorded even where they are inconvenient for the system we want to build.
We separated what they told us from what we inferred.
SQR cards given to another team: one Strength with evidence, one genuine Question, one Risk with a suggested mitigation.
AI disclosure states what was AI-assisted and how we verified it.
Contribution statement says who did what.

Reflection Prompts

Answer individually in your submission, keyed to the Open Questions (Goal 15):

What should matter to me? Before the interview you had assumptions about what this stakeholder’s real problem was. Which assumption died first, and what does the gap between what you expected to matter and what actually mattered to them tell you about how you choose problems?
How can we understand the world? Name one thing the stakeholder’s discipline treats as obvious evidence that CS would not, or vice versa. What would your team lose by using only one of the two lenses?

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).
Please describe any use of outside resources you may have engaged in the completion of this assignment, including the use of generative Artificial Intelligence.

Assignment Rubric

Description	Pre-Emerging (< 50%)	Beginning (50%)	Progressing (85%)	Proficient (100%)
Problem Identification and Research Grounding (Goal 11) (30%)	No real stakeholder is identified, or the "problem" is invented by the team rather than drawn from the stakeholder	A stakeholder is named but the issue is described in the team's words rather than the stakeholder's, or the brief shows no preparation research about the stakeholder's context	A real community partner outside CS was interviewed and the issue is presented in their terms with supporting context, but the problem statement stops at the partner's first framing rather than the problem behind it, drifts from what the stakeholder actually said, or is too broad to act on	The brief presents a real, named-with-consent community partner outside CS (from the course partner roster shared in class, or an instructor-approved stakeholder group); the issue appears in the stakeholder's own terms (with at least two direct quotes captured with permission, or attributed close paraphrases); the problem statement reaches the problem behind the stated problem, is specific, traceable to the interview, and framed as something an agent system could plausibly address; the "what we don't yet know" section names concrete open questions rather than generic uncertainty (Goal 11)
Multi-Disciplinary Understanding (Goal 12) (30%)	The brief treats the problem as purely technical, with no disciplinary perspective beyond CS	One non-CS perspective is name-checked ("this is also an education problem") without any account of how that discipline sees the issue	At least two disciplinary perspectives are identified with a plausible account of each, but the brief does not connect them, the perspectives sit in separate paragraphs without interaction	The brief names at least two disciplinary perspectives beyond CS involved in the problem, explains what each discipline notices that the others miss (including what would count as evidence or success in that discipline), and identifies at least one point where the perspectives are in tension, a place where the eventual project will have to choose (Goal 12)
Interview Quality and Professionalism (20%)	No interview took place, or the interaction is undocumented	An interview took place but was unprepared, no prep questions, no record of what was asked, or missing consent to be named	The interview followed the protocol with prep questions and a documented listen-and-learn stance, with a minor gap such as a missing follow-up thank-you or an unclear consent record	The interview packet shows the full protocol, researched prep questions written in advance, a documented listen-and-learn stance (the record shows the stakeholder talking more than the interviewers), explicit consent to be named (or the brief anonymizes accordingly), and a follow-up message thanking the stakeholder and confirming the team's understanding, with the stakeholder's confirmation or corrections noted
Writeup, Process, and Submission (20%)	An incomplete submission is provided	The brief is submitted but misses the length or required sections, or lacks per-section primary authors or signatures	The brief is complete and well-organized with all Project Thread process elements present, with a minor omission such as a thin track-fit section covering fewer than all three final-project tracks	The 2-3 page brief contains all required sections including a candidate track fit that works for all three final-project tracks; every section names its primary author and every member is primary author of at least one section; the submission carries all members' signatures (Goals 13, 14)

Please refer to the Style Guide for code quality examples and guidelines.