CSTA 2026 Standards Reference
#T-CODE to this page's URL.
#Algorithms & Design (11 standards)
#HS-ALG-PS-01
Solving a problem well often means choosing the right data structure to go with the algorithm, not just writing steps in isolation.
The focus is picking and using structures a language already provides (like a list or a class) to support the plan, not implementing custom structures from scratch -- a leaderboard built on a list plus a sort is the kind of example this covers.
#HS-ALG-PS-02
An algorithm can be reworked to run more clearly or efficiently by wrapping repeated steps in a function and using loops or conditionals instead of restating logic.
This is about restructuring code with existing constructs like functions and loops, not formal efficiency analysis or advanced recursive optimization.
Alignment: chap03 wraps repeated print statements in repeat/print_verse and introduces the for loop, matching this standard's function-plus-loop-instead-of-restated-logic framing. chap04's Refactoring section is the chapter's own named term for exactly this. chap05's logical-operators-instead-of-nested-conditionals rewrite is the conditional half of the same idea. chap07's has_e progression (inline loop → function → boolean return) is another instance, headers only. Optimizing for efficiency, the standard's other half, isn't addressed anywhere.
#HS-ALG-PS-03
Comparing two algorithms for the same job means checking more than just whether they work -- how fast they run and how easy they are to read matter too.
Comparisons can be informal or based on test runs rather than a formal proof of running time.
#HS-ALG-PS-04
An algorithm that always gives the same result from the same input behaves differently from one that leans on randomness and can vary run to run.
Explaining the distinction in plain terms is enough; formal probability calculations aren't expected.
#HS-ALG-PS-05
Content that comes out of an AI tool -- text, an image, even code -- deserves a critical look for whether it's accurate, skewed, or capable of causing harm.
The judgment call is about the output itself, not about understanding how the model that produced it works internally.
#HS-ALG-ML-06
Picking one kind of AI approach over another for a task is a decision that should be defended, weighing things like how much data there is and how easy the result is for a person to interpret.
The point is arguing for a choice between approaches, not building or deriving the math behind them.
#HS-ALG-ML-07
Before trusting a dataset, it's worth asking where it came from, how complete and accurate it is, whether it represents everyone it should, and whether using it raises privacy concerns.
This is a critical-eyes evaluation, not a statistical proof of bias or a formal correction procedure.
#HS-ALG-ML-08
Building a working machine-learning model for a specific job means choosing suitable data and tools, training it, and checking whether it actually performs the task.
Using an existing tool or simple library to build and test the model is the expectation, not writing the learning algorithm from scratch.
#HS-ALG-IM-09
Designing something so that it's genuinely usable by a wide range of people means researching what those people need and thinking ahead about a design's social and ethical side effects.
Considering accessibility law and practical inclusive-design choices (contrast, navigation, plain language) is the expectation, not meeting every clause of a formal accessibility standard.
#HS-ALG-IM-10
Both an algorithm built from explicit rules and one trained on data can end up treating people unfairly, and tracing where that unfairness comes from is part of evaluating it responsibly.
The analysis stays conceptual -- recognizing patterns of bias and suggesting fixes -- rather than auditing a real company's system or running statistics on it.
#HS-ALG-IM-11
Every algorithmic system's design quietly favors some outcomes over others, and naming which values -- efficiency, privacy, fairness -- got prioritized is part of understanding it.
The goal is identifying the priorities baked into a design, not reverse-engineering a real company's business model.
#Programming (9 standards)
#HS-PRO-PD-12
Splitting a program into distinct, well-organized pieces -- functions, imported libraries, or objects -- makes the result easier to read and easier to reuse.
Straightforward decomposition is the target; elaborate design patterns or deep class hierarchies aren't expected.
Alignment: chap03's function definitions -- especially building print_verse out of first_two_lines/last_three_lines/repeat -- directly match splitting a program into reusable, readable pieces. chap04's encapsulation/generalization/refactoring sequence (square → polygon → polyline, then circle → arc → polyline) is a stronger instance of the same standard. chap07's uses_none = not uses_any(...) and the exercises deriving uses_all from uses_only/uses_any (instead of a new loop) extend it again.
#HS-PRO-PD-13
Good program development leans on outside resources -- reference docs, existing libraries, simple APIs, and the features built into a development environment -- rather than reinventing everything from scratch.
Using these resources well is the goal, not building new ones.
Alignment: chap02's `import math` and its use of math.pi/math.sqrt/math.pow is this book's first real use of an existing library. chap04 (jupyturtle), chap07 (`from doctest import run_docstring_examples`), and chap08 (`re`) are secondary instances of the same pattern -- genuine but not new information each time, so headers only. The rest of this standard -- API docs, IDE features -- isn't addressed anywhere.
#HS-PRO-PD-14
Anything borrowed from someone else -- code, art, sound -- needs to be credited according to whatever terms it was shared under.
Practicing honest attribution is the point, not mastering copyright law itself.
#HS-PRO-PD-15
Working on a program as a team goes better with some structure -- assigned roles, a shared design document, and a way to track who changed what.
Classroom-scale tools and practices are the expectation, not professional-grade project management.
#HS-PRO-VD-16
Choosing the right structure -- a list, a dictionary -- to hold a program's data is what makes storing, retrieving, and changing that data manageable.
Common built-in structures are the scope here; things like linked lists, trees, and graphs are not.
#HS-PRO-RD-17
Reading someone else's code well means being able to explain what each moving part does -- a variable holding state, a loop repeating until some condition, a conditional branching on it -- and how those parts cooperate.
This is about tracing a manageable segment of code, not untangling a large system with many interacting structures.
Alignment: chap03's stack diagrams and tracebacks explain what a function's parameters and loop are doing, but conditionals (the standard's third element) don't appear until chapter 5 -- partial there. chap05's countdown stack trace and chap07's predict-the-output prompts (total, count, which doctest fails) complete the triad: a variable holding state, a loop or conditional, and how they cooperate. chap06's factorial trace and chap08's file-reading loop (a state variable, a loop repeating on a condition, a conditional branching on it) are further worked instances of the same standard.
#HS-PRO-RD-18
Code that an AI tool produces still has to be tested against what it was actually supposed to do, including checking that it holds up on tricky or edge-case inputs.
The task is testing and judging the output, not understanding the model that generated it.
#HS-PRO-TR-19
Finishing a program includes checking it against its own original plan -- does it work correctly, does it do what it was meant to, and is it actually pleasant and accessible to use.
This is a self- or peer-review against the project's own stated goals, not a formal verification process or industry tooling.
#HS-PRO-TR-20
Feedback and test results should actually change the program -- tightening up usability, accessibility, or accuracy -- even if not every issue gets fixed at once.
Meaningful, partial improvement is the expectation, not chasing full optimization or fixing every possible issue.
#Data & Analysis (8 standards)
#HS-DAT-DC-21
A simulation often needs input data that doesn't exist yet, and a simple program or spreadsheet formula can manufacture data meeting whatever constraints the simulation calls for.
Producing the data that feeds into an existing simulation is the task, not building the simulation itself.
#HS-DAT-DC-22
A data dictionary spells out, for every column in a dataset, its name, its type, and the values it's allowed to hold -- plus how columns depend on each other, like a skipped survey question leaving a related answer blank.
Documenting an existing dataset this way is the task; building the dataset, or handling huge or specialized data, is not.
#HS-DAT-DC-23
Messy text data -- inconsistent capitalization, typos, a name and a date crammed into one field -- usually needs cleanup before it's useful, and a spreadsheet or short script can do that work.
Recognizing where a pattern-matching tool like a regular expression would help is part of this; building a cleaning tool from scratch, or handling huge unstructured feeds, is not.
Alignment: chap08's is_special_line (stripping Gutenberg header/footer cruft) and re.sub-based British-to-American spelling normalization are direct instances of cleaning up messy text data with a pattern-matching tool -- close to a literal match for this standard's own scope note.
#HS-DAT-DC-24
There's more than one way to check that a dataset's values are the right type and fall in a sensible range, and weighing those approaches against each other is its own skill.
Comparing validation approaches conceptually is the expectation; writing the validation code or using statistical models is not.
#HS-DAT-DI-25
Turning a dataset with several variables into a chart -- a scatter plot, a stacked bar chart -- is how a question about that data gets answered visually.
Using existing tools like spreadsheets to build the visualization is the expectation, not writing code to generate it or running formal statistics.
#HS-DAT-DI-26
A chart or simulation someone else built can still mislead -- a truncated axis, a biased sample -- and spotting those limits is as important as reading the result itself.
Critiquing an existing data product is the task, not building one or fixing the code behind it.
#HS-DAT-IM-27
Collecting and processing data at scale carries real costs beyond the technical -- consent, who owns the data, bias baked into it, misinformation, even the environmental footprint of the data centers running it.
The analysis is conceptual, not a formal legal or economic study of data policy.
#HS-DAT-IM-28
Whether an existing data-privacy law or policy actually works is a debatable question, and building an argument on either side -- including whether public pressure or behavior change might work better than a new law -- is the point.
Debating the policy's effectiveness is the expectation; reading the actual legal text is not.
#Systems & Security (9 standards)
#HS-SYS-HW-29
An operating system stands apart from ordinary software because its job is managing the machine itself -- memory, storage, whatever's plugged in -- so other programs can just run.
Describing that role is the goal, not learning how an operating system is actually coded or configuring its internals.
#HS-SYS-HW-30
Putting a real device to work on some everyday task also means noticing what it can't do -- battery life, screen size, and other limits that come with the choice.
Using a device thoughtfully is the expectation, not building one or writing code that controls its hardware directly.
#HS-SYS-SE-31
Every security measure protects something at some cost -- multifactor login guards an account but makes it slower to get into -- and naming that trade-off is part of understanding security.
Recognizing these trade-offs conceptually is the goal, not implementing the security measures.
#HS-SYS-SE-32
The same security breach can hit different groups in different ways -- a person's identity, a company's finances, a whole community's trust in a system -- and sorting out who's affected and how is more than just listing consequences.
This is broad-impact analysis, not a forensic investigation or professional-grade tooling.
#HS-SYS-SE-33
Given a described security weakness, proposing a fix means naming the vulnerability, what could go wrong because of it, and concrete steps -- technical and non-technical -- to close the gap.
Proposing the fix is the task; actually building it is not.
#HS-SYS-NT-34
A network diagram shows both the physical pieces -- servers, routers, devices -- and the software running on them, and how all of it connects to get work done.
Drawing the diagram is the task, not physically building the network.
#HS-SYS-NT-35
The internet is really a network stitched together out of many smaller networks, with its own layered structure, hardware like routers, and protocols like TCP/IP tying it together -- which sets it apart from something like a single classroom network.
A high-level, conceptual grasp is the goal, not configuring real equipment or analyzing network traffic.
#HS-SYS-IM-36
Laws and policies about how computing systems get built and used usually exist for a reason -- technical, legal, or social -- and explaining that reasoning matters more than reciting the rule.
Understanding why a policy exists is the point; reading the legal text itself is not.
#HS-SYS-IM-37
Computing infrastructure has a physical life cycle -- energy-hungry data centers, e-waste, supply chains -- and those costs don't land on everyone equally, which makes asking who's affected and why part of the investigation.
Researching and explaining the impact is the task, not proposing a technical fix for it.
#Computing & Society (9 standards)
#HS-SOC-HI-38
Tracing a technology's history from its start to now usually turns up moments where forces outside the technology itself -- economics, culture, politics -- pushed its design or adoption in a particular direction.
Working from reliable secondary sources is the expectation, not original historical research or deep economic modeling.
#HS-SOC-HI-39
A privacy law or a rule about algorithmic transparency exists to head off some specific harm, and being able to explain that reasoning is what this is really about.
Explaining the reasoning behind a policy is the point, not drafting legal language or mastering the lawmaking process.
#HS-SOC-ET-40
An emerging technology usually does something genuinely different under the hood, and that difference is what lets it do new things or get past an old limitation.
How deep the technical explanation goes depends on the topic and the students -- the underlying advanced theory isn't required.
#HS-SOC-ET-41
A new technology's upside rarely lands evenly -- weighing its benefits against its costs means asking who gets left out of the access or the outcomes.
A reasoned, conceptual argument is the goal, not a formal data-driven study.
#HS-SOC-ET-42
Sketching out how an emerging technology could tackle a real problem means backing the idea with real research and being honest about who might be helped or harmed by it.
A design document grounded in research is the deliverable, not a working, production-ready build.
#HS-SOC-HU-43
The people behind a computing system -- the ones who chose its data, tuned it, decided how it gets used -- make choices that carry their own risks and benefits down the line.
Tracing those human choices and their consequences is the focus, not building or mathematically analyzing the underlying model.
#HS-SOC-HU-44
Whether an AI system could ever be intelligent the way a person is opens real philosophical questions about consciousness and who's responsible for what it does.
This is a debate about ideas, not an exploration of neuroscience or a specific model's architecture.
#HS-SOC-CE-45
Looking at how real, varied computing professionals actually work -- the problems they run into, the barriers they've navigated -- connects computational thinking back to the people who practice it.
Analyzing existing public accounts (an interview, a podcast) is the expectation, not conducting original interviews.
#HS-SOC-CE-46
What a student has learned in computing can be weighed against their own interests and where they might want to go next, without needing to settle on a final answer.
Reflecting on the connection is the task; committing to a specific career path is not.