Paper 2 - Application

Length: 1,500–2,000 words (approx. 6–8 double-spaced pages), excluding references and appendices

First draft is due Nov 4, end of the day

Final draft is due Nov 18, end of the day

For this application paper, there are three options you can choose from. You will complete this assignment individually for the first two assignment options or optionally in pairs for option 3.

Learning Objectives

By completing this assignment, you will be able to:

  1. Apply the concepts from our discussions to a concrete case.
  2. Gather and interpret evidence about how a technology affects people, through imagination grounded in research (Option 1), interviews (Option 2), or systematic testing (Option 3).
  3. Identify who benefits from and who is harmed by a technology, including people who are not its users.
  4. Communicate ethical reasoning to a specific audience: readers of fiction, app developers, or the people responsible for an automated system.
  5. Practice writing with evidence, citation, and revision.

Overview

In Assignment 1 you analyzed a technology from the outside, through its patent. In this assignment you apply that kind of thinking to something more hands-on. You will pick one of three options:

Option What you produce Main evidence Work mode
1. Science Fiction Short Story A short story plus an author’s note Research on a real technology Individual
2. App Recommendations A requirements and recommendations report Interview(s) with a prospective user, compared to an LLM Individual
3. Bias Auditing An audit report Systematic tests of a real system Individual or pair

All three options share the same core: a specific technology, specific people it affects, an explicit use of course concepts, and a conclusion that someone could act on. They differ in genre. Choose the one that best fits what you want to practice, not the one you think is easiest. Each is about the same amount of work.

Working in Pairs

If you work with a partner:

  • Both partners are responsible for the whole paper and receive the same grade.
  • Both names go at the top of the google doc.
  • Include a short contribution statement at the end of the paper (2–4 sentences, not counted in the word count) describing what each partner did. Both partners should do substantive writing. Splitting the work as “one person tests, the other writes” is not acceptable for a Writing Intensive course.
  • Pairs are expected to show more depth than individual papers: Option 3 requires the creation of test cases and data analysis and interpretation (I can help with the technical parts of data analysis).
  • If a partnership breaks down, let me know before the first draft is due, not after.

Option 1: Science Fiction Short Story

Write a piece of science fiction that explores the social and ethical implications and impacts of a particular technology.

Good science fiction about technology is less about the gadget and more about the people living with it. Think of the readings and case studies we discussed: the most revealing stories show a technology working as designed and still producing harm, or show who adapts, who resists, and who never got a choice.

Here’s an example science fiction short story if you need to get a sense of this genre.

Requirements

  • Ground it in something real. Your story must be anchored in a technology that exists today or is plausibly near (e.g., a patent, a product, a research prototype, a policy proposal). Extrapolate from it, but don’t invent physics. Cite your sources in the author’s note.
  • Show, don’t lecture. The ethical issues should emerge through characters, choices, and consequences, not through a character explaining the moral of the story.
  • Include more than one perspective. At least two characters (or groups) should experience the technology differently. Consider including someone who is affected by the technology but never chose to use it.
  • Leave room for disagreement. As in paper 1, a story where the technology is purely evil (or purely good) is less interesting than one in which a reasonable person could see it either way.

Structure

Part What it does Approx. words
Short story The fiction itself, with a title 1,200–1,600
Author’s note Include 1) the real technology your story is based on (with citations); 2) the ethical issues you set out to explore; 3) whose experience did you center?; 3) what a reader should take away 300–400

Grading Rubric (Option 1)

We will be grading your paper on a 20-point scale:

  • Grounding in a real technology (4 points)
    • the technology is real or plausibly near, and accurately described
    • the extrapolation is believable and supported by cited research
  • Exploration of ethical implications (6 points)
    • ethical issues emerge through the narrative rather than being explained
    • multiple perspectives and stakeholders, including non-users
    • the story illuminates who benefits and who bears the costs
    • complexity: the story does not reduce to a simple moral
  • Author’s note (5 points)
    • clearly identifies the technology and its sources
    • explicitly connects the story to course concepts
    • reflects on the choices you made as a writer and why
  • Craft and mechanics (5 points)
    • coherent narrative with a clear arc, characters, and setting
    • prose is clear, purposeful, and proofread
    • meets length and citation requirements

Option 2: App Recommendations

For this assignment, come up with a set of requirements for a fictional app that aims to address a real-world issue. As part of this assignment, you will conduct at least one interview with a prospective user of the app, paying special attention to the use cases, desired functionality, and concerns brought up by the interviewee. You will then use the same questions to prompt an LLM.

You will summarize the interview findings in a short report, describe the main functional requirements of the app, and provide general recommendations to the app developers on how to implement this functionality while respecting user privacy, welfare, freedom from bias, ownership and property, and informed consent. Compare the answers given by a human interviewee versus the LLM.

You have access to LLM tools through the university.

Step 1: Define the problem and the app

Pick a real-world issue (e.g., food insecurity on campus, finding accessible housing, coordinating care for an aging parent, reporting unsafe working conditions) and sketch an app that addresses it. One paragraph is enough at this stage: who is the app for, and what problem does it solve? Pick an issue where the people most affected have something real at stake. Those are the cases in which privacy, consent, and bias matter most.

Step 2: Prepare and conduct the interview

  • Who to interview. Interview at least one person who could realistically use the app. They should be an adult (18+). The best interviewee is someone with direct experience of the problem, not just a friend who is willing to talk to you.
  • Write your questions in advance. Prepare 8–12 open-ended questions covering:
    • their experience with the problem and how they deal with it now
    • what they would want the app to do (use cases and desired functionality)
    • what would make them not use it, or worry about using it
    • what data they would and would not be comfortable sharing, and with whom
    • who else (family members, employers, landlords, etc.) could be affected by the app
  • Ask follow-up questions. The most useful material usually comes from “Can you tell me more about that?” Don’t just read the list.
  • Get consent and protect your interviewee. Before you start, tell them what the interview is for, that it is for a class assignment, and that they can skip any question or stop at any time. Ask before recording or taking notes. Use a pseudonym in your paper and leave out identifying details. Do not ask them to disclose information they would be harmed by if it became public. Include a copy of your questions in an appendix at the end of your paper.
  • Interviews should be about 20–30 minutes. Take notes during the interview, and write up any other ideas you had during the interview right after while they are fresh.

Step 3: Prompt an LLM with the same questions

Using one of the LLM tools available through the university, ask the same questions you asked your interviewee. Prompt it to answer as a prospective user of the app (e.g., “Imagine you are a … who … Answer the following questions as that person.”). Save the full transcript and include the prompt and an excerpt in an appendix at the end of your paper.

Then compare the two sets of answers. Useful questions to ask yourself:

  • What did the human raise that the LLM didn’t (and vice versa)?
  • Which answers were more specific? More surprising? More generic?
  • Did the LLM reflect any assumptions or stereotypes about the kind of person it was asked to be?
  • What does this suggest about using LLMs as a substitute for talking to real users, a practice that some companies are adopting?

Step 4: Write the report

Section What it does Approx. words
Introduction The real-world problem, who it affects, and the app concept 150–200
Interview findings Key use cases, desired functionality, and concerns, with short quotes or paraphrases from your interviewee(s) 350–450
Human vs. LLM comparison What differed, what was missing, and what that means for design practice 250–350
Functional requirements 5–8 concrete requirements, each traceable to something you learned in the interview(s) 200–300
Recommendations to developers How to implement those requirements while respecting privacy, welfare, freedom from bias, ownership and property, and informed consent. Address each of the five 450–600
Conclusion The most important tradeoff the developers will face, and your advice on it 100–150
Appendices (not counted) Interview questions, LLM prompt and transcript excerpt —

A functional requirement describes what the app must do, stated so that a developer could test whether it was done. “The app should be private” is not a requirement. “Users can delete their account and all associated location history from within the app, and deletion completes within 30 days” is.

Grading Rubric (Option 2)

We will be grading your paper on a 20-point scale:

  • Interview design and findings (5 points)
    • questions are open-ended and cover use cases, functionality, and concerns
    • the interviewee is a relevant prospective user, and consent and privacy were handled appropriately
    • findings are reported specifically, with evidence from the interview
  • Human vs. LLM comparison (3 points)
    • identifies concrete differences, not just “the LLM was more generic”
    • draws a reasoned conclusion about what LLMs can and cannot substitute for
  • Requirements (3 points)
    • requirements are concrete and testable
    • each is grounded in the interview findings
  • Ethical recommendations (6 points)
    • addresses all five areas: privacy, welfare, freedom from bias, ownership and property, informed consent
    • recommendations are specific and actionable for a developer
    • explicitly applies course concepts
    • considers people affected by the app who are not its users
    • acknowledges tradeoffs between requirements and ethical goals
  • Writing and mechanics (3 points)
    • clear organization and structure, appropriate for an audience of developers
    • meets length, appendix, and citation requirements
    • proofread

Option 3: Bias Auditing (up to two people)

For this assignment, you will perform a bias audit of a computerized system to assess whether its outputs create fair or discriminatory outcomes. The goal is to examine whether the system behaves consistently across populations, whether training data is skewed, or whether downstream decisions amplify unfairness.

Examples based on Non-Human Identity Bias Audit:

  • Testing a hiring model to compare shortlist rates across gender, ethnicity, and age groups before the system is approved for production use
  • Reviewing a credit decision model to identify whether similar applicants receive systematically different outcomes after controlling for relevant risk factors
  • Auditing a customer support chatbot to see whether it responds differently to dialects, names, or phrasing patterns associated with particular communities
  • Assessing healthcare diagnostics and treatment prioritization performance gaps across patient groups where unequal error rates could create safety and liability concerns
  • Examining targeted ad-placement systems to verify whether job, housing, or financial service ads are unfairly restricted or skewed away from specific gender or ethnic audiences

Most of you won’t have access to a bank’s credit model or a company’s hiring system, so pick a system you can actually test from the outside. Examples:

  • An LLM chatbot (e.g., one of the LLM tools available to you) asked to evaluate resumes, write recommendation letters, give medical or legal advice, or grade essays, where only a name, dialect, or demographic detail varies
  • An image generator prompted with occupations (“a doctor,” “a nurse,” “a CEO,” “a criminal”)
  • Machine translation between a gendered and a non-gendered language
  • Search engine autocomplete or image search results
  • Speech-to-text transcription across accents or dialects
  • A publicly available dataset or pre-trained model (if you have programming experience, but programming is not required)

Step 1: Define the audit

Before you start testing, write down:

  • The system and what it is used (or could be used) for. Bias matters most when outputs feed into decisions about people.
  • The groups you will compare (e.g., names associated with different genders or ethnicities, different dialects, different age signals) and how you will signal group membership in your inputs. Justify your choices and cite sources where possible (e.g., research on name-based signals).
  • Your hypothesis. What disparity do you expect, and why?
  • Your measure of bias What counts as “different treatment”? Examples: the rate at which candidates are recommended, the score or tone of a response, the proportion of generated images showing women, error rates. We discussed in class that different definitions of fairness can conflict. Explain why the one you chose fits this system.

Step 2: Design and run your tests

  • Use paired (counterfactual) inputs: identical inputs that differ only in the attribute you are testing. For example, the same resume with only the name changed.
  • Run at least 30 test cases in total (pairs: at least 60), spread across your groups. Since many systems are non-deterministic, run each input more than once, or in a fresh session, and record whether the outputs vary.
  • Record every input and output in a spreadsheet: date, system and version, exact input, output, and your coding of the output. Include a link to it (shared with me) or a summary table in an appendix.
  • Decide how you will code outputs before looking at the results, so you are not tempted to code them in a way that confirms your hypothesis.

Step 3: Write the audit report

Section What it does Approx. words
Introduction The system, why its fairness matters, who could be harmed, and your hypothesis 150–250
Methodology Groups, bias measure, test design, number of test cases, how outputs were coded 300–400
Results What you found, with at least one table or chart summarizing outcomes by group, and representative examples 300–400
Analysis Interpret the results: possible sources of the disparity (training data, design choices, deployment context), how downstream decisions could amplify it 400–500
Limitations What your audit cannot show (sample size, the groups you did not test, intersectionality, your own coding choices) 150–200
Recommendations Concrete actions for the people responsible for the system, and who should have the authority to require them 200–250
Appendices (not counted) Test inputs, data link or summary table, coding scheme —

Report what you found, even if it isn’t what you expected. “We found no significant difference on this test, and here’s what that does and does not tell us” is a legitimate result. Don’t overstate your findings: 30 test cases from a single system can show a pattern worth investigating, but cannot prove a system is biased in general.

Grading Rubric (Option 3)

We will be grading your paper on a 20-point scale:

  • Audit design (5 points)
    • clearly defined system, groups, hypothesis, and bias measure, with justification
    • paired inputs that isolate the attribute being tested
    • meets the minimum number of test cases
    • coding scheme defined in advance
  • Results (4 points)
    • results reported accurately and completely, with a summary table or chart
    • representative examples support the summary
  • Analysis (5 points)
    • offers plausible explanations for the results, tied to course concepts and readings
    • considers how outputs could affect real decisions and real people
    • honest about limitations
    • makes sure claims are proportionate to evidence
  • Recommendations (3 points)
    • specific and actionable
    • identifies who has the responsibility and standing to act
  • Writing and mechanics (3 points)
    • clear organization and structure
    • meets length, appendix, and citation requirements
    • proofread

Requirements (All Options)

  • Length: 1,500–2,000 words, excluding references, appendices, and contribution statement.
  • Citations: Cite everything you did not come up with yourself, including paraphrases. Use one citation style consistently — APA, Chicago, or ACM are all fine. If you have no preference, use APA. Include a reference list at the end.
  • Specificity: Name the technology, the actors, and the harms. “Users may be negatively impacted” is weak. “An applicant whose resume lists a historically Black college receives a lower fit score than an otherwise identical applicant” is strong.

What This Assignment Is Not

  • It is not a product pitch (Option 2). You are not trying to convince anyone to fund the app. You are telling its developers how to build it responsibly.
  • It is not a “gotcha” collection (Option 3). One shocking screenshot is an anecdote, not an audit. The value comes from systematic, documented comparison.
  • It is not a lecture disguised as a story (Option 1).
  • It is not graded on whether you found something bad. A carefully designed audit with a null result, or an app whose interviewee had few concerns, can earn full marks if the work is rigorous and the reasoning is sound.

Drafts and Revision

This paper has a first draft (due Nov 4, end of the day) and a final draft (due Nov 18, end of the day). You get about a week of feedback turnaround between them.

The first draft is graded, and it should be a complete attempt. For Options 2 and 3, this means your interviews or tests must be done before the first draft. A first draft that says “results to come” cannot get useful feedback on the parts that matter most. If a section is still rough, mark it with a comment in the doc telling me what you are stuck on.

For the final draft, revise in the same google doc. I want to see what changed.

Recall the course revision policy from the syllabus:

  • Students who earn less than a B on any writing assignment are required to meet with a TA before submitting the final draft of the following assignment.
  • Students who earn a B-, B, or B+ are required to send a rough draft to a TA before submitting the final draft of the following assignment.
  • Students may resubmit major writing assignments with no penalty until the last day of class by meeting with a TA and revising their original submission.

The TAs and the Center for Writing exist for exactly this. Use them.

Getting Started

  1. Choose your option as soon as possible. Look over your journal for a technology or issue you keep coming back to.
  2. Start the evidence-gathering early. Interviews take time to schedule, and audits take longer to run than you think. Aim to finish them at least a week before the first draft is due.
  3. Write your plan before collecting data. Interview questions (Option 2) or groups, hypothesis, and coding scheme (Option 3) should exist in writing before you start. For Option 1, collect your research on the real technology before drafting the story.
  4. Ask early. If you are unsure whether your app idea, interviewee, or system to audit will work, ask me or a TA before you invest a lot of time in it.
  5. Check your citations and your word count, then proofread.

Academic Integrity & Use of AI

The writing, analysis, and recommendations must be yours (and your partner’s, in case you are working with someone). Generative AI tools may be used for brainstorming (bring your own ideas into that process) and for proofreading (grammar, clarity of your own prose), but not to generate the substance of your paper.

Specifically, for each option:

  • Option 1: Do not use AI to write any part of the story or the author’s note.
  • Option 2: Prompting an LLM with your interview questions is a required part of the assignment. Its responses are data you analyze and should be clearly labeled as such (quotes in the comparison section, transcript in the appendix). Do not use an LLM to write your findings, requirements, or recommendations, and never present LLM output as something your human interviewee said.
  • Option 3: If you are auditing an AI system, its outputs are your data. Do not use AI to write your analysis or recommendations. Do not fabricate or alter test results.

An LLM asked about the ethics of a technology will produce fluent, generic text and plausible-looking citations that may not exist. Fabricated sources and fabricated data are a scholastic dishonesty issue. Verify every source you cite by reading it.

Disclose any use of AI tools in a note at the end of your paper, as described in the syllabus. For example:

“For this assignment, I used [list of AI tools used in assignment] for [specific purpose, e.g., generating an outline, summarizing sources, grammar revision] but not for [list of student contribution, e.g., direct content creation.]”