CA CS Standards Reference
#AP Algorithms & Programming
#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.
#9-12.AP.13
Once a problem needs more than a handful of related values, a collection replaces a pile of separately named variables.
#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.
#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.
#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.
#9-12.AP.17
A program built from separate, interacting pieces -- including code someone else wrote -- is organized by modular design.
#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.
#9-12.AP.19
Using someone else's library or code comes with license terms that limit what you can do with it.
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#9-12S.AP.23
Adding functionality to existing code means also tracking down what that change might break elsewhere, intended or not.
#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.
#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.
#CS Computing Systems
#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.
#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.
#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.
#9-12S.CS.2
An operating system's separate jobs -- managing memory, storage, running processes, controlling access -- can each be named and told apart.
#DA Data & Analysis
#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.
#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.
#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.
#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.
#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.
#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.
#IC Impacts of Computing
#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.
#NI Networks & the Internet
#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.