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

Purpose, Task, and Criteria

Purpose: To ground your semester project in a problem owned by a person outside CS, whether a real stakeholder you interview or a stakeholder persona that stands for your target audience, and to understand that problem through the disciplines it actually lives in, not only through ours.

Task: Anchor your team in a stakeholder outside CS: interview a real one if you can, or invent a stakeholder persona for your target audience and brainstorm the questions they would ask and your answers. Then 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 interview or persona brainstorm, 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 stakeholder outside computer science, real or a persona for the target audience, 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, or, without one, to anticipate a stakeholder persona's questions and answer them honestly
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 stakeholder outside computer science, learns their problem, and writes a 2-3 page Stakeholder Brief that states it in their own words. If you can interview a real stakeholder, do. If you cannot, invent a stakeholder persona who stands for your target audience, anticipate the questions that person would ask, and answer them as part of your brainstorm.

A stakeholder is a 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. A stakeholder persona is a realistic, researched description of such a person, written by your team when no real one is available.

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 partner from that roster, in a concrete stakeholder group your team identifies and I approve, or, if no interview is possible, in a stakeholder persona for your target audience.

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 audience-facing artifact your team presents at Demo Day.

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, 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 or persona	Your team claims a roster partner (or I approve a self-identified one) and sends a first message, or decides to build a stakeholder persona instead.	The day of the kickoff; see the course schedule.
3. Interview or persona brainstorm	A prepared, listen-and-learn conversation with consent recorded and a follow-up message sent, or a persona brainstorm that anticipates and answers the persona’s questions.	In the first week of the milestone; see the course schedule.
4. 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.
5. 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 or persona brainstorm has to happen in the first week, because the team drafts the brief from it. If you are interviewing, scheduling 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, and switch to a persona if no one answers in time.

Key Concepts

Term	Plain-English Definition	Where It Appears
Stakeholder	A 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. Often a community partner from the course roster shared in class.	Phase 2
Stakeholder persona	A realistic, researched description of a person in your target audience, written by your team when no real stakeholder can be interviewed: their role, context, pressures, vocabulary, and what a good day looks like.	Phase 3, Route B
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, Route A
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 4)
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 4)
Problem statement	One paragraph, traceable to the interview or persona brainstorm, stating the problem an agent system could address, without committing to a design yet.	Brief section 4 (Phase 4)
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 4)
Known unknowns	The concrete things you would need to find out before proposing anything, the edge of your understanding.	Brief section 6 (Phase 4)

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. What matters is that the brief reflects what your stakeholder, or your persona brainstorm, actually told you, so keep your notes and your packet as the source for every claim.

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 in the first week of the milestone?

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, or “students in general.” If your team is unsure whether a candidate qualifies, ask me before the interview.

If you cannot get an interview. A real conversation is the stronger route, but it is not required. If no stakeholder is available in time, build a stakeholder persona for your target audience instead (Phase 3, Route B). The persona still has to be specific and outside CS: “the evening-shift coordinator at a food bank” works, “users” does not. Log the decision in your decision log.

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 in time for the team to draft the brief.

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, or Brainstorm with a Persona

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.

There are two routes. Route A is a real interview, in four steps, documented in an interview packet. Route B, for teams that cannot get an interview in time, is a stakeholder persona and a brainstorm of the questions that persona would ask, documented in a persona packet. Either packet is attached to the brief as an appendix.

Route A: Interview a Real Stakeholder

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

Route B: Build a Stakeholder Persona and Brainstorm Its Questions

Use this route when no real stakeholder can be interviewed in time. The persona stands in for the person your project would serve, so it has to be specific and grounded in research, not invented from thin air.

Do this.

Research your target audience the way Step 3.1 describes: the public materials of the kind of office or organization they work in, and the basics of their field.

Write the persona in half a page: a role and setting (“the volunteer coordinator at a mid-sized food bank”), their daily context, the pressures they are under, the vocabulary they use, what a good day looks like for them, and what has already been tried.

Brainstorm at least six questions this persona would ask your team, in their voice. Think about what they would worry about: “Will this take more of my volunteers’ time, not less?”, “Who fixes it when it breaks?”, “Can I trust the numbers it gives me?”

Answer each question as part of your brainstorm, specifically and in the persona’s terms, not in CS terms.

Mark every answer as either supported (cite the source that backs it) or an assumption to verify. The assumptions become open questions in brief section 6.

Persona statements can stand in for quotes in brief section 2, as long as they are clearly labeled as the persona’s words and not a real person’s.

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

the persona (half a page) and the sources you researched it from

the six or more anticipated questions, each with its answer

each answer marked supported (with source) or assumption to verify

Phase 4: 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, or, on Route B, two persona statements labeled as the persona’s. 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 or persona brainstorm. 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 your interview or persona notes, not from a blank page or a prompt. Where teammates read the problem differently, write the disagreement down; it usually points 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, or from your persona packet. If the stakeholder declined to be named, describe the role, not the person. Label a persona as a persona.

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 or persona packet.

Write sections 5 and 6, then attach the interview or persona 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), or the persona packet appendix (persona, sources, anticipated questions and answers)

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 5: 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
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), or persona packet appendix (persona, sources, anticipated questions and answers)	That the interview followed the full protocol, or that the persona is grounded and its questions were answered honestly	Interview or Persona Brainstorm Quality (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 interviewed, or a clearly labeled persona grounded in research about our target audience.
The brief reports what they said (or, for a persona, what we anticipated and answered), and every persona answer is marked supported or an assumption to verify.
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 or persona brainstorm 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 stakeholder is identified, real or persona, or the "problem" is the team's own idea with no stakeholder behind it	A stakeholder or persona 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 stakeholder outside CS was interviewed, or a persona was built and brainstormed, and the issue is presented in their terms with supporting context, but the problem statement stops at the first framing rather than the problem behind it, drifts from the interview or brainstorm, or is too broad to act on	The brief presents either a real, named-with-consent stakeholder outside CS or a clearly labeled stakeholder persona that stands for the target audience, grounded in research about that audience; the issue appears in the stakeholder's own terms (at least two direct quotes or close paraphrases from the interview, or two persona statements labeled as such); the problem statement reaches the problem behind the stated problem, is specific, traceable to the interview or brainstorm, and framed as something an agent system could plausibly address; the "what we don't yet know" section names concrete open questions, including which persona answers are assumptions still to verify (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 or Persona Brainstorm Quality (20%)	Neither an interview nor a persona brainstorm is documented	An interview took place but was unprepared or is missing its consent record, or a persona was written but its questions were not anticipated and answered	The interview followed the protocol with a minor gap such as a missing follow-up thank-you, or the persona brainstorm answers at least six anticipated questions but the answers stay generic or do not separate assumptions from what is known	Route A (interview): the packet shows researched prep questions written in advance, a listen-and-learn record in which the stakeholder talks more than the interviewers, explicit consent to be named (or anonymization), and a follow-up message with the stakeholder's confirmation or corrections. Route B (persona): the packet shows a persona grounded in research about the target audience (role, context, pressures, vocabulary, what a good day looks like), at least six questions that persona would ask, answered specifically in the persona's terms, with each answer marked as supported by a source or as an assumption to verify
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.