How many AP CSP Create PT rows can you lose and still earn a 5

AP Computer Science Principles rewards students who can describe a program, not just write one. The Create Performance Task (commonly shortened to Create PT) is the most distinctive component of the course: a sustained, portfolio-style submission in which the candidate designs, codes, and reflects on a single program that solves a problem of personal interest. It accounts for roughly 30% of the composite AP score, with the multiple-choice exam contributing the remainder. Students aiming for a 5 quickly learn that the Create PT is not graded like an ordinary coding assignment; it is graded against a published row-by-row rubric, and understanding the rows is the single most efficient preparation move available.

This article breaks down the rubric the way a senior tutor breaks it down at the whiteboard: row by row, with worked examples, the kind of errors that quietly drop a candidate from a 5 to a 3, and a triage routine that takes roughly 90 seconds per row. By the end, the reader should be able to read any of the 6 Create PT rubric rows, predict what the reader is looking for, and self-audit a draft against each one.

What the AP Computer Science Principles Create PT actually is

The Create Performance Task is an in-class, sustained project. Candidates are given roughly 9 class hours (broken into 1–2 hour blocks at the teacher's discretion) to develop, write, and document an original program of reasonable complexity. The program must contain a list as part of its function, must use a procedure that the candidate has written themselves with a parameter, must include sequencing, selection, and iteration, and must produce some kind of output or behaviour that responds to user input or to data drawn from an external source. At the end of the development window, the candidate submits two artefacts: a video walkthrough of no more than 1 minute, and a written response that answers four short prompts in plain text.

The video is not scored on production value. It is scored on whether the candidate narrates their program while it runs, names the inputs, names the outputs, and points at the list and at the student-developed procedure. The written response is where most of the points are. It is roughly 350–400 words, broken into four short responses labelled 2a, 2b, 2c, and 2d. Each response is scored independently by a College Board reader against a single rubric row. The two artefacts are uploaded to the College Board digital portfolio by an AP coordinator, then sent for scoring in June. There is no in-school grading: every Create PT is read at the national reading.

For most candidates the surprise is that the written response, not the code, decides the score. A sophisticated program with a weak written response will earn a 2 or a 3. A modest program with a sharp, well-targeted written response can earn a 4 or a 5. The rows are the lever.

The six rubric rows at a glance

The College Board publishes the Create PT scoring guidelines in the form of six independent rows, scored 0–1 each, that combine into a 6-point task score. The task score then feeds into the composite AP score through a conversion table. The rows are designed to test the four big ideas of the course: creativity, abstraction, data and information, and algorithms. A useful habit is to memorise the row names before you memorise the code, because the row names are the only thing a student can self-check against.

The 0–1 structure of each row is what makes a 3 versus a 5 feel so cruel. A candidate who earns all 1s gets the full 6 points; a candidate who loses two rows and is otherwise perfect gets a 4. There is no partial credit within a row. Every row is binary, and binary rows punish unclear writing more than they punish weak code.

Row 1: the purpose row, and why vague topics lose the point

Row 1 asks the candidate to identify the purpose of the program and to identify the list that supports that purpose. The reader expects two distinct things in roughly one short paragraph: a sentence stating what the program does, and a sentence naming the list and explaining what role the list plays in that function. Candidates who describe only the topic — for example, 'my program is about music' — lose the point, because the reader cannot tell what the program actually computes or displays. Candidates who describe the program in functional terms — 'my program allows the user to enter a series of quiz scores into a list, then displays the running average and the lowest score' — earn the row.

The 90-second triage for Row 1 is to read the candidate's purpose statement out loud. If you cannot tell a non-technical adult what the program would look like on screen, the statement is not specific enough. If you can describe the input the user types, the output the program produces, and the list that connects them, the row is in the bag. In my experience the most common reason students lose Row 1 is that they write about their inspiration ('I like basketball, so I built a basketball program') instead of writing about the program's behaviour. Replace the inspiration with a behaviour and the row is usually won.

Row 2: showing the list and how the program manages it

Row 2 requires the candidate to capture and paste the full list from the running program, then write a paragraph explaining what is stored in the list and what the program does with the data as it runs. The reader wants to see the actual data values, not a code snippet declaring the list. A block of three lines that simply reads myList = [] loses the row. A screenshot or copied output that shows five or six values sitting inside the list after the user has interacted with the program earns the row.

Common pitfalls and how to avoid them:

• The list is empty in the screenshot. Run the program once, generate real data, then capture the list while it has values in it.
• The list is declared but the program never adds anything to it. The list must be part of the program's function, not a leftover variable from the prototype.
• The candidate explains the wrong list. If the code contains three different lists, point at the one that does the work described in Row 1.
• The list is hidden inside a built-in data structure. A pandas DataFrame or a dictionary does not count as a list for the purposes of this row. The College Board row requires a one-dimensional structure accessed by index.

The triage for Row 2 is to read the candidate's pasted list values and ask: 'If I deleted this list, would the program still work?' If the answer is yes, the candidate has pointed at the wrong list.

Row 3: calling the student-developed procedure with a parameter

Row 3 is the row that most candidates over-prepare and most candidates still lose. The College Board definition of 'student-developed procedure' is narrow: it is a procedure that the candidate wrote themselves (not a built-in), that has at least one parameter that controls its behaviour, and that is called at least once in the program. The reader must see the procedure definition, the call site with arguments, and the output (or visible behaviour change) that results from the call.

The error pattern is consistent. Candidates show the procedure definition, then show the procedure call on a separate line of code, then never show what happens at the call site. The reader has to infer that the procedure worked. Inference is not enough; the rubric row says the response must include 'the call to the procedure' and 'the result of the call'. Both are required for the point.

The triage for Row 3 is mechanical. In the candidate's written response, find the procedure name from Row 2's discussion, then look for two specific things: a code line that calls the procedure with arguments, and a line or output that shows what changed because of the call. If either is missing, Row 3 is at risk.

Row 4: describing one algorithm in the procedure, not the whole procedure

Row 4 is conceptually the hardest row for students who are also taking AP Computer Science A, because A-level rubric language encourages them to describe the procedure as a complete unit. The CSP rubric is more granular: the candidate must identify one named algorithm inside the procedure, describe how that algorithm works in plain English, and explain how that algorithm contributes to the overall function of the program. A 'one algorithm' description is a segment of code, not the procedure as a whole.

A common losing answer reads: 'My procedure takes the list, then loops through it, and returns the average.' That is a description of the procedure. A winning answer reads: 'Inside my procedure, the algorithm that finds the lowest score is a linear search. It starts by setting the variable lowest to the value at index 0, then iterates through the rest of the list, comparing each value to lowest and reassigning when a smaller value is found. This algorithm contributes to the program by ensuring the user always sees their worst quiz score alongside the average.' The difference is specificity: an algorithm is a small, named, mechanical process, and the row is awarded only when the candidate isolates one and explains it.

The triage for Row 4 is to circle every verb in the candidate's algorithm paragraph. If the verbs are all about the program ('the program takes input, the program shows output'), the row is missing. If the verbs are about a small piece of work ('the algorithm sets a variable, the algorithm compares two values, the algorithm reassigns when a condition is met'), the row is in.

Row 5: the video, and what 'input and output visible' actually means

Row 5 is the only row the candidates often misread as 'easy'. It is not. The rubric says the video must show the program running, and must show input being given to the program and output being produced by the program. The reader is not watching for a code walkthrough; the reader is watching for evidence that the program responds to interaction. A video that opens the program, scrolls through the source code, and closes the program loses the row. A video that opens the program, lets the user type a value, presses enter, and shows the screen changing in response earns the row.

Common pitfalls and how to avoid them:

• The video is too long. The College Board hard cap is 1 minute. Going over forfeits the row.
• The input is invisible. If the camera is on the code window, the reader cannot tell whether the user typed something or whether the program generated the output itself.
• The list is never shown in the video. The video must include a moment when the list — with values inside it — is visible on screen. A console log, a printout, or a graphical display all count.
• The student-developed procedure is never called in the video. The reader must see the call, the result, and the link between them.

A useful prep drill is to record the video first, then watch it back at 0.5x speed. If the reader cannot tell which lines of output came from the call to the procedure, the video needs another take.

Row 6: the code itself, and the structural requirements

Row 6 is scored on the submitted program code, not on the written response. The code must demonstrate that the candidate can use the tools the course has taught: at least one list, at least one student-developed procedure with a parameter, sequencing, selection, and iteration. The reader scans the code for these structures, and the row is awarded if all five are present. The structures can be in any order; the code does not have to be elegant.

Iteration is the most common silent failure. A candidate who relies on list.append() inside a for loop satisfies the iteration row, but a candidate who relies on a built-in function that iterates internally (such as sum(myList)) does not. The rubric is looking for a visible loop or recursion in the candidate's own code. Selection is the second most common failure: an if/elif/else block must be present in the program, even if the program would still work without it. The student-developed procedure must declare at least one parameter, and that parameter must influence the procedure's behaviour. A procedure that takes an argument but ignores it loses the row.

The 90-second triage for Row 6 is a checklist: list, parameterised procedure, sequence, selection, iteration. If the candidate's program is missing any one of these, the row is gone.

Tying the rows together: a 3 versus a 5 self-audit

Imagine a candidate named Jordan. Jordan's program is a quiz-scorer: the user enters quiz scores into a list, then the program displays the running average and the lowest score. Jordan's video is 58 seconds long, shows the program accepting a score, shows the screen updating, and shows the list with values inside it. Jordan's written response is well written but organised in the wrong order. The four prompts are answered in sequence, but the procedure call is buried inside the procedure description.

If a reader scores Jordan's submission mechanically, they would see: Row 1 earned (purpose is specific); Row 2 earned (list shown with values); Row 3 lost (procedure call not isolated from the procedure definition); Row 4 lost (algorithm description covers the whole procedure, not one named algorithm); Row 5 earned (video shows input, output, and list); Row 6 earned (all five structures present). That is a 4 out of 6. A 4 on the Create PT does not necessarily mean a 5 on the composite AP score; it depends on the multiple-choice exam.

Now imagine a candidate named Mira who writes a more modest program — a recipe scale, where the user enters a serving size and the program scales ingredient amounts in a list — but who treats the rubric as a writing task. Mira's video is 47 seconds, her written response is 380 words, and every prompt is answered with the row's verb pattern in mind. Mira earns all six rows. The 6 out of 6 combined with a strong multiple-choice exam produces a 5. The point of the comparison is not that simpler programs are better; the point is that rows, not program complexity, decide the score.

Preparation strategy: row-by-row drafting beats whole-program drafting

Most candidates prepare the Create PT by writing the program first, then writing the response at the end. That sequence is the wrong way around for a row-scored submission. A more efficient sequence is to draft the written response rows first, in short paragraphs, while the program is being designed. If the candidate cannot write a clear purpose paragraph for the program they are about to build, the program is not yet designed. If the candidate cannot point at a list and explain its role, the list is not yet chosen. If the candidate cannot name one algorithm inside the procedure, the procedure is not yet refined.

Concretely, the senior-tutor preparation sequence looks like this:

1. Pick a problem the candidate can describe in one sentence to a non-technical adult.
2. Identify the list and the role of the list in the problem, then write the Row 1 paragraph.
3. Sketch the procedure signature, name one algorithm inside it, and write the Row 4 paragraph before writing the procedure code.
4. Build the program, then immediately write Rows 2, 3, and 6 by copy-pasting from the running code, not from memory.
5. Record the video as a separate pass, after the program has been shown to work end to end.

The single best preparation move a candidate can make is to write the written response in advance, then run the program and verify that every claim in the written response is visible in the running program. The Create PT is a writing task disguised as a coding task, and the rows are the writing prompt.

Common pitfalls and how to avoid them

The Create PT is graded in a national reading by human scorers, and the scoring patterns are remarkably stable. A short list of pitfalls, ranked by frequency:

• Treating the topic as the purpose. 'My program is about chess' is not a purpose; 'my program lets a user enter a chess opening move and tells them which of three named openings it matches' is.
• Showing code without showing data. The list row requires the values inside the list, not just the line that declares it.
• Calling the procedure without showing the result. The call and the result must be on adjacent lines in the written response.
• Describing the procedure as a single algorithm. The row is awarded for one named algorithm inside the procedure, not for the procedure as a whole.
• Recording a code-tour video. The reader is looking for input and output interaction, not for an explanation of the source code.
• Relying on a built-in for iteration. A built-in sum or map call does not satisfy the iteration row. A visible for or while loop does.
• Missing the parameter on the student-developed procedure. A procedure that takes no arguments is not a student-developed procedure for the purposes of this row.

For most candidates, the difference between a 3 and a 5 is the resolution of two or three of these pitfalls. A 90-second triage against this list is usually enough to find the points that are being left on the table.

Next steps

The Create PT is a learnable artifact. Once a candidate can read the six rows as a writing prompt, the score tends to take care of itself, because the program and the response are designed in the same order. Practice writing the Row 1 purpose paragraph for three different program ideas; if the paragraphs do not become sharper, the ideas are not yet ready to be coded. Practice writing the Row 4 algorithm paragraph for the procedures you have already written in class; the language is what the rubric is rewarding, and the language is built by repetition.

AP Courses' one-to-one AP Computer Science Principles programme works through a candidate's Create PT draft against each of the six rows in the order above, with worked examples from past readings, and turns a row-by-row audit into a concrete preparation plan for the May submission window.

Frequently asked questions