CA CS Standards Reference

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

#6-8.AP.12

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

#6-8.AP.13

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

#6-8.AP.14

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

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

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

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

#6-8.AP.19

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

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

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

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

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

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.

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

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

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

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

Covered in Chapter 2 (Variables and Statements), Chapter 4 (Functions and Interfaces), Chapter 8 (Strings and Regular Expressions)

Same evidence as this file's core 9-12.AP.17 and csta2026 HS-PRO-PD-13 entries: Chapter 2's import math, Chapter 4's jupyturtle, and Chapter 8's re are all cases of reaching for an existing, well-tested library instead of reimplementing its functionality.

#9-12S.AP.19

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

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

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.

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

Covered in Interlude A (Docstrings and Doctests), Chapter 7 (Iteration and Search)

Same evidence as this file's new csta2026 S1-SWD-TR-07 entry: Interlude A's Choosing test cases table (typical, boundary, edge) is close to a literal match for 'ordinary behavior and the edge cases at the boundary.'

#9-12S.AP.23

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

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.

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

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.

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

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

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

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.

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.

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

#6-8.DA.8

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

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

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

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

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.

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.

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

#6-8.IC.22

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

#6-8.IC.23

A license is a tradeoff between protecting a creator's rights and letting other people use and modify their 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.

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

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

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

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

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

#6-8.NI.5

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

#6-8.NI.6

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

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

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

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

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

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