CA CS Standards Reference
#S-CODE to this page's URL.
#Computing Systems
#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. 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. 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.
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.
#Networks & the Internet
#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.
#Data & Analysis
#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.
Same underlying content as AP DAT-1.A (data represented using bits). Taught in CS50T Multimedia, same as that AP topic.
#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.
The CED's own worked example for this standard is file-size-vs-quality tradeoffs across image formats — the same territory as AP DAT-1.D (data compression). Taught in CS50T Multimedia.
#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.
Real gap: the book has no plotting/visualization content anywhere (no charting library is used in chapters 1-13). chap12'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. chap12'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.
#Algorithms & Programming
#9-12.AP.12
Solving a computational problem often means combining an algorithm you already know with one you design yourself.
chap07 develops a linear-search algorithm from scratch; chap09'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.
Direct match to chap09 (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.
Strong match: the CED's own worked example here is comparing iterative vs. recursive Fibonacci — and chap06 has a "Fibonacci" section built on chap05's recursion material. The book only ever demonstrates the recursive side, so the iterative half of this comparison is thinner than the recursive half (no while loop anywhere in the book).
#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.
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.
chap03/chap04'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, 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.
Same evidence as AP AAP-3.D (Libraries): chap02 introduces import, chap04 (jupyturtle) and chap08 (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.
chap04'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. Same gap as AP CRD-2.H (acknowledging code from other sources) — the book never discusses licensing or attribution of borrowed code, even though chap04/chap08 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.
chap04's development plan and chap07'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.
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.
chap04'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.
#Impacts of Computing
#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.