Create Performance Task & Personalized Project Reference

The Create performance task is the through-course component of AP Computer Science Principles. Alongside the end-of-course digital exam, it asks you to design and implement a program of your own choosing and then demonstrate that you understand every part of it.

The program itself is genuinely open. It may solve a problem, explore a personal interest, enable innovation, or simply express creativity. A budgeting tool, a quiz trainer, a habit tracker, a music-recommendation experiment, and a small game are all legitimate directions. What is not open is the evidence your program must contain and the way that evidence must be captured.

You submit three components:

• Program code — the complete code for your program, including any acknowledgements of outside contributions.
• Video — a short demonstration of your program running, showing input and the resulting output, created according to the current task requirements.
• Personalized Project Reference (PPR) — a small set of code screenshots that you take into the exam room.

The Personalized Project Reference deserves special attention because it is the only piece of your project that travels with you to exam day. It contains four categories of code evidence drawn from your own program, and on the exam you will use it to answer two written-response questions containing four distinct prompts:

• Written Response 1: Program Design, Function, and Purpose
• Written Response 2(a): Algorithm Development
• Written Response 2(b): Errors and Testing
• Written Response 2(c): Data and Procedural Abstraction

Your PPR is only available to you in the exam if it has been submitted as final by the official deadline shown in the AP Digital Portfolio or current AP schedule. If it is not final, you sit the written responses with nothing in front of you — an entirely avoidable disaster.

You are given at least nine hours of in-class time to complete the task. The program code may be developed independently or collaboratively, but the video and the Personalized Project Reference must be created independently. That single rule shapes how you should plan: whatever help you have while building, you alone must be able to select the evidence and explain it.

This is why backward planning matters so much. Students who build first and hunt for evidence afterwards routinely discover that their loop is outside their procedure, that their parameter changes nothing, or that their "list" is decoration. Students who decide where the evidence will live before they write code almost never have that problem.

Every strong Create task follows roughly the same nineteen-step arc. Read it once as a workflow, then read it again as a checklist.

1. Select a manageable program idea. Something you can finish, test, and explain — not something you hope to finish.
2. Define the purpose and intended users. One precise sentence. "This program helps students find unfinished tasks for a chosen subject."
3. Plan input and output. Input may come from a user, a device, an online data stream, or a file. Output may be visual, textual, audible, or tactile.
4. Identify the list or other collection that will hold your data.
5. Explain how that collection manages complexity. If you cannot say why separate variables would be worse, redesign now, not later.
6. Design a student-developed procedure. It needs a name and, where applicable, a return type.
7. Add a meaningful parameter. At least one parameter must genuinely affect what the procedure does.
8. Place sequencing, selection, and iteration inside that procedure. All three must live in the algorithm you select as evidence.
9. Call the procedure elsewhere in the program. A definition with no call is not usable evidence.
10. Build the program.
11. Test normal, boundary, and invalid cases.
12. Debug the errors you find.
13. Prepare the program video — one minute or less, created independently, following the current task requirements.
14. Capture the full program code for submission, including acknowledgements.
15. Select procedure-definition and procedure-call evidence.
16. Select list-storage and list-use evidence — from the same list.
17. Create readable PPR screenshots with no comments.
18. Submit every component as final by the official deadline shown in the AP Digital Portfolio or current AP schedule.
19. Practise the four written-response categories using your own PPR.

Notice where the evidence decisions sit: steps 4 through 9, before a single line of the finished program is written. That ordering is the whole strategy. Ambitious projects fail the Create task not because they are bad programs, but because their required features end up in the wrong places — the loop in the main body, the list touched once and forgotten, the parameter passed but never used.

A modest program with a clean, well-placed procedure and one genuinely useful list will earn every point available and will be far easier to explain under exam pressure. Scope down. Explain up.

Visual Create Task Workflow

Click to enlarge

Create task workflow: plan the required evidence before building, then test, capture, submit, and practise explaining.

Read the workflow left to right. The first band — idea, purpose, input/output, list, procedure, parameter, algorithm, call — is entirely planning. Nothing is built yet, but every requirement already has an address inside the future program. This is what "designing for evidence" means in practice.

The second band — build, test, debug — is where most students believe the task lives. It is important, but it is only the middle of the story. Testing here is not decoration: the normal, boundary, and invalid cases you construct now become raw material for the Errors and Testing prompt later.

The third band — video, code capture, evidence selection, screenshots, final submission — converts a working program into an assessable artefact. If a step in band one was skipped, band three is where the damage becomes visible, and by then it is usually too late to fix.

The final band — practise the four written-response categories — is the one students most often omit. Your PPR is not a comfort object; it is a working document you must be able to read out loud, line by line, and justify.

• Create Performance Task: the through-course project in which you design, implement, test, and explain a program of your own choosing.
• Personalized Project Reference (PPR): the set of code screenshots drawn from your program that you take into the exam and use to answer the written responses.
• Program Purpose: the problem the program solves, the interest it explores, or the creative goal it achieves — stated in terms of what it does for someone.
• Program Function: what the program actually does when it runs — the observable behaviour, including how input becomes output.
• Input: data the program receives from a user, a device, an online data stream, or a file.
• Output: what the program produces — visual, textual, audible, or tactile.
• List: an ordered collection of elements that can be accessed and traversed, used here to manage many related values under one name.
• Collection: any structure that groups multiple values together; a list is the most common form in AP CSP.
• Data Abstraction: managing complexity by representing many values with a single named structure instead of many separate variables.
• Student-Developed Procedure: a procedure you wrote yourself. Built-in procedures, event handlers, and main methods do not count.
• Parameter: an input to a procedure that allows the same procedure to behave differently depending on the value passed in.
• Procedural Abstraction: managing complexity by naming a block of logic so it can be called from elsewhere without re-stating its detail.
• Algorithm: a finite sequence of steps that accomplishes a task; the one you select must contain sequencing, selection, and iteration.
• Sequencing: statements executed in a defined order, where the order genuinely matters.
• Selection: a decision point — the program takes one path or another based on a Boolean condition.
• Iteration: a repeated section of code, such as a loop that traverses a list.
• Test Case: a specific input, paired with the behaviour you expect, used to check one aspect of the program.
• Expected Output: what the program should produce for a given input, stated before you run it.
• Boundary Case: an input at the edge of the valid range — the first element, the last element, an empty list, a single-item list.
• Debugging: locating the cause of incorrect behaviour and correcting it, then re-testing.

On exam day, the written responses are answered with your Personalized Project Reference in front of you. There are two questions containing four distinct prompts. Prepare for each one deliberately.

A. Written Response 1 — Program Design, Function, and Purpose

This is the "explain your program to a stranger" prompt. Be ready to state:

• the overall purpose of the program — what it is for, not just what it contains;
• the intended users and why the program is useful to them;
• the function of a specified code segment — what those particular lines accomplish;
• the program input and where it comes from;
• the program output and its form;
• a design or development decision you made, and the reasoning behind it;
• how the interface supports the purpose — how the user reaches the functionality.

Weak answers describe features. Strong answers connect every feature back to the purpose: "The user selects a subject because the whole point of the program is to reduce a long task list down to what is relevant right now."

B. Written Response 2(a) — Algorithm Development

Here you reason about the algorithm inside your selected procedure. Be ready to:

• explain how the algorithm works, step by step, in order;
• trace conditions and evaluate Boolean expressions for given values;
• explain the role of selection — what decision is made, and what happens on each branch;
• explain the role of iteration — what is repeated, over what, and when it stops;
• predict the result of running the algorithm on specific data, including side effects;
• modify or combine algorithms — describe what changes if a condition or bound is altered;
• express an algorithm without relying on a specific language, using plain steps or AP-style pseudocode.

C. Written Response 2(b) — Errors and Testing

This prompt asks you to think like a tester, not a coder. Be ready to:

• identify a possible error in a given or described code segment;
• state a correction that fixes it without breaking other behaviour;
• construct valid test cases that actually test something;
• state the input for each test case precisely;
• state the expected output or behaviour — before running anything;
• distinguish normal, boundary, and invalid cases and explain what each one checks.

A test case is not "I ran the program and it worked." A test case is a stated input, a stated expected result, and a stated reason the case matters.

D. Written Response 2(c) — Data and Procedural Abstraction

This is the prompt built directly on your four PPR segments. Be ready to:

• identify the list you selected and describe the data it holds;
• explain how that list manages complexity — specifically, why writing the program with individual variables instead would make it harder to develop or maintain;
• explain the traversal — how the list is accessed, element by element, and to what end;
• identify your student-developed procedure and what it does;
• explain how procedural abstraction manages complexity — how naming that logic keeps the rest of the program simple and reusable;
• explain the effect of the parameter — how a different argument produces different behaviour.

Consider a Study Planner application. Its purpose is to help a student see, at a glance, which tasks remain unfinished for one chosen subject. Each stored task records a name, a subject, a priority, and a completion status.

List-storage evidence. Tasks are added to a single list, studyTasks:

studyTasks ← []

PROCEDURE addTask(name, subject, priority)
{
    newTask ← createTask(name, subject, priority, false)
    APPEND(studyTasks, newTask)
}

This is the segment that shows data being stored in a list. Every task the user adds, whatever the subject, lands in the same collection under one name.

Procedure-definition evidence. The student-developed procedure below takes the chosen subject as a parameter and reports the unfinished tasks for it:

PROCEDURE showTasksBySubject(selectedSubject)
{
    matchFound ← false

    FOR EACH task IN studyTasks
    {
        IF task.subject = selectedSubject AND task.completed = false
        {
            DISPLAY(task.name)
            matchFound ← true
        }
    }

    IF matchFound = false
    {
        DISPLAY("No unfinished tasks found")
    }
}

Procedure-call evidence. The procedure is called from the part of the program that handles the user's choice:

selectedSubject ← INPUT("Enter a subject: ")
showTasksBySubject(selectedSubject)

List-use evidence. The FOR EACH task IN studyTasks traversal inside the procedure is the segment showing data from the same list being used to fulfil the program purpose. Notice that storage and use refer to the same list. This is not optional — a PPR that stores into one list and reads from a different one fails the requirement outright.

Now walk the evidence chain deliberately:

• Program purpose: to reduce a long, mixed task list down to the unfinished work for one subject, so a student can decide what to do next.
• Input: the subject typed by the user.
• Output: a textual display of matching task names, or a clear message when there are none.
• Data abstraction: studyTasks holds every task under a single name. Without it, each task would need its own set of variables, and the program would have to be rewritten every time the number of tasks changed. The list lets one traversal handle any number of tasks.
• Procedural abstraction: showTasksBySubject names a block of logic — traverse, filter, display, handle the empty result — so the rest of the program can request that behaviour in one line and never repeat the detail.
• Parameter effect: selectedSubject is compared against every task's subject. Passing "Physics" displays a different set of tasks than passing "History". Change the argument and you change the output — that is what "meaningfully affects functionality" means.
• Sequencing: matchFound is initialised to false before the loop and checked after it. Reverse those two and the procedure breaks. The order carries meaning.
• Selection: the IF inside the loop decides whether a task is displayed, using a compound Boolean condition. A second IF after the loop decides whether the "no results" message appears.
• Iteration: the FOR EACH repeats the check once for every task in studyTasks, regardless of how many there are.

Three test cases. These are the kind of cases the Errors and Testing prompt expects — each with a stated input, a stated expected output, and a stated reason.

• 1. Normal case. Input: the list contains three Physics tasks (two unfinished, one completed) and two History tasks; the user enters "Physics". Expected output: the names of the two unfinished Physics tasks only. Checks: the compound condition correctly filters both by subject and by completion status, and the traversal reaches every element.
• 2. No-match case. Input: the list contains only completed Physics tasks; the user enters "Physics". Expected output: "No unfinished tasks found". Checks: matchFound remains false, the post-loop selection fires, and the program does not simply display nothing.
• 3. Boundary case. Input: studyTasks is empty; the user enters any subject. Expected output: "No unfinished tasks found". Checks: the loop body never executes, the initialisation before the loop still protects the program, and no error is raised on an empty collection.

A fourth case worth constructing for practice is the invalid case: the user enters a subject that does not exist in the data, or enters an empty string. The program should behave predictably rather than crashing — which is exactly the kind of behaviour an exam prompt will ask you to defend or correct.

Design and scope

• Choosing an oversized project. An ambitious half-finished program is worth less than a small complete one whose evidence is airtight.
• Selecting a decorative list. A list that stores three fixed values and is never traversed does not manage complexity. It just exists.
• Storing values in a list but never meaningfully using them. Storage evidence without genuine use evidence fails the requirement.
• Selecting different lists for the storage and use segments. Both segments must involve the same list.

Procedure and algorithm

• Using a built-in procedure instead of a student-developed one. Built-in procedures, event handlers, and main methods do not count.
• Having no procedure call. A definition alone is incomplete evidence.
• Using a parameter that does not affect behaviour. If passing a different argument produces identical output, the parameter is not meaningful.
• Placing selection or iteration outside the selected procedure. All three constructs must appear in the algorithm inside the procedure you select.
• Assuming several lines automatically prove sequencing. Sequencing means the order matters. Be able to say what breaks if two statements are swapped.

PPR capture

• Capturing comments in PPR screenshots. Comments must not appear in the PPR. Remove or exclude them before capture.
• Including course notes, explanations, or annotations in the screenshots. Only the code evidence belongs there.
• Using tiny or blurry screenshots. Unreadable evidence is unusable evidence.
• Capturing code that is too wide. Long horizontal lines shrink the font and destroy readability.

Process and integrity

• Preparing the PPR collaboratively. The PPR must be created independently.
• Creating the video collaboratively. The video must also be created independently.
• Failing to submit every component as final. A PPR that is not final by the official deadline is not available to you in the exam.
• Misunderstanding code produced with outside or AI assistance. If you cannot explain it, it will sink you in the written responses.
• Memorising generic answers instead of understanding your actual code. Exam prompts point at your segments; rehearsed phrases collapse instantly.
• Never practising testing and expected-output prompts. This is a distinct skill and it is examined every year.

Sit down with your Personalized Project Reference and nothing else. No notes, no editor, no teammate. Work through the list in order.

1. Can I state my program's purpose in one precise sentence?
2. Can I identify the program input and output?
3. Can I point to the exact list used to manage complexity?
4. Do my two list code segments use the same list?
5. Does one segment show data being stored?
6. Does the other show the same data being used?
7. Can I explain why separate variables would be harder to develop or maintain?
8. Can I identify my student-developed procedure?
9. Does the selected definition contain a meaningful parameter?
10. Does the parameter change the procedure's functionality?
11. Does the procedure body contain sequencing, selection, and iteration?
12. Can I show a call to that exact procedure?
13. Can I explain the algorithm step by step?
14. Can I produce normal, boundary, and invalid test cases?
15. Are all PPR screenshots readable and free of comments?
16. Can I explain every selected line without relying on memorised generic language?

Any "no" or "not sure" is a task, not a worry. Fix it while the program is still editable; after final submission, the evidence is locked and you must live with it.

Screenshot craft. A few practical habits protect readability:

• Capture at the size you intend to read. Do not zoom far out and enlarge afterwards — that produces blur.
• Use at least a 10-point font; 12-point is preferable where practical.
• Avoid very wide lines. Break long statements before capturing.
• Long code segments may be captured in multiple readable sections rather than one shrunken image.
• Show only the necessary code evidence — no surrounding clutter, no comments, no annotations.

On outside help and AI-assisted code. Outside code, media, data, APIs, starter code, open-source code, and AI-assisted code must be properly acknowledged in the complete program-code submission. Those acknowledgements and comments belong in the full code file where appropriate — never inside the PPR screenshots. More importantly, you remain responsible for understanding every line you submit. AI-generated code frequently contains errors, bias, inefficiency, or complexity you did not need, and the exam will ask you to explain your code, not the tool's. During the official administration of the task, follow the current assistance and collaboration rules given to you by your teacher and College Board. The simple test: if you cannot explain a line without help, it should not be in your program.

Scenario. A student builds a fitness tracker. It stores daily step counts in a list, asks the user for a start day and an end day, calculates the average steps across that range, ignores any invalid or missing values, and displays the result.

dailySteps ← [8200, 10400, -1, 9600, 12100, 0, 7400]

PROCEDURE calculateAverage(startDay, endDay)
{
    total ← 0
    validCount ← 0
    day ← startDay

    REPEAT UNTIL (day > endDay)
    {
        steps ← dailySteps[day]

        IF (steps > 0)
        {
            total ← total + steps
            validCount ← validCount + 1
        }

        day ← day + 1
    }

    IF (validCount = 0)
    {
        RETURN(0)
    }

    RETURN(total / validCount)
}

start ← INPUT("Start day: ")
end ← INPUT("End day: ")
average ← calculateAverage(start, end)
DISPLAY("Average steps: ")
DISPLAY(average)

Answer all eighteen questions before reading the model answers.

1. What is the program purpose?
2. What are the inputs?
3. What is the output?
4. Identify the list-storage evidence.
5. Identify the list-use evidence.
6. Explain how the list manages complexity.
7. Identify the procedure.
8. Identify its parameters.
9. Explain how each parameter affects behaviour.
10. Identify sequencing.
11. Identify selection.
12. Identify iteration.
13. Give a normal test case.
14. Give a boundary test case.
15. Give an invalid-data test case.
16. State the expected output for each.
17. Would the selected procedure be suitable PPR evidence? Explain.
18. What screenshot-readability checks should be performed?

This is the final topic in the AP CSP roadmap. Everything from binary and abstraction through algorithms, data, the internet, and impact now converges on one question: can you explain, precisely and confidently, the program you built?

Your remaining work is deliberate rather than open-ended:

• Verify your final evidence. Four segments, the same list in both list segments, a student-developed procedure with a meaningful parameter, and a call to that exact procedure.
• Check screenshot readability. Sharp, at least 10-point font, no comments, no annotations, nothing unnecessary in frame.
• Rehearse your explanations aloud. Purpose, input, output, function of each segment, and one design decision you can defend.
• Practise algorithm questions. Trace conditions, evaluate Boolean expressions, predict results, and describe modifications without leaning on a specific language.
• Practise errors and testing. Construct normal, boundary, and invalid cases with stated inputs and stated expected outputs.
• Practise abstraction questions. Explain how your list manages complexity and how your procedure keeps the rest of the program simple.
• Take full, timed mock exams. Endurance and pacing are skills, and they are trained the same way everything else is.
• Use your analytics to revisit weak areas. Let the data choose your revision, not your mood.

Confirm that every component — program code, video, and Personalized Project Reference — has been submitted as final by the official deadline shown in the AP Digital Portfolio or current AP schedule. A submission marked final cannot be revised, so make the final check a careful one.

You have written a program that does something real, tested it against cases you designed yourself, and reduced it to four pieces of evidence you can defend line by line. That is not exam preparation dressed up as a project. That is what computer scientists actually do. Walk into the exam room knowing your program better than anyone else in it — because you do.