CA CS Standards Reference

What this is. A locally built index of California's 9-12 Computer Science core standards (adopted 2018), for linking from standards-alignment work. What this is not. Original paraphrases, not the CDE's text; only codes are reproduced as-is.

#AP Algorithms & Programming

6-8

#6-8.AP.10

Flowcharts and pseudocode let you design and check an algorithm before writing any real code.

#6-8.AP.11

A variable's name should say what it holds, since that's what makes the operations performed on it make sense to someone reading the code.

  • Bootstrap:Algebra: Chapter 5 (Simple Data Types), Chapter 9 (Defining Values)
    Naming values and choosing names for them in 'Simple Data Types' and 'Defining Values'; the overview names datatypes as a core CS concept.
  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit 1 (Drawing with Shapes)
    Drawing with Shapes, an introductory graphics unit, is where a first course names variables for shape properties (position, size, color) -- inferred from the unit title alone, not a confirmed lesson breakdown.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 7.2 (Local Variables)
    This carrier's own inference, since neither CMU document maps CS1 to the 6-8 band: local variables (7.2) is where naming a variable well starts to matter for reading the code back, the standard's own concern.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-11, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • MicroPython on Pi Pico and Projects: Chapter 4 (Physical computing with Raspberry Pi Pico) (partial)
    Chapter 4 has students rename led_onboard to led_external purely because its meaning changed, and says explicitly to make names match their purpose -- though the lesson doesn't develop naming conventions any further than this one example.
  • TurtleLab Lessons: Unit step-6-boxes (Step 6: Variables, boxes that keep a number), Unit step-7-boxes-that-count (Step 7: Boxes that count), Unit step-8-teach-the-turtle-a-word (Step 8: Teach the turtle a word) (partial)
    Boxes are named box1 to box4, so a box's name does not say what it holds. The fit is in the operations: Steps 6 and 7 store, read and update boxes and follow what they hold. Naming for meaning shows up in Step 8, where learners name their own blocks and inputs.

#6-8.AP.12

Real programs combine multiple control structures and compound conditions, and get built up iteratively rather than all at once.

  • Bootstrap:Algebra: Chapter 23 (Compound Inequalities: Solutions & Non-Solutions), Chapter 24 (Sam the Butterfly — Applying Inequalities), Chapter 25 (Piecewise Functions and Conditionals) (partial)
    Compound inequalities and piecewise functions combine conditions; loops are not taught, so only the compound-conditions half is met.
  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit 2 (Basic Animations), Unit 3 (Giving Programs Options), Unit 4 (Animating Lots of Shapes)
    Basic Animations (a repeating step mechanism), Giving Programs Options (the unit's own title names branching), and Animating Lots of Shapes (looping over many objects) are each control-structure content, built up across three units rather than introduced all at once. Inferred from unit titles.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 3.2 (Conditionals (if Statements)), Unit 4.1 (More Conditionals (if-elif-else Statements)), Unit 5.1 (Complex Conditionals), Unit 7.3 (For Loops), Unit 8.3 (Nested For Loops)
    This carrier's own inference: conditionals (3.2), if-elif-else (4.1), compound and nested conditionals (5.1), for loops (7.3), and nested for loops (8.3) are exactly the combined-control-structures, built-up-iteratively territory this standard names.
  • Code.org's CS Discoveries (Unit 3a: Music Lab): Unit 3 (Unit 3a - Programming with Music Lab)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-12, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-12, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • MicroPython on Pi Pico and Projects: Chapter 2 (Programming with MicroPython), Chapter 4 (Physical computing with Raspberry Pi Pico) (partial)
    Chapter 2 combines loops and conditionals rather than teaching them in isolation. Chapter 4 builds its combined LED-and-button program iteratively across three small programs (Blink, Button, Switch) rather than all at once.
  • Pico Projects: Chapter p1.4 (Project 1.4: Blinking Your LEDs), Chapter p1.7 (Project 1.7: Reading Your Switches) (partial)
    Project 1.4 follows an incremental pattern: blink the onboard LED, then a wired LED, then sequence three LEDs in a row, then count in binary, each program built on the last rather than arriving at the full version all at once. Project 1.7 combines a loop and a compound conditional into one program: a while True loop that checks all three switches every pass, with a single if gating the print statements only when something actually changed.
  • TurtleLab Lessons: Unit step-4-choose-a-path (Step 4: Choose a path), Unit step-5-random-art (Step 5: Capstone, random art), Unit step-9-a-loop-inside-a-loop (Step 9: A loop inside a loop), Unit step-12-capstone-2 (Step 12: Capstone 2, boxes and blocks), Unit step-16-catch-the-square (Step 16: Catch the square), Unit step-17-steer-the-snake (Step 17: Steer the snake)
    A conditional goes inside a loop with random in it, built up in small steps: first a loop that draws one thing, then random, then the if and else. Step 9 puts a loop inside a loop. Step 16 uses compound conditions (and, or, not) in the click handler of a game, and builds it in small steps: first the block that draws the square, then the first question, then the second. Step 17's snake joins its conditions with and and or.

#6-8.AP.13

Breaking a problem into smaller subproblems makes it possible to design, build, and review a program piece by piece.

  • Bootstrap:Algebra: Chapter 4 (Game Design), Chapter 21 (Problem Decomposition)
    Same lessons as 2-AP-13: Game Design breaks a game into parts and 'Problem Decomposition' is the standard by name.
  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit 4.1 (Unit 4, Lesson 1 (within Animating Lots of Shapes))
    Per the teacher's own knowledge of this lesson (not documented in CMU's own published materials): Unit 4's first lesson has students break the many-shapes problem into smaller subproblems before assembling the full animation.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 3.3 (Helper Functions)
    This carrier's own inference: helper functions (3.3) is decomposition into subproblems, the same evidence as 9-12.AP.16 above.
  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-13, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3a: Music Lab): Unit 3 (Unit 3a - Programming with Music Lab)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-13, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-13, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • TurtleLab Lessons: Unit step-1-your-initials (Step 1: Your initials), Unit step-5-random-art (Step 5: Capstone, random art), Unit step-8-teach-the-turtle-a-word (Step 8: Teach the turtle a word), Unit step-12-capstone-2 (Step 12: Capstone 2, boxes and blocks) (partial)
    Step 1 breaks the initials into one letter at a time, each planned and tested before the next. Step 8 breaks a flower into one petal used eight times, and a name into one block for each letter. Step 5 builds the capstone in three pieces.

#6-8.AP.14

A procedure that takes parameters can be reused for many different inputs instead of being rewritten each time.

  • Bootstrap:Algebra: Chapter 8 (Function Composition), Chapter 13 (Functions Make Life Easier!), Chapter 16 (Functions: Contracts, Examples & Definitions)
    Functions with parameters reused on many inputs, from 'Function Composition' to the contract-and-definition cycle.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 2.1 (Functions), Unit 3.3 (Helper Functions), Unit 4.3 (Methods)
    This carrier's own inference: functions (2.1), helper functions (3.3), and methods (4.3) are all reusable procedures parameterized for different inputs.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-14, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Bootstrap:Data Science — Hour of Data: Unit coding-challenge (Coding Challenges (optional star track in Parts 7 and 8)) (partial)
    OPTIONAL TRACK, not every student reaches it. `is-deer(r)` takes a row parameter so the same function can be tested against every row of the table, following the pattern of the provided `is-bird` and `is-turtle`; students write one new procedure with a parameter, which is a narrow slice of the standard.
  • Pico Projects: Chapter p2.1 (Project 2.1: Moving a Servo)
    setangle(servo, angle) and sweep(servo) are both written once and reused for any angle or any wired servo, rather than one-off code repeated for each position -- a procedure with parameters standing in for what would otherwise be separately written, nearly identical blocks.
  • TurtleLab Lessons: Unit step-8-teach-the-turtle-a-word (Step 8: Teach the turtle a word), Unit step-12-capstone-2 (Step 12: Capstone 2, boxes and blocks)
    Step 8 is about a procedure with a parameter: write it once, give it a different number each time it is used, and change it in one place to change every use.

#6-8.AP.15

A solution actually meets user needs only if you go get feedback from teammates and users and use it to refine the design.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit creative-task (Creative Tasks (every unit, 1-4))
    CMU's Creative Task feature (shared across its courses, including CS1) asks for a design intent statement, but its rubric doesn't itself require a feedback step -- whether this standard is actually met depends on the teacher building one in, same caveat cmu_cs1.json carries for the 9-12 equivalent (AP.18).
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit creative-task (Creative Task (every unit, 1-10))
    This carrier's own inference, same caveat as 9-12.AP.18 above: the Creative Task's design step invites feedback, but the rubric doesn't require it. Whether this standard is actually met depends on the teacher building a feedback step in. In this teacher's own classroom it is.
  • Code.org's CS Discoveries (Units 1-2): Unit 1 (Unit 1 - Problem Solving and Computing), Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-15, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-15, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.

#6-8.AP.16

Reusing someone else's code, media, or library in your own program is normal practice, as long as you credit where it came from.

  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-16, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-16, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.

#6-8.AP.17

Testing a program well means trying a deliberate range of test cases, not just the one you expect to work.

#6-8.AP.18

Building something as a team means splitting up tasks and keeping to a shared timeline, not just dividing the code.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit collaborative (Collaborative tasks)
    A stretch, by the teacher's own admission: CS0's collaborative tasks split work between partners, which is this standard's own team/role framing, though it's a lighter, shorter-form version of it than a full-length course's collaborative work would be.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit collaborative (Collaborative task (every unit))
    This carrier's own inference: the collaborative task's real-time shared-editor pair programming is team roles and shared tools, the same evidence as 9-12.AP.21 above, at a lighter grain.
  • Code.org's CS Discoveries (Units 1-2): Unit 1 (Unit 1 - Problem Solving and Computing), Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-18, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-18, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Kagan Cooperative Learning — Teambuilding: Unit Team Projects (Team Projects) (related)
    Team Projects assigns roles and resource access before the team builds together, echoing this standard's own shape (splitting tasks, keeping a timeline, not working in silence). But the standard's own frame is explicitly about code ('not just dividing the code'), Team Projects' deliverables are generic classroom builds, and the assigned-roles step is a single line in the structure's mechanics, not taught content -- a distant echo, not genuine coverage.

#6-8.AP.19

Documentation is what makes a program usable, readable, testable, and debuggable by someone other than the person who wrote it.

  • Bootstrap:Algebra: Chapter 7 (Contracts for Strings and Images), Chapter 16 (Functions: Contracts, Examples & Definitions)
    Contracts, purpose statements, examples and # comments are documentation for another reader; 'Solving Word Problems with the Design Recipe' says programmers write good purpose statements so teammates can understand code, and has students repair weak ones.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit creative-task (Creative Task (every unit, 1-10))
    This carrier's own inference: the Creative Task's describe-and-reflect step is documentation that lets someone else follow what was built and why, the same evidence as 9-12.AP.22 above.
  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-19, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games)
    Mechanically derived from this carrier's own csta2017 entry (2-AP-19, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • TurtleLab Lessons: Unit step-4-choose-a-path (Step 4: Choose a path), Unit step-5-random-art (Step 5: Capstone, random art) (partial)
    A sticky note in the program says what it does in the maker's own words: one sentence on what the if and else decides (Step 4), and what the loop, the random and the if and else each do (Step 5). It is short, and it travels with the PDF.
9-12

#9-12.AP.12

Solving a computational problem often means combining an algorithm you already know with one you design yourself.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc, Subconcept Algorithms: 'Design algorithms to solve computational problems using a combination of original and existing algorithms.' Concept-level claim, not lesson-localized in that document.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 8 (Math Functions, Random Values, and Nested Loops), Unit 11 (2D Lists and Board Games)
    Math functions, random values, and nested loops (unit 8) and 2D lists and board-game logic (unit 11) both involve choosing and adapting existing algorithms rather than inventing from scratch.
  • Carnegie Mellon's AP CSP in Python: Unit 3 (Unit 3: Groups, Lists, and Loops), Unit test-prep (Optional: AP Test Prep)
    Unit 3's loop/traversal work chooses and adapts algorithms over groups and lists; Test Prep's Algorithms review lesson makes the same skill explicit.
  • CodeHS' Intro to JavaScript: Unit 2 (Karel Challenges), Unit 5 (Graphics Challenges), Unit 7 (Control Structures Challenges), Unit 9 (Functions Challenges), Unit 11 (Animations Challenges) (partial)
    Recurs across every 'challenges' unit (2, 5, 7, 9, 11) -- larger problems that call for choosing among algorithms already introduced. Syllabus-inferred: whether these problems actually require justifying that choice, rather than just applying it, isn't visible from the topic list.
  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 6 (Unit 6: Algorithms)
    This carrier's own inference, not mechanically derived: code.org's cited AAP-2.L/AAP-4.A on this unit (developing and comparing algorithms) is this standard's own 'combination of original and existing algorithms' language, but the unit's actual csta2017 codes (3B-AP-10/11) have no CA crosswalk match -- so this line is this carrier's own judgment, not the crosswalk's.
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 3 (Week 3: Algorithms (searching, sorting, asymptotic notation, recursion))
    Same algorithms-comparison claim as apcsp 3.9.
  • Working in Python (a jupyter notebook): Chapter 7 (Iteration and Search), Chapter 9 (Lists)
    Chapter 7 develops a linear-search algorithm from scratch; Chapter 9's 'Sorting lists' uses an existing (built-in) sort. Together they match 'combination of original and existing algorithms' well.

#9-12.AP.13

Once a problem needs more than a handful of related values, a collection replaces a pile of separately named variables.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc, Subconcept Variables: 'Create more generalized computational solutions using collections instead of repeatedly using simple variables.'
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 10.1 (Lists), Unit 10.2 (List Methods), Unit 11.1 (2D Lists)
    Lists (10.1), list methods (10.2), and 2D lists (11.1) replace repeated simple variables with a single generalized collection -- core, assessed content, not an optional add-on.
  • Carnegie Mellon's AP CSP in Python: Unit 3 (Unit 3: Groups, Lists, and Loops)
    Lists and Groups (Unit 3) are core, assessed content, not an optional add-on -- same argument cmu_cs1.json makes for its own units 10-11.
  • CodeHS' Intro to JavaScript: Unit optional-extension (Optional extension: Data Structures) (related)
    Arrays, lists, objects, sets, and grids live only in an optional extension sequenced after the final project -- the final exam's own listed coverage never touches them. Whether a student ever meets this standard depends on whether their teacher assigns material after the course is functionally over. Included because the extension exists, not because it's reliably taught.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): not covered
    Looked specifically for this because it's the most load-bearing 9-12 AP standard and the obvious one to hope a 'Variables' lesson reaches. It doesn't: Lesson 5 (Variables) and everything built on it only ever stores a single scalar value per variable -- no list, array, or dictionary appears anywhere in this unit's vocabulary or objectives.
  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 2 (Week 2: Arrays), Unit 5 (Week 5: Data Structures)
    Arrays (week 2) and the named Abstract Data Types (week 5) are collections replacing separately named variables.
  • Harvard's CS50-Python (Weeks 0-8): Unit 2 (Lecture 2: Loops, Lists, Dictionaries)
    Lists and Dictionaries, named week-2 headings, are the collection this standard describes.
  • Working in Python (a jupyter notebook): Chapter 9 (Lists)
    Direct match to Chapter 9 (Lists).

#9-12.AP.14

Different control structures for the same task read differently and run differently, and choosing between them is a real design decision.

  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 3.2 (Conditionals (if Statements)), Unit 4.1 (More Conditionals (if-elif-else Statements)), Unit 5.1 (Complex Conditionals), Unit 7.3 (For Loops), Unit 8.3 (Nested For Loops), Unit 9.4 (While Loops (Unit 9 is optional)), Unit creative-task (Creative Task (every unit, 1-10))
    Woven through every conditionals/loop lesson -- if statements (3.2), if-elif-else (4.1), complex conditionals (5.1), for loops (7.3), nested for loops (8.3), and while loops (9.4, in the optional Unit 9) -- and made explicit in the Creative Task's own design step, which has students list the concepts they plan to use and justify why -- the standard's own language, 'justify the selection.' Not in CMU's own official standards document; the teacher's own classroom analysis argues it should be.
  • Carnegie Mellon's AP CSP in Python: Unit 2 (Unit 2: Functions, Mouse Events, Conditionals), Unit 4 (Unit 4: Complex Conditionals, More Events, and Libraries), Unit test-prep (Optional: AP Test Prep)
    Conditionals (Unit 2), nested/compound conditionals (Unit 4), and Test Prep's explicit while-vs-for loop comparison ('Robot and While Loops') are all control-structure choices this standard names.
  • CodeHS' Intro to JavaScript: Unit 1 (Programming with Karel), Unit 6 (JavaScript Control Structures), Unit 7 (Control Structures Challenges) (partial)
    Control-structure choice appears in Karel (unit 1) and the JavaScript control-structures units (6-7), though this is inferred from the syllabus's topic list, not audited against the platform directly.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (related)
    This carrier's own 9-12 reading, not a code.org claim: Lesson 12 (The Draw Loop), Lesson 15 (Conditionals), and the keyboard/mouse-input lessons (16-17) put loops, conditionals, and if/else branching to real use side by side in the same programs. The unit never frames picking between them as its own design decision the way the standard does -- it's genuine use of both structures, not an explicit comparison.
  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 1 (Week 1: C), Unit 6 (Week 6: Python)
    The same Conditionals/Loops task reads and runs differently in C versus Python -- a real, named-topic-grounded control-structure choice.
  • Harvard's CS50-Python (Weeks 0-8): Unit 1 (Lecture 1: Conditionals)
    if/elif/else and match are two different, named control structures for the same branching task -- a real, explicit choice in the week's own material.
  • CS50 Problems: Unit 1 (Mario (less comfortable)), Unit 3 (Palindromes), Unit 4 (Square), Unit 7 (Readability)
    Mario, Palindromes, Square, and Readability all turn on a deliberate control-structure choice (loop vs. conditional vs. helper function) made concrete in each solution.
  • MicroPython on Pi Pico and Projects: Chapter 4 (Physical computing with Raspberry Pi Pico), Chapter 5 (Traffic light controller) (partial)
    Chapter 4 has students rewrite an explicit led.value(1)/led.value(0) pair as a single led.toggle() call and explicitly frames it as an optimization -- two different control structures for the same job. Chapter 5 contrasts polling with using an interrupt and picks the interrupt for a stated reason, though the lesson doesn't have students weigh the tradeoff themselves.
  • Pico Projects: Chapter p1.8 (Project 1.8: Choosing a Program with Imports) (partial)
    Project 1.8 explains if/elif/else as the way to check more than two possibilities and contrasts it directly against chaining separate if statements -- the same choosing-between-control-structures idea the book's own chapters 4 and 5 show, now a decision students make in their own code rather than one shown to them.
  • Working in Python (a jupyter notebook): Chapter 5 (Conditionals and Recursion), Chapter 6 (Return Values)
    Strong match: the CED's own worked example here is comparing iterative vs. recursive Fibonacci -- and Chapter 6 has a 'Fibonacci' section built on Chapter 5's recursion material. The book only ever demonstrates the recursive side (see the AP index's 3.8 Iteration note on the missing `while` loop), so the iterative half of this comparison is thinner than the recursive half.

#9-12.AP.15

A program built around events -- a button press, a timer -- responds to things happening rather than running start to finish in one line.

  • Bootstrap:Algebra: Chapter 20 (Functions for Character Animation), Chapter 26 (Player Animation) (partial)
    update-player takes the name of the key pressed and returns a new position, and Sam the Butterfly moves with the arrow keys. The event loop itself is provided by the starter file, so students write the handler logic, not the event wiring.
  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc, Subconcept Control: 'Iteratively design and develop computational artifacts... by using events to initiate instructions.'
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 2.2 (Mouse Events), Unit 3.1 (Mouse Motion Events), Unit 4.2 (Key Events), Unit 5.2 (More Key Events), Unit 6.3 (Step Events and Motion), Unit 12.1 (Final Project)
    Iterative development through events recurs across mouse events (2.2), mouse motion (3.1), key events (4.2 and 5.2), step events and motion (6.3), and the final project (12.1).
  • CodeHS' Intro to JavaScript: Unit 10 (Animation and Games), Unit 11 (Animations Challenges), Unit 12 (Project: Breakout) (partial)
    Iterative development via animation/game events across units 10-12.
  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (3A-AP-16, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (partial)
    This carrier's own 9-12 reading: Lesson 16 (Keyboard Input) and Lesson 17 (Mouse Input) have students write real event-handler code that reacts to input rather than running top to bottom -- the core idea of an event-driven program, just scoped to keyboard/mouse in a game rather than a general UI event model.
  • MicroPython on Pi Pico and Projects: Chapter 5 (Traffic light controller), Chapter 6 (Reaction game), Chapter 7 (Burglar alarm)
    Chapters 5 and 6 replace straight-line, run-to-completion code with a button press that changes what runs next via an interrupt handler. Chapter 7 does the same with a PIR sensor's rising-edge trigger -- the standard's own framing almost verbatim in all three.
  • Working in Python (a jupyter notebook): not covered
    Real gap: every program in this book runs top-to-bottom to completion. There is no event-driven or GUI programming anywhere in chapters 1-13 (turtle graphics is imperative, not event-based).

#9-12.AP.16

Breaking a big problem into smaller ones, each solved by its own procedure, module, or class, is what makes a complex program manageable.

  • Bootstrap:Algebra: Chapter 21 (Problem Decomposition) (partial)
    'Problem Decomposition' with a game as the project; modules and classes are not part of the course.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 3.3 (Helper Functions)
    Helper functions (3.3), introduced right where students first need to break a bigger drawing problem into named pieces, is decomposition into subproblems.
  • Carnegie Mellon's AP CSP in Python: Unit 2 (Unit 2: Functions, Mouse Events, Conditionals)
    Function Basics, introduced in Unit 2, is decomposition into subproblems -- same argument cmu_cs1.json makes for its own unit 3.
  • CodeHS' Intro to JavaScript: Unit 1 (Programming with Karel), Unit 2 (Karel Challenges) (partial)
    Karel's top-down design (units 1-2) is decomposition into subproblems.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (partial)
    This carrier's own 9-12 reading: Lesson 25 (Functions) has students write their own functions 'that perform a single high-level task' specifically so a program can be reasoned about at a higher level -- the procedure half of this standard, directly. The module/class half never comes up; this unit is single-file Game Lab programs throughout.
  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 2 (Week 2: Arrays), Unit 6 (Week 6: Python)
    Functions (named in both weeks) are decomposition into a subproblem solved on its own.
  • Harvard's CS50-Python (Weeks 0-8): Unit 0 (Lecture 0: Functions, Variables, Strings, def), Unit 8 (Lecture 8: Object-Oriented Programming)
    Functions (week 0) and Classes (week 8) are both named ways of decomposing a program into its own procedure or class.
  • CS50 Problems: Unit 4 (Square), Unit 7 (Readability)
    Square and Readability both require breaking the problem into named, reusable functions rather than one long script.
  • Working in Python (a jupyter notebook): Chapter 3 (Functions), Chapter 4 (Functions and Interfaces)
    Chapter 3/Chapter 4's function-decomposition material carries the procedure half directly. Chapters 14-19 (classes) carry the class-based half of this standard too, but that range is independent-study/post-AP pathway per the treatment matrix, not part of the Aug-Dec sequence this standard would be taught alongside.

#9-12.AP.17

A program built from separate, interacting pieces -- including code someone else wrote -- is organized by modular design.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc, Subconcept Modularity: 'Create computational artifacts using modular design.'
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 2.1 (Functions), Unit 4.3 (Methods), Unit 7.1 (New Shapes), Unit 10.3 (Return Values)
    Modular design via functions (2.1), methods (4.3), the New Shapes library (7.1), and functions that return values (10.3).
  • Carnegie Mellon's AP CSP in Python: Unit 4 (Unit 4: Complex Conditionals, More Events, and Libraries)
    Unit 4's Libraries lesson (calling pre-written library code, including media) is modular design via library calls.
  • CodeHS' Intro to JavaScript: Unit 1 (Programming with Karel), Unit 3 (JavaScript Basics), Unit 8 (Functions), Unit 9 (Functions Challenges) (partial)
    Modular design via functions recurs in units 1, 3, 8, and 9.
  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 1 (Week 1: C), Unit 6 (Week 6: Python)
    Libraries (week 1) and Modules/Packages (week 6) are modular design built from code someone else wrote.
  • Harvard's CS50-Python (Weeks 0-8): Unit 4 (Lecture 4: Libraries)
    Libraries, Packages, and Making Your Own Libraries are named week-4 headings -- modular design built from code someone else wrote.
  • Working in Python (a jupyter notebook): Chapter 2 (Variables and Statements), Chapter 4 (Functions and Interfaces), Chapter 8 (Strings and Regular Expressions)
    Same evidence as AP AAP-3.D (Libraries): Chapter 2 introduces `import`, Chapter 4 (jupyturtle) and Chapter 8 (`re`) are the worked examples.

#9-12.AP.18

Designing for a broad audience means building in a way to collect feedback from real users and revising the design in response.

  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit creative-task (Creative Task (every unit, 1-10))
    Design-for-audience is the Creative Task's rubric, but the rubric itself does not require a feedback step -- CMU claims the standard on the task's design intent; whether it's actually met depends on the teacher building a feedback step in. In this teacher's own classroom it is.
  • Carnegie Mellon's AP CSP in Python: Unit 5 (Unit 5: Create Performance Task (supplemental, used with/in place of Code.org's own CPT unit))
    The Create PT's design guide and example graded projects are explicitly audience-facing (a real AP exam submission an outside reader scores), a stronger claim than cmu_cs1.json can make for its own Creative Task, which only has a feedback step if the teacher builds one in.
  • CodeHS' Intro to JavaScript: Unit 13 (Final Project) (partial)
    Design-for-audience lands only in the Unit 13 final project -- a capstone, not a recurring practice. A genuine open-ended build does ask for it once; it just isn't the ten-times-a-year rhythm CMU's Creative Task gives the same standard.
  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (3A-AP-19, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3a: Music Lab): Unit 3 (Unit 3a - Programming with Music Lab)
    Mechanically derived from this carrier's own csta2017 entry (3A-AP-19, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (related)
    This carrier's own 9-12 reading: both major projects (Lesson 18 Interactive Card, Lesson 28 Design a Game) ship a 'Peer Review' activity guide students use to give each other structured feedback, which the Game Design Process lessons (26-27) then have students act on. It's a real feedback-and-revise loop, just a classroom partner rather than the standard's own 'real users' / 'broad audience' framing.
  • Working in Python (a jupyter notebook): not covered
    Chapter 4's development plan is a solo, technical process -- it never involves gathering feedback from an audience of users. Real gap, distinct from AP.21/CRD-1.1's collaboration gap: this one is about user feedback, not teammate collaboration.

#9-12.AP.19

Using someone else's library or code comes with license terms that limit what you can do with it.

  • Carnegie Mellon's Introduction to Programming with Python (High School): not covered
    Not taught in CS1 -- software license limitations are deliberately deferred to AP CS Principles, where this teacher covers it directly with his own materials.
  • Carnegie Mellon's AP CSP in Python: not covered
    Not taught in this product's pacing guide -- software license limitations aren't named in either source PDF, matching cmu_cs1.json's own explicit gap for its unit-19 equivalent.
  • CodeHS' Intro to JavaScript: not covered
    Not in Corgi's unit list -- software license limitations don't appear anywhere in the syllabus, the same gap as CMU CS1, which defers this topic to AP CS Principles.
  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (3A-AP-20, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Working in Python (a jupyter notebook): not covered
    Not covered. Same gap as AP CRD-2.H (acknowledging code from other sources) -- the book never discusses licensing or attribution of borrowed code, even though Chapter 4/Chapter 8 use libraries.

#9-12.AP.20

A program gets better through repeated rounds of testing and fixing, aimed at more than just correctness -- performance and ease of use matter too.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc, Subconcept Program Development: 'Iteratively evaluate and refine a computational artifact to enhance its performance, reliability, usability, and accessibility.'
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit creative-task (Creative Task (every unit, 1-10))
    The Creative Task's build-reflect-revise cycle runs ten times a year (units 1-10).
  • Carnegie Mellon's AP CSP in Python: Unit 5 (Unit 5: Create Performance Task (supplemental, used with/in place of Code.org's own CPT unit))
    The Create PT is a build-reflect-revise cycle by design (practice Create Tasks, then the graded submission); the syllabus PDF tags this unit's collaborative option with CTP1/CTP3/CTP4/CTP6.
  • CodeHS' Intro to JavaScript: Unit 13 (Final Project) (partial)
    Iterative refinement lands only in the Unit 13 final project.
  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-AP-21)
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (related)
    This carrier's own 9-12 reading: the same Peer Review + Student Checklist pairing on both major projects drives iteration aimed at more than raw correctness (the checklist covers whether the game is actually fun/usable, not just whether it runs). Narrower than the standard's own 'performance and ease of use' framing -- no performance angle here, just correctness and usability.
  • Harvard's CS50-Python (Weeks 0-8): Unit 5 (Lecture 5: Unit Tests)
    Unit Tests and pytest, named week-5 headings, are repeated rounds of testing aimed at more than just running once.
  • Working in Python (a jupyter notebook): Chapter 4 (Functions and Interfaces), Chapter 7 (Iteration and Search)
    Chapter 4's development plan and Chapter 7's doctest work carry the iterative-testing half. Usability and accessibility specifically -- this standard's other named dimensions -- aren't addressed anywhere in the book.

#9-12.AP.21

Building something as a team, in defined roles, with shared tools, is different work from building it alone.

  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit collaborative (Collaborative task (every unit))
    Real-time shared-editor pair programming is built into every unit, not a capstone.
  • Carnegie Mellon's AP CSP in Python: Unit 5 (Unit 5: Create Performance Task (supplemental, used with/in place of Code.org's own CPT unit))
    The syllabus PDF explicitly offers a collaborative Creative Task grouping option for the unit that maps onto this product's Unit 5.
  • CodeHS' Intro to JavaScript: Unit 3 (JavaScript Basics), Unit 13 (Final Project) (related)
    One collaboration lesson appears in unit 3 (driver/navigator, list the pros and cons), and the final project (13) may involve it too, but the standard's own real practice is concentrated at the end of the course rather than built into the rhythm of every unit -- one lesson on pair programming addresses the letter of the standard without much of what it's meant to capture.
  • Kagan Cooperative Learning — Teambuilding: Unit Team Projects (Team Projects) (related)
    Team Projects does assign defined roles before the team builds something together, matching half of this standard, but the standard also specifically names 'shared tools' -- collaborative software tooling this book never touches -- so it's surfaced as related rather than counted as genuine coverage.
  • Outside-the-book supplement (lab practice, CPT, misc.): covered, no locator on record
    Same practice as AP CRD-1.1 (Collaboration). Taught continuously, through lab pair work and the Create Performance Task, not as a standalone lesson.

#9-12.AP.22

As a program's design takes shape, writing the decisions down -- in whatever form fits -- is what makes the process legible to anyone else who looks at it later.

  • Bootstrap:Algebra: Chapter 7 (Contracts for Strings and Images), Chapter 16 (Functions: Contracts, Examples & Definitions) (partial)
    Contracts and examples are written design decisions about a function; there is no project-level design document.
  • Carnegie Mellon's Exploring Programming with Python (Middle School): covered, no locator on record
    CMU's own CA alignment doc: 'Document decisions made during the design process using text, graphics, presentations, and/or demonstrations in the development of complex programs.'
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit creative-task (Creative Task (every unit, 1-10))
    The Creative Task requires describing the program and reflecting on what changed and why -- documentation of design decisions, ten times a year.
  • Carnegie Mellon's AP CSP in Python: Unit 5 (Unit 5: Create Performance Task (supplemental, used with/in place of Code.org's own CPT unit))
    The Create PT's own written-response prompts about the finished program are documentation of design decisions -- the CPT cannot be submitted without them.
  • CodeHS' Intro to JavaScript: Unit 13 (Final Project) (partial)
    Documentation lands only in the Unit 13 final project.
  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (related)
    This carrier's own 9-12 reading: Lesson 1's Animation and Game Design Template and Lesson 28's planning objective ('create a plan... describing its major components') both have students write their design down before building it. A worksheet-level design doc, not code-level documentation, but a real instance of writing decisions down to make them legible later.
  • Working in Python (a jupyter notebook): Chapter 4 (Functions and Interfaces)
    Chapter 4's docstrings and development-plan material carry the in-code documentation half. The graphics/presentation/demonstration forms of documentation this standard also names aren't part of the book.
9-12 Specialty

#9-12S.AP.10

AI already sits inside plenty of everyday software and physical systems -- research one and explain how it's actually doing its job there.

Unassigned

#9-12S.AP.11

Building a small AI-driven program that handles a simple task a living thing would normally do -- like navigating toward a goal -- is different from implementing AI theory from scratch.

Unassigned

#9-12S.AP.12

Writing a real search or sort into a program to organize or retrieve data matters more here than choosing the fastest algorithm.

  • Working in Python (a jupyter notebook): Chapter 7 (Iteration and Search), Chapter 9 (Lists)
    Same evidence as this file's core 9-12.AP.12 entry: Chapter 7 builds a linear-search algorithm from scratch and Chapter 9 uses the built-in sorted -- writing a real search and using an existing sort, exactly this standard's emphasis.

#9-12S.AP.13

The same task written two different ways can run at very different speeds, and naming that difference with a time class -- linear, quadratic, log n -- makes the comparison concrete.

  • CS50 Problems: Unit 10 (Lineup (more comfortable))
    Lineup (more comfortable)'s NOTE aside on deque vs. list is a plain-language version of exactly this: the same task (removing from the front) runs at very different speeds depending on the structure, without ever naming Big-O formally. This is the CA 9-12 Specialty (non-core) tier, one step beyond the core standards the earlier six psets cite.
  • Working in Python (a jupyter notebook): not covered
    Real gap: the book never names a formal complexity class. Chapter 10's fibonacci section shows the naive recursive version getting slower as n grows and fixes it with memoization (fibonacci_memo), and Chapter 10 also prefers a dictionary over a list specifically because lookup is faster -- both are informal, hands-on brushes with efficiency, but 'linear', 'quadratic', and 'log n' never appear anywhere in chapters 1-13.

#9-12S.AP.14

Different data structures trade off differently for the same basic operations -- inserting, deleting, modifying -- and picking one over another is a real design decision, not a formality.

  • CS50 Problems: Unit 10 (Lineup (more comfortable))
    Lineup (more comfortable) makes the data-structure choice explicit and consequential: deque over list for the queue (fast at both ends), plain list over deque for the history stack (fast at one end already, so the extra machinery buys nothing). Same CA 9-12 Specialty (non-core) tier as 9-12S.AP.13.
  • Working in Python (a jupyter notebook): Chapter 10 (Dictionaries) (partial)
    Chapter 10 switches from a list to a dictionary specifically because dictionary lookup is faster than scanning a list with in -- a genuine data-structure trade-off. Narrower than the standard's own examples (insert/delete/modify): the book's comparison is about lookup speed only, not those three operations.

#9-12S.AP.15

Tracing how a recursive algorithm actually resolves means following the chain of calls down to a base case and back up again, not just trusting that it works.

  • CS50 Problems: Unit 11 (Inheritance)
    Inheritance's create_family is exactly this: a base case (generations == 1, no parents) and a recursive case (build both parents first, then choose alleles from them), and the Hints section explicitly walks through why the parents have to be built before this person's alleles can be chosen. Same CA 9-12 Specialty (non-core) tier as the two entries above.
  • Working in Python (a jupyter notebook): Chapter 5 (Conditionals and Recursion), Chapter 6 (Return Values), Chapter 10 (Dictionaries)
    Chapter 5's stack diagrams for recursive functions and Chapter 6's factorial/fibonacci trace a call chain down to its base case and back -- exactly this standard's own framing. Chapter 10's fibonacci call graph (visualizing repeated calls for fibonacci(4)) is the same tracing done as a diagram instead of a stack of frames.

#9-12S.AP.16

A big, real-world problem usually decomposes into smaller pieces that already have a solution -- reusable code or a known procedure -- if you can spot the pattern.

  • Bootstrap:Algebra: Chapter 21 (Problem Decomposition) (partial)
    'Problem Decomposition' (top-down and bottom-up, revenue, cost and profit) is breaking a problem into pieces that already have a procedure; real-world scale and reuse of existing code are not part of it.
  • Working in Python (a jupyter notebook): Chapter 4 (Functions and Interfaces), Chapter 7 (Iteration and Search) (partial)
    Chapter 7's uses_all, built by reusing uses_any/uses_only instead of writing a new loop, and Chapter 4's arc built by generalizing the existing polygon-derived circle, are both instances of spotting that a subproblem already has a solution close at hand -- this standard's own framing, distinct from AP.17's 'write your own procedures' and AP.18's 'reach for a library.'

#9-12S.AP.17

A problem substantial enough to need decomposing is also substantial enough to justify building it from your own procedures, modules, or objects instead of one long script.

  • Working in Python (a jupyter notebook): Chapter 3 (Functions), Chapter 4 (Functions and Interfaces)
    Chapter 3's print_verse built from first_two_lines/last_three_lines/repeat, and Chapter 4's square/polygon/circle/arc/polyline chain, are the book's clearest instances of decomposing a substantial problem into its own procedures instead of one long script.

#9-12S.AP.18

Pulling in a well-tested library or API instead of reimplementing its functionality is what code reuse actually looks like in practice.

#9-12S.AP.19

Planning software for people beyond yourself means following an actual development-lifecycle process, not just writing until it works.

  • Working in Python (a jupyter notebook): Chapter 4 (Functions and Interfaces) (partial)
    Chapter 4's development plan (problem statement, examples, template, draft, test) is a real, structured process, not writing until it works. Same caveat as this file's core 9-12.AP.18 gap: it's a solo, technical process that never involves feedback from users beyond the student, so the 'planning software for people beyond yourself' half of this standard is thinner than the process half.

#9-12S.AP.20

The same solution often needs to exist on more than one platform -- desktop, web, mobile -- and building it for more than one is the point here.

  • Working in Python (a jupyter notebook): not covered
    Real gap: every example in this book runs in one place, the Jupyter/JupyterLite environment. Chapters 1-13 never ask a student to target more than one platform, and there's no desktop/web/mobile comparison anywhere.

#9-12S.AP.21

Reading someone else's code well enough to spot a security hole, show how a specific input would exploit it, and then close it is the actual skill.

Unassigned

#9-12S.AP.22

A meaningful set of test cases covers ordinary behavior and the edge cases at the boundary, not just the input you expect to work.

#9-12S.AP.23

Adding functionality to existing code means also tracking down what that change might break elsewhere, intended or not.

  • Working in Python (a jupyter notebook): not covered
    Real gap: Chapter 4's refactoring (circle built on polygon, then generalized into arc and polyline) and Interlude A/Chapter 7's doctest work are the book's two closest threads, but they're never connected -- the book doesn't frame 'does this change break something that used to work' as its own concern.

#9-12S.AP.24

A code review means walking someone through your own code, and following along with real questions when someone else walks through theirs.

  • Code.org's CS Discoveries (Unit 3b: Animations & Games): Unit 4 (Unit 3b - Interactive Animations and Games) (related)
    This carrier's own 9-12 Specialty reading: both major projects ship a named 'Peer Review' activity guide, a real structured walk-a-partner-through-your-code step. Worksheet-guided and introductory, not the open-ended professional code review this strand otherwise targets, but a genuine instance of the practice rather than a stretch.

#9-12S.AP.25

Building software as a group means actually using the tools that make group development work -- version control, a real IDE, documentation practices -- not just splitting up files.

  • Working in Python (a jupyter notebook): not covered
    Real gap, same evidence as this file's new csta2026 S1-SWD-PP-08 entry: no version control, shared IDE workflow, or team documentation practice anywhere -- the book is written for solo work throughout chapters 1-13.

#9-12S.AP.26

Different programming languages fit different problems better, and being able to say why a specific language suits a specific task is the actual comparison.

Unassigned

#CS Computing Systems

6-8

#6-8.CS.1

A computing device's design shapes how easily people can actually use it, and proposing a change to that design is itself a real engineering task.

Unassigned

#6-8.CS.2

Building something that collects and shares data means choosing hardware and software components together, weighing tradeoffs like cost, speed, and size.

#6-8.CS.3

Fixing a broken computing system means working through a structured troubleshooting process, not guessing -- and a problem in one connected device can come from another.

Unassigned

9-12

#9-12.CS.1

Computing systems hide their internal workings behind a simpler experience for the person using them.

About hardware/device abstraction (e.g., a phone hiding its GPS hardware from the user), not software abstraction in code.

  • Harvard's CS50-Python (Weeks 0-8): Unit 8 (Lecture 8: Object-Oriented Programming)
    A class's methods hiding its internal attributes behind a simpler interface -- encapsulation, the week's own Classes/Object-Oriented Programming headings -- is this standard's 'hide internal workings' claim made concrete.
  • Working in Python (a jupyter notebook): not covered
    Nothing in the book addresses this. Not covered by the AP crosswalk either -- a systems-level topic with no obvious carrier in either framework as currently scoped.

#9-12.CS.2

Application software, system software, and hardware form layers that each manage their own part of getting a task done.

#9-12.CS.3

Troubleshooting a complex problem means researching, testing, and drawing on past experience with similar problems, and writing that process down so someone else can repeat it.

  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 2 (Week 2: Arrays)
    Debugging, plus reliance on Manual Pages, is troubleshooting a problem through research and testing.
  • Harvard's CS50-Python (Weeks 0-8): Unit 3 (Lecture 3: Exceptions), Unit 5 (Lecture 5: Unit Tests)
    Exceptions/runtime errors (week 3) and pytest (week 5) are both named troubleshooting-through-testing content.
  • MicroPython on Pi Pico and Projects: Chapter 5 (Traffic light controller)
    Wiring three LEDs, a button, and a buzzer to the right pins on a breadboard is exactly the kind of troubleshooting-by-testing this standard describes, but the lesson doesn't frame it as a debugging skill explicitly.
  • Pico Projects: Chapter p1.1 (Project 1.1: Wiring Three LEDs), Chapter p1.6 (Project 1.6: Wiring a Switch Bank)
    Project 1.1's two-stage sign-off, a neighbor check followed by a teacher check against a written workmanship rubric, is a structured, repeatable troubleshooting process. Project 1.6 repeats the exact same sign-off process for the switch wiring, comparing the breadboard against an exemplar photo before anything gets powered back on.
  • Working in Python (a jupyter notebook): not covered
    The descriptive statement's examples (network connectivity, help-desk guidelines) are about systems/hardware troubleshooting, not code debugging. Every chapter's 'Debugging' section teaches the code-debugging skill this is adjacent to, but that carries AP CRD-1.4, not this standard as written -- deliberately not claiming credit here for a different skill.
9-12 Specialty

#9-12S.CS.1

A processor's logic gates -- AND, OR, NOT -- combine into higher-level circuits like adders, and that's the literal hardware carrying out a program's instructions.

  • Working in Python (a jupyter notebook): not covered
    Not covered. Same status as this file's core 9-12.CS.1 entry -- a hardware/systems topic with no carrier anywhere in the book.

#9-12S.CS.2

An operating system's separate jobs -- managing memory, storage, running processes, controlling access -- can each be named and told apart.

  • Working in Python (a jupyter notebook): not covered
    Not covered. Chapter 13's os module (listdir, path operations, walking directories) is the book's only brush with the operating system, and it's filesystem-only -- memory management, process management, and access control, the standard's other named jobs, never come up.

#DA Data & Analysis

6-8

#6-8.DA.7

The same data can be represented in more than one way, and choosing a representation changes what's easy to see in it.

  • Carnegie Mellon's Exploring Programming with Python (Middle School): Unit 1 (Drawing with Shapes)
    A shape's position, size, and color are all numeric properties -- the same drawn shape can be built from different property values, the representation choice this standard names. Inferred from the unit title.
  • Carnegie Mellon's Introduction to Programming with Python (High School): Unit 9.1 (Types and Input (Unit 9 is optional)), Unit 9.2 (Strings (Unit 9 is optional))
    This carrier's own inference, and Unit 9 is marked optional in CMU's own pacing guide: types and input (9.1) and strings (9.2) are where the same value can be represented as an int, a float, or a string, and the choice changes what you can do with it.
  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 2-DA-07)
  • Bootstrap:Data Science — Hour of Data: Unit 3 (Introducing the Pyret Programming Environment — Bar Chart / Pie Chart), Unit 5 (More Pie Charts & Bar Charts), Unit 6 (Comparing Subsets / Making Predictions Using Proportional Reasoning), Unit 7 (Patterns in the Code — More Subsets & Pie Charts via Filtering), Unit 8 (Analyzing Scatter Plots Using Rate of Change)
    Same representation-choice argument as 9-12.DA.10 above, at the MS band -- same parts of the activity, since it's one lesson used at both levels with different scaffolding (Bootstrap's own note: MS needs guidance, HS can work independently).
  • porttack.com: Coding: Teaching Binary With Coins (partial)
    This carrier's own inference, mirroring 9-12.DA.8 above at the lighter '6-8 representation changes what's easy to see' framing this standard uses -- hex vs. binary for the same byte value is exactly that: which representation makes byte boundaries or bit patterns easier to read, which is the post's own argument for introducing hex at all.
  • CS Unplugged: Count the Dots: binary numbers, Secret Messages in ASCII, Pixel Pictures (partial)
    Each sheet shows one thing in more than one form: a number as decimal, binary, or a row of lights (Count the Dots); a letter as a number and as bits (ASCII); a picture as a grid of pixels and as run-length numbers (Pixel Pictures).

#6-8.DA.8

Raw data collected with computational tools usually needs to be transformed before it's actually useful for answering a question.

  • Bootstrap:Data Science — Hour of Data: Unit 2 (Introducing the Dataset: Animal-Vehicle Collisions in Vermont — Notice and Wonder), Unit 4 (Scatter Plots, Outliers & Human Error), Unit 7 (Patterns in the Code — More Subsets & Pie Charts via Filtering)
    Notice-and-Wonder (Part 2), the outlier/human-error catch (Part 4), and filtering by route or animal (Part 7) are all raw data being transformed before it's useful -- this standard's own scope.

#6-8.DA.9

A computational model lets you change one variable at a time and observe the effect, which is how you test what's actually driving a result.

  • Bootstrap:Data Science — Hour of Data: Unit 6 (Comparing Subsets / Making Predictions Using Proportional Reasoning), Unit 8 (Analyzing Scatter Plots Using Rate of Change) (partial)
    Part 6 compares raccoon-collision rates between I-89 and I-91 (changing which subset, observing the effect), and Part 8 compares 2004 vs 2005 collision rates by slope -- both change one variable and observe the effect on the same dataset.
  • Pico Projects: Chapter p2.2 (Project 2.2: Reading a Potentiometer, and What a Voltage Divider Is), Chapter p2.3 (Project 2.3: Adding a NeoPixel Bar), Chapter p2.5 (Project 2.5: Swapping in a Light Sensor)
    Project 2.2 has a student turn the potentiometer and watch the plotted voltage respond, changing one variable (the knob's position) and directly observing its effect on another (the printed/plotted number) -- the same single-variable-at-a-time testing this standard describes, done with a physical dial instead of a spreadsheet. Project 2.3 makes that effect visible on the NeoPixel bar instead of just a number. Project 2.5 takes the idea further: swapping the potentiometer for an LDR, while running the exact same code, changes only the sensor itself, and everything downstream keeps working.
9-12

#9-12.DA.8

The same real-world thing -- a color, a character, an image -- can be represented digitally in more than one way, and converting between those representations is a normal task.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-DA-09)
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 0 (Week 0: Scratch -- data representation only (unary, binary, decimal, ASCII, Unicode, RGB)), Unit 4 (Week 4: Memory -- data representation only (hexadecimal, images, file I/O))
    Same representation claim as apcsp 2.1: the same image or character can be encoded more than one way (unary/binary/decimal/ASCII/Unicode/RGB, hexadecimal).
  • CS50 Problems: Unit 2 (Pathfinder), Unit 5 (Caesar)
    Pathfinder and Caesar both convert between a character and a numeric representation of it -- the same letter can be written as a symbol or as a number, and moving between the two is the whole point of each problem.
  • MicroPython on Pi Pico and Projects: Chapter 8 (Temperature gauge), Chapter 12 (Bluetooth connectivity)
    Chapter 8 converts a raw ADC reading into a voltage and then into a temperature via two separate equations -- the same real-world quantity represented three different ways. Chapter 12 packs a floating-point temperature into structured binary bytes with struct.pack and unpacks it back with struct.unpack on the receiving end.
  • Pico Projects: Chapter p1.4 (Project 1.4: Blinking Your LEDs)
    Project 1.4's binary-counting challenge represents a count from 0 to 7 a third way, after chapters 8 and 12's own two: as a physical pattern across three LEDs, each one standing for a place value.
  • porttack.com: Coding: Teaching Binary With Coins
    The color-picker demonstration (RGB, each channel 0-255) and the byte-to-hex conversion ('split a byte down the middle, convert each half, and you get two characters instead of eight') are this standard's own example set almost verbatim -- a color represented digitally in more than one way, converting between representations as a normal task.
  • CS Unplugged: Count the Dots: binary numbers, Secret Messages in ASCII, Pixel Pictures (partial)
    The California standard names characters, numbers, and images: Count the Dots converts numbers between decimal and binary, ASCII converts characters to numbers and bits, Pixel Pictures converts an image to pixels and run-length numbers. Color isn't covered.
  • Working in Python (a jupyter notebook): Interlude B (Representing Data, outline only)
    Same underlying content as AP 2.1/DAT-1.A (data represented using bits), carried by the interlude between chapters 7 and 8 ('Representing Data', Interlude B) -- see apcsp.json's 2.1 note for the full carrier detail, including that Interlude B is an outline only as of 2026-08-17, not drafted prose. Previously logged as carried by CS50T Multimedia, same as that AP topic; removed 2026-08-09 -- teacher confirms that supplement hasn't been taught since year one. Pico I2C unit remains a secondary, partial touchpoint.

#9-12.DA.9

How data is organized and where it's stored is a choice with real consequences for cost, speed, reliability, privacy, and integrity.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information), Unit 9 (Unit 9: Data)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-DA-10)
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 7 (Week 7: SQL)
    SQL's own named topics -- Tables, Types, Constraints, Indexes -- are exactly 'how data is organized and where it's stored.'
  • Harvard's CS50-Python (Weeks 0-8): Unit 6 (Lecture 6: File I/O)
    File I/O, CSV, and Binary Files and PIL, named week-6 headings, are literally how and where data gets organized and stored.
  • MicroPython on Pi Pico and Projects: Chapter 9 (Data logger) (partial)
    The FILE STORAGE aside works out how long the data logger can run before filling the Pico's file system at different logging intervals -- a real storage-capacity tradeoff, though the lesson doesn't extend this to reliability, privacy, or integrity.
  • Working in Python (a jupyter notebook): Interlude B (Representing Data, outline only)
    Partially carried: the CED's own worked example for this standard is file-size-vs-quality tradeoffs across image formats -- the same territory as AP 2.2/DAT-1.D (data compression), which the interlude between chapters 7 and 8 ('Representing Data', Interlude B) now covers. But DA.9's scope is broader than 2.2 alone (storage location, cost, reliability, privacy, integrity), and Interlude B's outline doesn't reach those dimensions -- see apcsp.json's 2.2 note. As of 2026-08-17 Interlude B is an outline only, not drafted prose. Previously logged as carried by CS50T Multimedia; removed 2026-08-09, same reason as DA.8.

#9-12.DA.10

Turning a data set into a visualization is itself a design choice that shapes what other people take away from it.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 9 (Unit 9: Data)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: partial) -- not independently checked against a code.org source document. (from 3A-DA-11)
  • Bootstrap:Data Science — Hour of Data: Unit 3 (Introducing the Pyret Programming Environment — Bar Chart / Pie Chart), Unit 5 (More Pie Charts & Bar Charts), Unit 6 (Comparing Subsets / Making Predictions Using Proportional Reasoning), Unit 7 (Patterns in the Code — More Subsets & Pie Charts via Filtering), Unit 8 (Analyzing Scatter Plots Using Rate of Change)
    Parts 3/5/7 move through bar, pie, and filtered-subset charts of the same dataset. Part 6's Teacher Moves note raises the pitfall ('a blue wedge does not necessarily represent the same animal in both charts'), but the guide says only some students will notice it and the teacher may point it out, so the misleading-chart half of the standard depends on the teacher.
  • Working in Python (a jupyter notebook): not covered
    Real gap: the book has no plotting/visualization content anywhere (no charting library is used in chapters 1-13). Chapter 12's word-frequency and Markov work processes data but never visualizes it.

#9-12.DA.11

A computational model is only useful once it's been checked against real observations and adjusted where it doesn't match.

  • Bootstrap:Data Science — Hour of Data: Unit 4 (Scatter Plots, Outliers & Human Error)
    Part 4's exact reasoning (screen 11 of the Teacher Guide) checks a model against real observations and catches the mismatch: 'both days and collisions are recorded in order from the start of the data collection period. If the deer hit on day 371 is collision number 657, it doesn't make sense that a deer hit 4 days earlier would be collision number 901' -- validating an assumption about the dataset's structure against what the data actually shows, and using the contradiction to identify a human-error outlier.
  • MicroPython on Pi Pico and Projects: Chapter 6 (Reaction game) (related)
    The lesson states a real baseline (average human reaction time, ~200-250ms) that a player's own measured result can be compared against, but it doesn't ask students to use the comparison to adjust a model.
  • Working in Python (a jupyter notebook): not covered
    Not covered. Chapter 12's Markov text model is a model of sorts but the chapter never validates or refines it against real-world data the way this standard describes -- too loose a connection to claim as a carrier.
9-12 Specialty

#9-12S.DA.7

Which data-collection tool you pick, and how carefully you use it, determines whether the data you end up with can actually support a real conclusion.

  • Bootstrap:Data Science — Hour of Data: Unit 4 (Scatter Plots, Outliers & Human Error), Unit 7 (Patterns in the Code — More Subsets & Pie Charts via Filtering) (partial)
    Part 4's human-error outliers and Part 7's turtles coded 'unknown' show how the way the data was recorded limits what conclusions it supports. Students do not choose or use a collection tool.

#9-12S.DA.8

Software tools for analyzing, summarizing, and visualizing a genuinely large dataset are what make patterns in complex, real-world systems visible at all.

  • Bootstrap:Data Science — Hour of Data: Unit 3 (Introducing the Pyret Programming Environment — Bar Chart / Pie Chart), Unit 4 (Scatter Plots, Outliers & Human Error), Unit 5 (More Pie Charts & Bar Charts), Unit 8 (Analyzing Scatter Plots Using Rate of Change) (partial)
    Students use software to summarize and visualize the data (bar, pie, scatter) and see patterns the table hides. The dataset is under a thousand rows, not large.
  • Working in Python (a jupyter notebook): not covered
    Real gap, same evidence as this file's core 9-12.DA.10 entry: Chapter 12 genuinely analyzes and summarizes a large real text dataset (word and bigram frequencies across a whole book), but the standard asks for analyzing, summarizing, AND visualizing together, and there's no charting anywhere in chapters 1-13.

#9-12S.DA.9

A model or simulation is only useful for refining a hypothesis once you've judged how accurately it actually represents the system it's standing in for.

  • Little Brother (a book by Cory Doctorow): Chapter 7 (Hiding in Plain Ciphertext), Chapter 8 (The Paradox of the False Positive)
    The whole paradox-of-the-false-positive sequence is judging a model's accuracy against the real system it claims to represent -- a 99-percent-accurate test still produces 200,000 false flags to catch 10 real terrorists in a city of 20 million, because the test's accuracy doesn't come close to matching the rarity of what it's hunting for.
  • Working in Python (a jupyter notebook): not covered
    Not covered. Same status as this file's core 9-12.DA.11 entry: Chapter 12's Markov text model is a model of sorts, but the chapter never judges how accurately it represents anything or uses that judgment to refine a hypothesis.

#IC Impacts of Computing

6-8

#6-8.IC.20

Computing technologies that reshape daily life and careers always come with tradeoffs worth weighing, not just benefits.

#6-8.IC.21

Existing technologies can carry real bias and accessibility problems baked into their design, worth examining directly.

  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-IC-21, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Little Brother (a book by Cory Doctorow): Chapter 8 (The Paradox of the False Positive)
    This carrier's own inference, mirroring 9-12.IC.24 above: the false-positive scene is an existing technology's bias made explicit and examined directly.

#6-8.IC.22

Building a computational artifact often means collaborating with many contributors, not working alone.

  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-IC-22, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Student Movies: Unit spare-parts (Spare Parts) (partial)
    Building a computing artifact is a team effort.

#6-8.IC.23

A license is a tradeoff between protecting a creator's rights and letting other people use and modify their work.

  • Little Brother (a book by Cory Doctorow): Chapter intro (Introduction)
    This carrier's own inference, mirroring 9-12.IC.28 above: the book's own printed Creative Commons license is a license as a real tradeoff between a creator's rights and what others can do with the work.

#6-8.IC.24

Making information public and keeping it private and secure are competing goods, and choosing between them is a real tradeoff.

  • Code.org's CS Discoveries (Units 1-2): Unit 2 (Unit 2 - Web Development)
    Mechanically derived from this carrier's own csta2017 entry (2-IC-23, strength: strong) via the castandards-csta2017 crosswalk -- not independently checked against a code.org source document.
  • Little Brother (a book by Cory Doctorow): Chapter 1 (Surveillance, ARGs, and Cutting Class), Chapter 13 (A Secret Comes Out), Chapter 20 (Masha, the Chase, and the Evidence)
    This carrier's own inference, mirroring 9-12.IC.29/30 above: arphid and camera tracking (1, 13) and the interrogation scene (20) are public-versus-private-and-secure information as a real, competing-goods tradeoff, not an abstract one.
  • Student Movies: Unit rons-gone-wrong (Ron's Gone Wrong) (partial)
    Public versus private information.
  • porttack.com: Society (Impact of Computing): the source
    Grades 7-9 seminar: a default setting is a choice between two competing goods, a lost dog found fast versus neighbors' cameras searched without being asked. Students weigh it in Round 1 and state it again on the exit ticket (leave it on, or turn it off).
9-12

#9-12.IC.23

Computing changes personal, social, economic, and cultural practices, not always for the better.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information), Unit 2 (Unit 2: The Internet)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-IC-24)
  • Little Brother (a book by Cory Doctorow): Chapter intro (Introduction), Chapter epilogue (Epilogue)
    The Introduction's account of computers as both liberating and surveilling, and the Epilogue's reckoning with the fallout, are computing changing social and cultural practice, not always for the better -- the novel's frame from both ends.
  • Student Movies: Unit the-social-dilemma (The Social Dilemma), Unit the-social-network (The Social Network) (related)
    Computing changes social practices.
  • porttack.com: Society (Impact of Computing): Finding Fido or Finding You?
    From the post's own appendix: computing's social and cultural effects, not always for the better -- the Ring ad backlash across senators, privacy groups, and ordinary users.

#9-12.IC.24

Bias built into a computing artifact, often from assumptions its designers didn't question, has to be actively tested for and reduced.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 2-IC-23; the crosswalk notes CA's own numbering shift here)
  • Little Brother (a book by Cory Doctorow): Chapter 8 (The Paradox of the False Positive)
    The false-positive scene is bias built into a computing artifact (a surveillance/pattern-matching system) that its designers didn't have to intend for it to misfire on innocent people at scale.

#9-12.IC.25

The same algorithm often turns out to solve problems in fields far from where it was first designed.

  • CS Unplugged: The Muddy City, Solo Battleship (related)
    Both sheets point out where the same method turns up elsewhere: minimal spanning trees in power, water, phone, and airline networks (Muddy City); constraint solving and backtracking in class scheduling, delivery routes, and truck packing (Solo Battleship).

#9-12.IC.26

New technologies reshape social, economic, and political structures in ways worth examining critically, not just adopting.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information), Unit 2 (Unit 2: The Internet), Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: related) -- not independently checked against a code.org source document. (from 3B-IC-27, 3B-IC-26, and 3B-IC-25 respectively -- a 'related,' not 'strong,' crosswalk in every case)
  • Little Brother (a book by Cory Doctorow): Chapter intro (Introduction), Chapter 4 (Detained and Interrogated by DHS), Chapter 5 (A Reunion, Missing One Friend), Chapter 20 (Masha, the Chase, and the Evidence), Chapter epilogue (Epilogue)
    Not in the teacher's own blog table, but arguably the book's central theme: a DHS-style security state reshaping social and political structure after a crisis (the Introduction and chapters 4-5's detention), paid off in Chapter 20's interrogation and the Epilogue's accountability reckoning.
  • Student Movies: Unit the-ai-doc-or-how-i-became-an-apocaloptimist (The AI Doc: Or How I Became an Apocaloptimist) (partial)
    New technology reshapes structures.
  • porttack.com: Society (Impact of Computing): Can a Company Have a Conscience?
    A single company's contract decision reshaping its relationship with the federal government, consumer sentiment, and a competitor's own choices in the same week is exactly this standard's 'new technologies reshape social, economic, and political structures' claim, playing out in real time.

#9-12.IC.27

Digital collaboration tools connect people across cultures and professions in ways that reshape how teams work together.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-IC-27)

#9-12.IC.28

Intellectual property law cuts both ways for innovation: it protects creators, but it can also limit what gets built next.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 1 (Unit 1: Digital Information), Unit 2 (Unit 2: The Internet)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-IC-28)
  • Little Brother (a book by Cory Doctorow): Chapter intro (Introduction)
    The book's own Creative Commons license, printed in full in the Introduction, is intellectual property law read directly rather than summarized -- both what it protects and what it lets other people build on.
  • Student Movies: Unit the-social-network (The Social Network) (related)
    Intellectual property law cuts both ways.

#9-12.IC.29

A lot of personal data is collected automatically, without the person it describes actively participating, and that raises its own privacy concerns.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-IC-29)
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 9 (Week 9: Flask)
    Sessions and Cookies, named week-9 topics, are the concrete mechanism for collecting a visitor's data automatically between requests.
  • Little Brother (a book by Cory Doctorow): Chapter 1 (Surveillance, ARGs, and Cutting Class), Chapter 13 (A Secret Comes Out)
    Arphid tracking (1) and a camera's individually identifiable 'noise signature' (13) are both data collected automatically, without the person it describes ever opting in.
  • Student Movies: Unit rons-gone-wrong (Ron's Gone Wrong), Unit the-social-dilemma (The Social Dilemma), Unit the-social-network (The Social Network) (partial)
    Personal data is collected automatically.
  • porttack.com: Society (Impact of Computing): Finding Fido or Finding You?, the source
    From the post's own appendix: Search Party is on by default and opt-out, meaning most camera owners' footage gets pulled into the system without ever actively agreeing to it -- this standard's 'automatic data collection without active participation' almost verbatim.

#9-12.IC.30

Privacy laws and ethics differ across places and contexts, and evaluating a policy means weighing its social and economic tradeoffs.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 2 (Unit 2: The Internet), Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-IC-30)
  • Little Brother (a book by Cory Doctorow): Chapter 20 (Masha, the Chase, and the Evidence), Chapter epilogue (Epilogue)
    Chapter 20's interrogation (including an explicit waterboarding reference) and the Epilogue's policy reckoning are privacy and civil liberties weighed against safety and law, in exactly the contested, context-dependent way this standard names.
  • Student Movies: Unit the-imitation-game (The Imitation Game), Unit sneakers (Sneakers) (partial)
    Privacy and security have to be weighed against each other.
  • porttack.com: Society (Impact of Computing): Finding Fido or Finding You?
    From the post's own appendix: weighing privacy against the safety and law-enforcement case Ring's founder makes for near-zero neighborhood crime is this standard's privacy-vs-safety-and-law tradeoff.
9-12 Specialty

#9-12S.IC.27

Judging a computational artifact means naming both who it actually helps and who it actually harms, and proposing something concrete to fix the harm.

  • Little Brother (a book by Cory Doctorow): Chapter 8 (The Paradox of the False Positive), Chapter 9 (Suspicion Spreads, Even to Dad), Chapter epilogue (Epilogue)
    The false-positive math names who a badly-tuned computational artifact harms -- overwhelmingly innocent people, hundreds of thousands of them for every real terrorist caught (8) -- and Chapter 9 makes clear that harm isn't evenly spread (Jolu's point about who actually gets pulled over and searched). The Epilogue's fix isn't just 'stop the surveillance' -- it's concrete: state-level civilian oversight empowered to inspect and shut down DHS operations.

#9-12S.IC.28

A technology that already reshaped some part of culture is still moving, and describing where it goes next -- and what that costs or brings -- is the forecast being asked for.

  • Little Brother (a book by Cory Doctorow): Chapter epilogue (Epilogue) (partial)
    The Epilogue doesn't end with the DHS simply gone -- it ends with the Coalition of Voters for a Free America planning a new ARG timed to the election, arguing that the technology and tactics that beat the DHS keep moving into ordinary civic organizing. That forward-looking 'what's next, and what it costs or brings' is this standard's own territory.

#9-12S.IC.29

Access to computing resources isn't handed out evenly, and naming who actually benefits versus who's left out is the equity question here.

  • Little Brother (a book by Cory Doctorow): not covered
    Checked and not a match -- easy to confuse with this carrier's own castandards 9-12.IC.29 entry (arphid and camera tracking), which is the core-tier code about data collected without consent. This specialty-tier code is a different concept, unequal access to computing resources, which the book doesn't take up as its own theme.

#9-12S.IC.30

Real laws and regulations -- net neutrality is the classic case -- shape what software even gets built, and arguing both sides of that is the point.

  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 17 (Barbara Stratford and the Crypto Wars)
    Two real-law examples, not a hypothetical: PATRIOT Act II's transaction-monitoring provisions are specific enough that the Turk stops taking debit cards over it (6), and Chapter 17's Crypto Wars history is a real law -- crypto classified as a munition, illegal to export -- that shaped what software Americans were allowed to write and publish, until a court fight overturned it. Both sides of the argument (security necessity versus overreach) get real airtime, as the standard asks for.

#NI Networks & the Internet

6-8

#6-8.NI.4

Protocols are the agreed-upon rules that let messages actually get where they're going across a network, quickly and with errors handled.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 2 (Unit 2: The Internet)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 2-NI-04)
  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 17 (Barbara Stratford and the Crypto Wars)
    This carrier's own inference, mirroring 9-12.NI.5 above: Xnet's mesh (6) and DNS tunneling (17) are messages getting where they're going across a network that wasn't built to carry them that way.

#6-8.NI.5

Every network faces real security threats, and different threats call for different countermeasures.

  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 7 (Hiding in Plain Ciphertext), Chapter 8 (The Paradox of the False Positive), Chapter 9 (Suspicion Spreads, Even to Dad), Chapter 10 (A Beach Key-Signing Party), Chapter 17 (Barbara Stratford and the Crypto Wars)
    This carrier's own inference, mirroring 9-12.NI.6 above: the same crypto-and-countermeasures arc, at the lighter 'different threats call for different countermeasures' framing this 6-8 standard uses.
  • Student Movies: Unit sneakers (Sneakers), Unit wargames (WarGames) (partial)
    Network threats and countermeasures.

#6-8.NI.6

Sending information securely usually takes more than one protective method working together, not a single fix.

  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 10 (A Beach Key-Signing Party)
    This carrier's own inference, mirroring 9-12.NI.7 above: sending information securely in the book always takes more than one protective method working together -- crypto plus anonymity plus the web of trust, not any single fix.
  • Student Movies: Unit sneakers (Sneakers) (related)
    Layers of protection.
  • CS Unplugged: Caesar Cipher (partial)
    The California version of CSTA 2-NI-06 (apply encryption methods to model secure transmission). Caesar Cipher is one simple method, encrypted, decrypted, and cracked; public-key encryption isn't modeled.
9-12

#9-12.NI.4

Networks have to satisfy real performance demands -- latency, bandwidth, throughput -- for the organizations that depend on them.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 2 (Unit 2: The Internet)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3B-NI-03)

#9-12.NI.5

The internet's design, including how it looks up addresses and routes traffic, is what lets it scale and stay reliable.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 2 (Unit 2: The Internet)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: strong) -- not independently checked against a code.org source document. (from 3A-NI-04)
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 8 (Week 8: HTML, CSS, JavaScript)
    DNS plus routing (named week-8 topics) is literally 'how the internet looks up addresses and routes traffic.'
  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 17 (Barbara Stratford and the Crypto Wars)
    Xnet's mesh distribution over sneakernet and borrowed internet connections (6), and DNS tunneling as a way around normal routing (17), are the internet's own addressing and routing being bent without breaking.
  • MicroPython on Pi Pico and Projects: Chapter 11 (Wi-Fi connectivity) (partial)
    The lesson touches on IP addressing when connecting to Wi-Fi and reaching a server by its address, but doesn't get into how the internet's own routing and lookup infrastructure lets that scale.

#9-12.NI.6

Different security threats call for different defenses, and choosing between them is a tradeoff, not a solved problem.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: partial) -- not independently checked against a code.org source document. (from 3A-NI-06 and 3A-NI-07, both compressed into this one CA standard)
  • Harvard's CS50AP (Weeks 0, 3, 7-9): Unit 7 (Week 7: SQL)
    SQL Injection Attacks, a named topic, is a concrete security threat calling for a specific defense (parameterized queries).
  • CS50 Problems: Unit 5 (Caesar)
    Caesar's own cipher, and why a small keyspace makes it breakable, is a direct case study for this standard.
  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 7 (Hiding in Plain Ciphertext), Chapter 8 (The Paradox of the False Positive), Chapter 9 (Suspicion Spreads, Even to Dad), Chapter 10 (A Beach Key-Signing Party), Chapter 17 (Barbara Stratford and the Crypto Wars)
    The whole crypto-and-countermeasures arc, from the first ParanoidXbox/ParanoidLinux defenses (6) through the DHS's exploits against them (9) to the Crypto Wars material (17), is choosing between security threats and defenses as a real tradeoff, not a solved problem.

#9-12.NI.7

Cryptographic techniques protect data in transit, and symmetric and asymmetric approaches trade off differently for cost and use case.

  • Code.org's AP CSP (Units 1,2,5,8,10): Unit 10 (Unit 10: Cybersecurity and Global Impacts)
    Mechanically derived from this carrier's own csta2017 entry for this unit via the castandards-csta2017 crosswalk (strength: related) -- not independently checked against a code.org source document. (from 3A-NI-05)
  • Harvard's CS50AP (C Language Content) (Weeks 1-6): Unit 2 (Week 2: Arrays)
    Cryptography, a named week-2 topic (Caesar and Vigenère ciphers in the problem set), is a symmetric-key technique for protecting data.
  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 10 (A Beach Key-Signing Party)
    Chapter 6's prime-factorization explanation of public-key crypto and Chapter 10's formal definition of a private key are cryptographic techniques for protecting data in transit, including the asymmetric case CA's own paraphrase calls out.
  • CS Unplugged: Caesar Cipher (related)
    Caesar Cipher is a simple symmetric cipher: one shared key both scrambles and unscrambles. It doesn't reach asymmetric encryption or the tradeoffs the standard asks about.
9-12 Specialty

#9-12S.NI.3

A network's addressing scheme and its mix of routers, switches, and servers together determine how well it scales and how reliably traffic actually arrives.

  • Little Brother (a book by Cory Doctorow): Chapter 17 (Barbara Stratford and the Crypto Wars)
    Chapter 17's DNS explainer walks through exactly this: how a name like pirateparty.org.se resolves to a number like 204.11.50.136, and how the shift from one central HOSTS file to millions of talking DNS servers is what let addressing keep scaling and stay reliable as the network grew.

#9-12S.NI.4

The internet scales and keeps growing because of design choices baked into it from the start -- redundancy, open standards, and pushing key functions out to the endpoints rather than the middle of the network.

  • Little Brother (a book by Cory Doctorow): Chapter 17 (Barbara Stratford and the Crypto Wars)
    The same chapter makes the design-philosophy point directly: DNS used to be a single file that lived under one person's desk at USC, and moving to a distributed, redundant, open-standard system of servers that all talk to each other is why a single unplugged machine no longer takes down the whole internet's ability to find itself.

#9-12S.NI.5

Defending against a security threat means weighing real tradeoffs, like a password policy that's easier to use against the cost of it being easier to break.

  • Little Brother (a book by Cory Doctorow): Chapter 6 (Building Xnet, Learning Crypto), Chapter 7 (Hiding in Plain Ciphertext) (partial)
    Not the standard's own password-policy example, but the same shape of tradeoff: Jolu spells it out plainly in Chapter 7 -- too much crypto in your traffic makes you stand out as a target, too little makes you easy to wiretap -- and Chapter 6 grounds why that crypto has a real cost (compute, key management) in the first place.

#9-12S.NI.6

Cryptography, plus the certificate authorities that vouch for who owns an encryption key, is what actually secures a connection across the open internet.

  • Little Brother (a book by Cory Doctorow): Chapter 10 (A Beach Key-Signing Party), Chapter 11 (Growing the Web of Trust)
    The web of trust that Chapter 10 explains and Chapter 11's key-signing party puts into practice is a real, working alternative to certificate authorities for exactly the problem this standard names -- vouching for who actually owns a given key -- built person-to-person instead of through a central authority.