CA CS Standards Reference

#9-12.AP.12

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

Covered in 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.

Covered in 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.

Covered in 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.

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.

Covered in 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.

Covered in 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.

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.

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.

Covered in 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.

#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.

Covered in 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.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.

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.

Not covered

Not covered. Same status as CS.1 -- a hardware/systems topic outside this book's scope.

#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.

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.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.

Covered in 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.

Covered in 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.

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.

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.IC.23

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

#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.

#9-12.IC.25

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

#9-12.IC.26

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

#9-12.IC.27

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

#9-12.IC.28

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

#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.

#9-12.IC.30

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

#9-12.NI.4

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

#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.

#9-12.NI.6

Different security threats call for different defenses, and choosing between them is a 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.