CSTA 2026 Standards Reference
Algorithms & Design
#MS-ALG-PS-01
An algorithm can hold onto more than one kind of information at once -- a number, a name, a yes/no flag -- and using several data types together is what lets it actually solve a problem or express an idea.
The expectation is designing and explaining the logic in words, a diagram, or pseudocode, not writing a program that runs, managing memory, or building data structures like lists or dictionaries.
#MS-ALG-PS-02
A flowchart or pseudocode can model someone else's algorithm, showing not just the sequence and branching but where a reusable, named procedure fits into it.
Modeling a given algorithm is the task -- designing or optimizing one, or converting the model into runnable code, isn't expected.
#MS-ALG-PS-03
Checking whether an algorithm actually gives the right answer means tracing it, or running it, against specific inputs and comparing the result to what was expected.
This is testing against sample inputs, not a formal proof of correctness or an efficiency comparison between algorithms.
#MS-ALG-PS-04
Some problems are best solved with a fixed set of steps, some by following rules, and some by learning from data -- and picking the right one, or combining them, is a choice worth defending.
Reasoning about which approach fits and why is the point, not implementing any of the approaches.
#MS-ALG-PS-05
An AI tool -- a chatbot, an image classifier -- can generate something that helps solve a computational problem, and using it well means judging what it produces rather than just accepting it.
Using and evaluating an existing AI tool's output is the expectation; training a model or explaining how one works internally is not.
#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.
#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.
#MS-ALG-IM-09
A familiar app or website can be checked against human-centered design principles -- empathy, accessibility, fairness -- to see which ones it actually lives up to.
Analyzing an existing technology, and suggesting improvements, is the task; designing or building a full technology from scratch is not.
#MS-ALG-IM-10
Everyday tools -- a photo app, a voice assistant, a recommendation feed -- carry their own ethical issues and biases, and noticing them in familiar, concrete examples is the starting point for evaluating computing responsibly.
Identifying and explaining bias in plain terms is the goal; understanding neural networks or studying formal AI policy is not.
#MS-ALG-IM-11
An existing algorithm can be reworked -- adding a language option, diversifying a playlist generator -- specifically to make its outcomes fairer or more inclusive.
Proposing a conceptual modification, verbally or as a diagram, is the expectation, not designing a complex algorithm from scratch or applying formal fairness statistics.
#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.
#MS-ALG-ML-06
Watching what goes into a machine learning model and what comes out of it is enough to form a reasonable, evidence-based guess about how it's making its classifications or predictions.
Forming a hypothesis from observed behavior is the task; explaining the model's internal workings is not.
#MS-ALG-ML-07
A machine learning model gets more accurate and less biased when the examples it's trained on are examined and improved -- adding what's missing, fixing what's overrepresented.
This stays a conceptual, testing-and-suggesting exercise; students aren't expected to build a model or actually retrain one themselves.
#MS-ALG-ML-08
A model card or similar documentation spells out what a machine learning model is actually good for and where it falls short -- its training data, its intended use, its risks -- and reading that critically is its own skill.
Reviewing documentation and observed behavior is the expectation; building a model or accessing proprietary training data is not.
#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.
Artificial Intelligence
#S1-AIN-DS-06
Tracing a single number as it moves through one neuron -- multiplied by a weight, shifted by a bias, squeezed through an activation function -- is how a neural network's layers actually transform an input into an output.
Conceptually tracing and diagramming that flow is the expectation; implementing a network or deriving the math behind backpropagation is not.
#S1-AIN-DS-07
Getting a raw dataset ready for a model -- pulling it from a CSV or API, fixing missing values, converting fields into machine-readable form, splitting it into training and testing sets -- is hands-on prep work, not an afterthought.
Working through this pipeline on a manageable dataset with existing tools is the scope; large-scale or distributed data infrastructure and building preprocessing algorithms from scratch are not expected.
#S2-AIN-DS-04
Checking a dataset's metadata -- when it was collected, what demographics it covers -- can reveal a gap that should change which model gets picked or where it's allowed to be deployed.
Critiquing a data pipeline to justify a model or deployment decision is the task; designing algorithmic fairness metrics is not expected.
#S2-AIN-DS-05
Getting a mixed dataset ready for a specific algorithm -- scaling numeric columns, one-hot encoding categorical ones -- is what makes it actually usable by something like a nearest-neighbor classifier.
Applying standard transformation techniques for a target algorithm is the scope; implementing dimensionality reduction techniques is not expected.
#S1-AIN-DD-01
Distinguishing generative AI (making new content, like a chatbot or image creator) from discriminative AI (sorting or labeling existing content, like an image classifier) is about seeing which real-world problems each is actually suited to.
Comparing categories of AI systems and their applications is the task; judging how well a system performs, or building or training one, is not expected.
#S1-AIN-DD-02
Reworking what data a model trains on -- adding examples of an underrepresented group to a facial-recognition dataset -- can visibly change how fair or accurate its output is, without touching the model itself.
Making simple, iterative changes to training data and keeping what improves results is the scope; the math behind fairness metrics is not expected.
#S1-AIN-DD-03
A pretrained model -- an image classifier pulled from a library -- can be wired into a simple app that takes a photo upload and hands back a prediction, without writing the model itself.
Integrating an existing model into a working application is the task; training a model from raw data or building production-grade software is not.
#S1-AIN-DD-04
The shape data comes in -- a table, a graph, an image, a sequence of text -- limits which kinds of algorithms can actually be applied to it.
Comparing given representation types and naming which algorithms fit is the scope; inventing new representations or proving the limits mathematically is not expected.
#S1-AIN-DD-05
Choosing AI over a simpler, rule-based approach for a real problem -- like sorting defective parts by photo versus checking pixel color ranges -- should hinge on things like data availability, interpretability, and computing resources, not a default assumption that AI is better.
Weighing the tradeoffs between an AI and a non-AI approach is the task; building either solution, or producing detailed cost estimates, is not expected.
#S2-AIN-DD-01
Problems without labeled answers -- grouping customers, spotting anomalies, finding hidden patterns in a big dataset -- are exactly where unsupervised learning fits, and recognizing that fit is the skill.
Matching problem characteristics to unsupervised learning is the task; implementing the algorithms or proving their mathematical convergence is not.
#S2-AIN-DD-02
Actually reaching into an existing model's controls -- how deep a decision tree grows, how a generative system samples -- and tuning them for a specific problem is optimization, not just picking a preset tool.
Hands-on tuning of an existing algorithm's parameters or structure is the scope; building an algorithm from scratch or using advanced automated tuning methods is not expected.
#S2-AIN-DD-03
Building something like a home-price predictor means choosing a more sophisticated model -- a random forest, a neural network -- preparing labeled data for it, training it, and wiring the result into an app that takes input and returns a prediction.
Working end-to-end with a more advanced but standard model type is the scope; designing or implementing deep learning architectures is not expected.
#S1-AIN-HR-08
Designing a safe AI workflow -- like a medical AI that only recommends a diagnosis while a doctor still makes the final, auditable call -- means building in a real human checkpoint, not just a privacy disclaimer.
Planning practical safeguards for a given scenario is the task; formally proving an AI system is safe is not expected.
#S1-AIN-HR-09
Comparing how a model performs across different groups of people -- and being willing to turn that same lens on a system students built themselves, not just ones made by others -- is how bias baked into training data or design surfaces.
Investigating bias with available metrics on accessible systems, including their own, is the scope; inventing new bias-detection methods or reaching into proprietary industry models and data is not.
#S1-AIN-HR-10
Training and running AI costs real energy and water, and those costs, along with the e-waste they generate, tend to land harder on some communities and regions than others.
Comparing known impacts, like a large model's emissions against a small model running on a local device, is the task; a full life-cycle hardware assessment is not expected.
#S2-AIN-HR-06
Writing a policy that forces high-risk AI uses -- hiring, criminal justice -- to disclose their training data, model type, and bias testing is really about balancing openness against competing interests like privacy and innovation.
Drafting and justifying a specific, reasoned policy is the task; citing real statutes or building the technical infrastructure to support it is not expected.
#S2-AIN-HR-07
Optimizing a model for one measure -- like high recall on a loan-approval model -- can create real fairness problems along a different measure, like precision, and seeing that tension is the point.
Reasoning through the tradeoffs in a described scenario is the scope; writing code or calculating the metrics is not expected.
#S1-AIN-PP-11
An off-the-shelf AI agent -- a web-search bot, a customer-support bot -- can be dropped into an application to handle a specific task without anyone building the agent from scratch.
Using an existing agent template to accomplish a task is the scope; designing or training a new agent is not.
#S1-AIN-PP-12
The same AI tool -- a voice assistant, a recommendation feed -- can behave noticeably differently depending on a user's accent, language, or background, and tracing that back to training data or design choices is the analysis.
Explaining observed differences in outputs across users is the scope; designing formal user-experience studies or building adaptive personalization systems is not expected.
#S1-AIN-PP-13
Whether it's fair for a company to train a model on copyrighted art or scraped personal data without asking first is a real, debatable tension between creators' rights and how AI models actually get built.
Debating the practice with general arguments about fair use and consent is the task; citing specific legislation or case law is not expected.
#S1-AIN-PP-14
The ethical worries around AI have shifted over time -- from fictional guardrails like Asimov's Three Laws and bugs in rule-based systems, to today's concerns about bias and transparency -- and spotting that shift, plus guessing what comes next, is the point.
Comparing past and present concerns and speculating informally about the future is the scope; researching AI's development trajectory in depth or rigorously defining consciousness is not expected.
#S2-AIN-PP-08
Building a working AI agent means giving it a clear goal, deciding what information it can draw on, defining how it responds and acts, then testing it against realistic prompts to refine it.
Building and optimizing with an accessible tool is the scope; building a custom underlying model is not expected.
#S2-AIN-PP-09
The same AI results -- an F1-score, a bias finding -- need to be reframed differently depending on the audience, like a school board that cares about cost and a community group that cares about fairness and appeals.
Translating technical results for specific named audiences is the task; producing publication-quality media or running a real communications campaign is not expected.
#S2-AIN-PP-10
Comparing how the EU's AI Act treats "high-risk" systems against a looser US approach is a way to argue the real tradeoff between faster innovation and stronger human protections.
Debating regulatory philosophies and their practical effects is the scope; reading the actual legislative text is not expected.
Computing & Society
#MS-SOC-CE-44
The same computational thinking moves -- breaking a problem down, spotting a pattern, abstracting a solution -- that students use while coding show up in how professionals in very different fields actually solve problems.
Drawing that parallel through described examples is the scope; specialized programming frameworks or domain-specific simulations are not expected.
#MS-SOC-CE-45
Automation -- robotics, AI, machine learning -- reshapes work by making some tasks faster or safer while displacing or changing others, and weighing those tradeoffs is part of understanding its impact.
Exploring examples of both benefit and disruption is the goal; designing automated systems or doing formal economic or labor-market analysis is not.
#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.
#MS-SOC-ET-40
An emerging technology like AI, robotics, or quantum computing is only worth using on a given problem if its actual capabilities, reliability, and environmental cost make sense for that problem right now.
Judging appropriateness from known capabilities and limits is the task; explaining the underlying mechanics or predicting future breakthroughs is not.
#MS-SOC-ET-41
The design choices behind a new technology -- what languages it supports, what it costs, what connectivity it assumes -- create real benefits for some communities and real barriers for others.
Evaluating examples through one or more of those factors is the scope; formal usability studies or building prototypes are not.
#MS-SOC-ET-42
Whether an emerging technology helps or harms a local community is a genuinely debatable question, and building an argued, evidence-backed case for one side is the point.
A researched debate on a specific technology's community impact is the task; deep technical understanding of the technology itself is not required.
#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.
#MS-SOC-HI-38
Individuals, communities, companies, and governments have all shaped computing technology differently across its history -- designing it, funding it, regulating it, using it -- and they often influenced or worked with each other.
Comparing these roles with described examples is the task; memorizing timelines or ranking groups by importance is not.
#MS-SOC-HI-39
A computing technology's original purpose and its actual, unintended effects on society and the environment -- on communication, jobs, privacy, e-waste, energy use -- are two different things worth tracing separately.
Simple cause-and-effect connections are the expectation; formal cost-benefit analysis or predicting future technology is not.
#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.
#MS-SOC-HU-43
It's the human decisions behind a computing system -- what data got collected, which algorithm got used, how results got interpreted -- that actually create its ethical and social consequences, not the technology by itself.
Tracing those human choices to their effects, and proposing more responsible alternatives, is the task; philosophical debates about AI consciousness or rights are not.
#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.
Cybersecurity
#S1-CYB-CP-11
Cybersecurity policy exists because technical controls alone don't stop people from doing risky things -- rules like acceptable-use or password policies translate legal and ethical expectations into behavior an organization can actually enforce.
Explaining why policies exist and naming common categories is the target; writing an actual policy or judging a real organization's legal compliance is not.
#S1-CYB-CP-12
A good policy spells out who it covers, what's allowed, who enforces it, and what happens when someone breaks it -- and those pieces working together are what actually shapes how people behave.
Explaining what makes a policy's structure effective is the scope; drafting a complete organizational policy or assessing legal compliance is not.
#S2-CYB-CP-09
Some regulations dictate exact controls to install, while others just set an outcome and leave the method open -- debating which style serves an organization's security and its users' rights better is the real question here.
Debating how regulatory approaches shape practice and trade-offs is the target; interpreting actual legal text or drafting regulatory guidance is not.
#S1-CYB-NO-05
Tools like ping or traceroute -- or their simulated equivalents -- can turn a vague 'the network is broken' into evidence about which layer is failing and whether the cause looks routine or suspicious.
Interpreting diagnostic output and connecting it to a layer is the scope; scripting your own diagnostics, monitoring live traffic, or actually fixing the problem is not.
#S1-CYB-NO-06
Logs exist so someone can look back and notice trouble -- a string of failed logins, a process that shouldn't be running -- and reading them well means spotting the warning sign and suggesting a reasonable response, not just running the command.
Working from instructor-provided logs or screenshots, or read-only tools in a sandbox, is expected; scanning real networks, cracking passwords, or building exploits is not.
#S2-CYB-NO-04
Spotting an attack in traffic data starts with knowing what normal looks like -- typical protocols, typical destinations -- so a spike or an odd new connection stands out as a possible scan or exfiltration attempt.
Reasoning from provided datasets or visualizations, including how AI tools like anomaly detection assist that reasoning, is the scope; building machine learning models or running live threat hunting is not.
#S2-CYB-NO-05
Automating a routine security task, like filtering logs, only helps if it's done safely -- validating input, handling errors, and never hard-coding a password into the script.
Writing or reviewing simple scripts for secure practice is expected; building production-grade automation pipelines or treating any scripting language as inherently secure is not.
#S1-CYB-ND-01
The same service often comes in an insecure and a secure flavor -- HTTP and HTTPS, Telnet and SSH -- and knowing which one a situation calls for means weighing the risk of plaintext against the cost of encrypting.
Comparing protocol pairs and reasoning about exposure in simulations or case studies is the scope; actually attacking a live network or configuring real infrastructure is not.
#S1-CYB-ND-02
The OSI model is a way to trace a piece of data's journey across a network and see which layer is doing which job, including where encryption or authentication kicks in.
Using the layers as a reasoning tool for how data moves and where security lives is the goal; reciting all seven layers from memory or matching every protocol to its exact layer is not.
#S1-CYB-ND-03
Real networks rarely fit one clean label -- they blend topologies, run several protocols at once, and mix IPv4 with IPv6 -- so describing a network means capturing that mixture rather than forcing it into a single box.
Describing how addressing and topology actually work together in practice is expected; sorting networks into old-style address classes or designing a production addressing scheme is not.
#S1-CYB-ND-04
Sizing up a security risk means naming the threat, the weakness it exploits, and what could realistically happen if it's used -- including newer wrinkles like phishing that's been automated with AI.
Reasoning through case studies or simulated scenarios with a simple likelihood-and-impact lens is the point; running real penetration tests or touching live hardware is not.
#S2-CYB-ND-01
A router or a host firewall does nothing for security until it's actually configured -- setting up a VPN tunnel, an access control list, or a firewall rule is what turns hardware and software into a layer of defense.
Configuring these features in a simulated or virtual lab is the expectation; physically wiring hardware or touching a network carrying real production traffic is not.
#S2-CYB-ND-02
Designing a secure network means more than picking parts -- it means deciding what counts as suspicious activity, where to put monitoring, and what an automated response like blocking or isolating traffic should look like.
Scaffolded design exercises that reason through choices and trade-offs are the target; building a fully automated security operations center or tuning real AI models is not.
#S2-CYB-ND-03
A star topology and a mesh topology fail differently -- one has an obvious single point of failure, the other trades that away for more complexity -- and picking mitigations like redundancy or segmentation depends on knowing which risk is inherent to the shape versus fixable by design.
Assessing topologies through diagrams, simulations, or case studies is expected; configuring or testing designs on an actual enterprise network is not.
#S1-CYB-PP-13
A security decision -- like letting an automated system respond on its own versus keeping a human in the loop -- trades off speed and consistency against judgment and accountability, and that trade-off has real consequences for the people affected.
Analyzing and ethically weighing a described scenario is the point; building the automated system or deploying it for real is not.
#S1-CYB-PP-14
A phishing email or a pretexting phone call works by pulling on urgency, authority, or trust rather than by breaking any code, and naming which lever it's pulling is how you see through it.
Recognizing and explaining the manipulation in existing examples is the goal; writing new phishing content or running a social engineering attempt on real people is not.
#S1-CYB-PP-15
Explaining a vulnerability to an executive takes different words than explaining it to another technician, and picking the right level of detail and the right next steps for the audience is the actual skill.
Practicing that translation for a hypothetical audience is the task; briefing a real external stakeholder, or leaning on AI-generated text to do the writing, is not.
#S2-CYB-PP-10
AI in cybersecurity cuts both ways -- the same pattern-detection techniques that flag an intrusion can also help an attacker automate one, so a professional has to weigh that dual use rather than treat AI as simply defensive.
Comparing the benefits, risks, and responsibilities around AI use in security is the scope; building, training, or deploying an actual AI model for security work is not.
#S2-CYB-PP-11
Finding a vulnerability is only half the job -- responsible disclosure is about reporting it through the right channel and timeline so it gets fixed instead of exploited, and bug bounty programs are one structure built for that.
Examining how coordinated disclosure and bug bounty programs are supposed to work, and how they can fail, is expected; actually finding a vulnerability on live systems or filing a real report is not.
#S2-CYB-PP-12
A security decision that isn't written down might as well not have happened -- an incident response playbook or a decision log is what lets a team coordinate and lets someone later verify why a call was made.
Producing documentation artifacts for a scenario is the goal; maintaining documentation for a real, live security operation is not.
#S1-CYB-TS-07
Spoofing, interception, and denial-of-service attacks each ride on a specific weakness in how networks normally behave, and untangling threat from vulnerability from exploit from impact is what makes the concept usable rather than just a vocabulary list.
Classifying and explaining example attacks conceptually is the expectation; actually carrying one out or using real offensive tools is not.
#S1-CYB-TS-08
Running a threat like ransomware through the CIA triad -- confidentiality, integrity, availability -- plus where the data sits and what kind of control would help, turns a scary headline into a structured analysis.
This is a classification and reasoning exercise on named example threats; designing an actual security system or picking specific vendor products is not.
#S1-CYB-TS-09
Encryption isn't free -- it costs processing time and key-management effort -- so deciding whether a situation needs it, and whether symmetric or asymmetric fits better, is a trade-off call, not an automatic yes.
Reasoning about when and why to encrypt using trusted, existing algorithms is the target; implementing a cipher or analyzing the math behind how hard it is to break is not.
#S1-CYB-TS-10
No single lock keeps everything safe -- firewalls, input validation, device updates, and a locked door each catch a different failure, and layering preventive, detective, and corrective controls together is what defense-in-depth means.
Evaluating and categorizing controls across domains, including their usability and cost trade-offs, is expected; configuring a real security tool or choosing specific commercial products is not.
#S2-CYB-TS-06
Requiring a second factor like a phone app is more secure, but it can also lock out a student without a smartphone -- designing access control means weighing that kind of trade-off, not just picking the strongest option.
Designing and evaluating authentication and authorization schemes conceptually is the target; building a real biometric system or administering production identity infrastructure is not.
#S2-CYB-TS-07
Not every risk gets fixed -- an organization can accept it, avoid the risky activity entirely, transfer it through insurance, or mitigate it with controls, and choosing among those four responses depends on likelihood, impact, and how real users will actually behave around the fix.
Justifying a strategy for a given scenario is the scope; running formal statistical risk calculations or using professional risk-assessment tools is not.
#S2-CYB-TS-08
Responding to a breach follows a lifecycle -- prepare, detect, contain, eradicate, recover, review -- and applying those phases to a real-world scenario means walking through what each one would actually require.
Examining or adapting a simplified incident response plan for a scenario is expected; operating a live security operations center or managing an actual incident is not.
Data & Analysis
#MS-DAT-DC-21
How precise and how fine-grained data collection is changes how accurate it is, how much storage it needs, and how useful it ends up being -- and different situations call for different tradeoffs.
Comparing given examples, like step counts recorded by minute versus by day, is the task; actually collecting data at varying precision is not required.
#MS-DAT-DC-22
Metadata -- a photo's timestamp and location, not the picture itself -- answers different questions than the data it describes, often without anyone deliberately adding it.
Explaining the distinction using tools like file properties or page source is the expectation; technical metadata standards or formats are not.
#MS-DAT-DC-23
A spreadsheet or similar tool can sort, filter, group, and summarize a structured dataset, and explaining why each operation was chosen is part of the skill.
Working with an existing, grade-level dataset is the scope; collecting data, cleaning messy data, or mastering the software itself is not required.
#MS-DAT-DC-24
A dataset with missing or misformatted values can be fixed more than one way -- deleting incomplete records, reformatting, or leaving it as-is -- and each option trades off differently, including the risk of introducing new bias.
Evaluating options on a provided dataset is the task; there's no single 'correct' fix to pick, and building automated error-detection tools isn't expected.
#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.
#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.
#MS-DAT-DI-25
A spreadsheet or programming tool can surface a relationship between variables in a dataset, and that relationship can then be used to make a prediction worth checking for sense.
Using a tool to find the relationship and sanity-check the prediction is the scope; statistics beyond grade-level math standards is not expected.
#MS-DAT-DI-26
The same dataset can be turned into more than one visualization, and comparing them for clarity, accuracy, and accessibility shows how a design choice changes what a reader takes away.
Working from existing data and comparing designs is the task; using a particular computational tool isn't required.
#MS-DAT-DI-27
Summarizing a finished data investigation -- the original question, how the data was gathered and analyzed, where bias or limitations crept in -- shows the reasoning behind the conclusions, not just the conclusions themselves.
Reflecting on an investigation, their own or someone else's (even via interview), is the task; actually collecting new data is not required.
#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.
#MS-DAT-IM-28
Letting an app collect personal data trades a real benefit, like personalization or free access, against a real risk, like lost privacy or reduced control over the data -- and where that data ends up governed can cross national borders.
Explaining these tradeoffs conceptually, including basic data-sovereignty ideas, is the goal; technical protections like encryption or specific laws like GDPR/COPPA are not.
#MS-DAT-IM-29
Every stage of working with data -- collecting it, processing it, analyzing it, presenting it -- involves a human choice, and those choices can unintentionally bias the data, distort the conclusions, or weaken a model trained on it.
Recognizing this in simple examples is the expectation; advanced statistics or the technical mechanics of AI training are not.
#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.
Data Science
#S1-DSC-AM-04
Matching the chart or statistic to the kind of data -- bar charts and frequency tables for categories, histograms and scatter plots for numbers -- with an eye on who will actually be reading it.
Choosing and applying descriptive techniques is the point; inferential tests like chi-squared or t-tests, and modeling approaches like regression, are out of scope.
#S1-DSC-AM-05
Noticing which variables have holes in them, how much is missing, and whether the gaps cluster around particular rows, because how you handle that missing data can quietly change or bias your results.
Observing patterns in missing data and discussing their effects is expected; formally classifying the missingness mechanism or implementing advanced imputation methods is not.
#S1-DSC-AM-06
Cleaning, aggregating, and charting a structured dataset with code -- say, computing and visualizing decade-long climate trends by continent -- rather than eyeballing a spreadsheet.
Working with a dataset that fits on a personal device using existing libraries is the scope; distributed computing or building analysis tools from scratch is not.
#S2-DSC-AM-05
Fitting a simple model -- linear regression, a decision tree -- to a dataset and using its output to say which inputs actually drive the prediction, like which factors most affect a runner's race time.
Applying and interpreting an existing simple model is the scope; implementing the algorithm from scratch or using advanced techniques like neural networks is not.
#S2-DSC-AM-06
Trying more than one fix for missing data -- dropping incomplete rows versus filling them in with the mean -- and comparing how each choice changes the resulting statistics or charts before deciding which to use.
Comparing the observed effects of different strategies is expected; implementing advanced imputation algorithms or running statistical quality tests on the strategies is not.
#S2-DSC-AM-07
Making sense of data that isn't a tidy spreadsheet -- counting word frequencies across a pile of text documents, or reducing an image dataset's huge pixel count down to something visualizable.
Applying basic techniques to unstructured or high-dimensional data is the scope; building models for tasks like natural language processing or image recognition is not.
#S1-DSC-CC-01
Turning a flat table of numbers into a first understanding -- summary stats, a histogram, a scatter plot -- and letting what you find point to what to check next.
The data here is flat and numeric; nested or hierarchical formats and anything past basic summary statistics are out of scope.
#S1-DSC-CC-02
Before analyzing someone else's dataset, reading its readme or data dictionary like a detective -- where it came from, what each column means, what might be skewing it -- so the analysis that follows is grounded.
Reading and reasoning about metadata that already exists is the task; datasets with no metadata at all, or auditing whether the metadata matches the data, aren't expected.
#S1-DSC-CC-03
Writing code with existing data libraries to get a dataset ready for analysis -- filtering rows, grouping and summarizing, reshaping, joining tables -- rather than analyzing it as-is.
Using existing libraries on a laptop-sized dataset is the scope; building your own data-manipulation tools or handling datasets too large for a personal device is not.
#S2-DSC-CC-01
Digging into nested data -- a JSON API response where each song has an artist object with its own fields -- to pull out the values needed for a summary stat or a chart.
Navigating one level of nesting is the scope; deeply nested or graph-structured data is not.
#S2-DSC-CC-02
Keeping a running record of a dataset's whole life story -- where it came from, when, and every cleaning or reshaping step taken -- built up as you go rather than reconstructed afterward, so someone else could redo the work.
Writing clear documentation as part of the process is expected; using formal version control or coordinating documentation across a team isn't.
#S2-DSC-CC-03
Pulling data from two unrelated places -- a live stock API and a historical file -- and stitching them together on a shared key like ticker and date, checking the merge actually worked before analyzing further.
Using existing libraries to combine structured sources is the scope; fuzzy matching, unstructured data like images or raw text, or writing your own API client from scratch is not.
#S2-DSC-CC-04
Weighing a project's goal against what's actually feasible -- a public air-quality API versus buying a sensor versus an existing government dataset -- and picking a collection strategy that fits your tools and skills.
Reasoning through the tradeoffs of a single, feasible data source is the scope; building custom collection tools or juggling multiple large or disparate sources is not.
#S1-DSC-MI-07
Reading someone else's chart or summary stats and explaining, in plain terms, what the pattern means for the original question, plus what limitations or alternative explanations might complicate that story.
Interpreting an existing analysis is the task; producing the statistics or visualizations yourself, or running formal hypothesis tests, is not.
#S1-DSC-MI-08
Arguing for the right kind of model given the problem -- logistic regression for a yes/no outcome instead of linear regression for a number -- and why picking wrong could actually hurt the people it affects.
Explaining why one model type fits the problem is the task; building the model or statistically comparing model fit is not.
#S1-DSC-MI-09
Watching how a model's predictions wobble when you add or remove rows -- a lot for a tiny dataset, barely at all for a big one -- to build intuition for why more data tends to mean a more stable model.
Observing and describing this effect is expected; calculating formal statistical measures of variance or its mathematical relationship to sample size is not.
#S2-DSC-MI-08
Judging whether a model is actually good using standard numbers -- accuracy for a classifier, R-squared for a regression -- and weighing whether a fancier model's gain in fit is worth its extra cost.
Using existing library functions to compute and interpret metrics is the scope; deriving the metrics' math or doing formal algorithmic complexity analysis is not.
#S2-DSC-MI-09
Weighing a transparent but slightly less accurate model against a black-box one that scores higher -- like a logistic regression educators can explain versus a neural network they can't -- and arguing which fits the situation better.
Reasoning about these trade-offs is the task; training the models yourself or proving mathematically why the trade-off exists is not.
#S2-DSC-MI-10
Rerunning a model after adding a new variable -- like neighborhood price alongside square footage -- to see how it shifts accuracy or changes which variable the model leans on most.
Observing these effects empirically is the scope; calculating formal multicollinearity measures or explaining the underlying math is not.
#S1-DSC-PP-12
Building privacy, transparency, and accountability into an actual project -- like anonymizing a social media dataset and writing a public statement about what was collected and why -- rather than treating ethics as an afterthought.
Applying these principles in practice is the task; reading formal privacy law or quantifying bias with statistics is not.
#S1-DSC-PP-13
Looking at who a dataset represents well and who it leaves out -- like checking a facial recognition set for skin tone and gender balance -- and proposing how to make the collection more equitable.
Reasoning qualitatively about representation and proposing fixes is the scope; using statistical tests to quantify representation or writing bias-mitigation algorithms is not.
#S1-DSC-PP-14
Writing up the same analysis twice for two very different readers -- a public presentation on community health findings versus a technical report other data scientists could reproduce.
Producing documentation and communication with guidance is expected; polished, publication-quality writing or a formal public presentation isn't required.
#S2-DSC-PP-13
Tracing potential harm through an entire project's pipeline -- from what data got collected to what a model predicts -- and pushing for fairer, more transparent decisions at each stage.
Reasoning about fairness and transparency in a real project is the scope; interpreting specific privacy laws or running statistical fairness tests is not.
#S2-DSC-PP-14
Judging whether an app's privacy policy and permissions actually protect users -- like questioning unnecessary location tracking -- and proposing safeguards that would do better.
Evaluating existing protective measures and suggesting alternatives is the scope; implementing encryption or building consent-management software is not.
#S2-DSC-PP-15
Reshaping the same findings into two very different deliverables -- a policy-focused slide deck for a city council and a full technical report with reproducible code for other analysts.
Producing audience-appropriate communication with structure and guidance is expected; publication-quality writing, custom infographics, or a formal public presentation is not.
#S1-DSC-VZ-10
Designing the same finding two different ways depending on who's looking -- a plain bar chart for a general audience, something denser like error bars or a density plot for a data-savvy one.
Designing single, static charts thoughtfully for an audience is the scope; building interactive dashboards or user-testing the design is not.
#S1-DSC-VZ-11
Recognizing the unwritten rules a chart is supposed to follow -- axes that increase upward, colors that mean what they should -- and explaining how breaking one, like flipping the Y-axis, distorts what a reader takes away.
Basic static charts are the scope; 3D, interactive, log-scale, or more advanced chart types like network graphs aren't expected.
#S2-DSC-VZ-11
Building a chart carefully enough that its scales, axes, and colors show the data honestly -- like giving SAT and ACT scores their own appropriately-ranged axes instead of forcing them onto one scale -- while keeping it readable for colorblind viewers too.
Deliberate, accessible design of a static chart is the scope; formal user testing or building interactive dashboards is not.
#S2-DSC-VZ-12
Picking apart a chart from a news story or social post -- a truncated axis, a cherry-picked date range -- to explain how the design choice exaggerates a trend and what that could lead people to believe.
Critiquing an existing visualization's design and its effect on viewers is the scope; verifying the underlying data's authenticity or judging whether the deception was intentional is not.
Game Development
#S1-GMD-AR-07
Connecting the dots between what's happening inside a computer -- its processor, graphics chip, memory, network -- and what a player actually notices, like a laggy frame rate or slow response to a button press.
A conceptual understanding of how hardware affects gameplay is the goal; comparing specific devices or digging into hardware specs and internals is not.
#S2-GMD-AR-06
Looking at how a game's systems are organized -- keeping input handling separate from gameplay logic, say -- and reasoning about how that organization makes the game easier to extend, faster to run, or more likely to break.
Analyzing and explaining architectural trade-offs is the expectation; actually implementing the improvements or benchmarking performance is not.
#S1-GMD-DD-01
Breaking a simple game down into its parts -- who plays, what moves are legal, how the rules change the game's state, and what ends it -- and capturing that structure in a diagram, flowchart, or rule table, the way you might map out a card game's turn order and win conditions.
The work is analyzing and diagramming games simple enough to map by hand; games with heavy randomness, real-time action, or sprawling rule sets that would require actually building them are out of scope.
#S1-GMD-DD-02
Sketching a game's story and player choices scene by scene -- rough drawings and notes showing key moments, decision points, and how the game reacts -- so a teammate can see the shape of the experience before any of it is built.
Simple, low-fidelity sketches that communicate structure and interactivity are enough; polished art and mapping out every possible branch aren't expected.
#S1-GMD-DD-03
Wiring together the pieces that make a game actually playable -- input that does something, code that reacts to it, and rules that decide when you win or lose -- so the separate functions add up to one coherent play experience rather than sitting as disconnected demos.
A working, connected set of input, response, and outcome logic is the target; a finished, commercial-quality game with polished visuals or advanced UI is not.
#S1-GMD-DD-04
Taking logic that already controls something in a game -- an enemy, a moving hazard, a scoring system -- and making it more capable by adding or combining conditions, then checking that the change actually makes the behavior better or more interesting.
Editing and testing conditional logic that already exists is the task; designing true AI, machine learning, or judging an algorithm's efficiency is not.
#S2-GMD-DD-01
Choosing at least two responsible-design moves -- something like adjustable difficulty for accessibility and a rule against addictive reward loops -- and explaining how each one actually shapes how players behave or feel, not just tacking them on afterward.
Justifying a couple of chosen design decisions baked into the gameplay is the task; covering every responsible-design category or running formal user research is not.
#S2-GMD-DD-02
Writing the logic that switches a character between premade animations -- idle to running to attacking -- based on what's happening in the game, so the visuals track the action.
Triggering and transitioning between existing animation states with code is the point; creating original animations or applying artistic animation principles is not.
#S2-GMD-DD-03
Giving a non-player character a small set of behaviors -- patrol, chase, retreat -- and clear if/then rules for switching between them, like fleeing once health drops below a threshold.
Rule-based state and transition logic is what's expected; machine learning, pathfinding optimization, or any behavior that adapts from player data is not.
#S1-GMD-PX-05
Designing a game's screen and controls so they're readable, consistent, and pleasant to look at, while also building in at least one real accommodation for players who need it -- larger text, remappable keys, that kind of thing.
Applying a handful of concrete design and accessibility criteria is the expectation; meeting formal accessibility standards or running a professional usability audit is not.
#S1-GMD-PX-06
Watching a couple of real people try to play the game, noting where they get confused or stuck, and using those observations to make specific, small fixes to the design.
A handful of observed playtesters and a short list of friction points is sufficient evidence; formal studies, large samples, or statistical analysis aren't expected.
#S2-GMD-PX-04
Judging how well a game keeps players absorbed by looking at concrete factors -- consistent rules, quick feedback, clear goals -- and considering how the choice of controller, keyboard, or motion input changes how comfortable and accurate play feels.
Reasoning from gameplay evidence and playtesting observations about a couple of immersion factors is the scope; formal UX research or trying out every possible input device is not.
#S2-GMD-PX-05
Comparing two versions of a game that differ in one deliberate way -- say, two different control schemes -- and using what players actually did, like completion counts or where they got stuck, to argue which version works better.
Comparing two intentionally different versions with simple observed evidence is the task; running a formal A/B test or applying statistics is not.
#S1-GMD-PP-08
Working out which license fits a game project, giving proper credit for any borrowed assets or code, and being able to say how those choices respect the people who made the original work.
Choosing and applying a license and giving attribution is the scope; interpreting copyright law like a lawyer is not.
#S1-GMD-PP-09
Building a game as part of a team -- splitting up tasks, using shared tools to track who's doing what, and talking honestly about whose voices and experiences the game does or doesn't represent.
Practicing team communication and reflecting on representation through discussion is the expectation; a teacher assigning team makeup or the class resolving deep social conflicts is not.
#S2-GMD-PP-07
Picking a focused set of ethical concerns -- like making sure the game doesn't exploit players' data or exclude certain players -- and being able to point to specific design decisions in a prototype that address them.
A partial build or prototype with a written explanation of a few ethical choices is enough; a fully polished game or a comprehensive ethics review covering every domain is not.
#S2-GMD-PP-08
Carrying your assigned role on a game team while still pitching in outside your specialty when the team needs it -- a programmer sketching art ideas with a teammate, for instance -- and working through disagreements instead of around them.
Practicing role management and flexible collaboration is what's graded; using formal project-management methods or achieving a perfectly smooth team dynamic is not.
Physical Computing
#S1-PHY-CI-04
Getting one device to wirelessly hand off sensor readings to a neighboring device or a gateway, and then actually doing something with that data once it arrives -- logging it, charting it, letting it flip a switch -- rather than just proving the link works.
Short-range, device-to-device or device-to-gateway transmission with a real downstream use for the data is the scope; setting up cloud services, managing servers, or inventing a custom protocol is not.
#S1-PHY-CI-05
Linking two or more physical devices so they share data or actions, picking a communication method -- serial, Bluetooth, Wi-Fi, a low-power radio link -- and weighing what it costs you in range, message size, delay, or battery life.
Comparing and choosing among available communication options for a small multi-device setup is the scope; designing networking infrastructure or deploying it at scale is not.
#S2-PHY-CI-04
Building a system where data moves between physical devices well enough to actually monitor or control something remotely, then defending the communication choice -- local versus longer-range -- by its tradeoffs in reach, delay, or battery use.
The system can be conceptual, simulated, or actually built; running an enterprise-scale IoT platform or maintaining persistent cloud infrastructure is not expected.
#S2-PHY-CI-05
Pulling data together from several physical devices through a central point -- a single-board computer or a coordinating script -- sketching out a simple message format for how they talk, and connecting that setup to real security concerns.
A small, simulated-or-built network with a basic protocol and security reasoning is the scope; cloud servers, advanced cryptography, or enterprise-grade security configuration are not required.
#S1-PHY-DD-03
Writing code that visibly drives what a physical device does -- reading a sensor, firing an output, switching between states -- and revising it across several rounds once you see how it actually behaves.
Repeated write-test-revise cycles in whatever environment fits, block-based through text, are the scope; fabricating hardware or working in a professional embedded toolchain is not expected.
#S2-PHY-DD-03
Building the software side that makes a physical device more useful to a person -- a settings screen, a live readout, an app that reacts to what the device is sensing -- with real thought put into how someone actually interacts with it.
A purposeful, user-facing extension of an existing device's function is the scope; fully autonomous behavior or a professional-grade embedded software pipeline is not.
#S1-PHY-HC-01
You build a working circuit from a schematic -- a microcontroller, a resistor, an LED is the classic starter -- and when the LED doesn't light, a multimeter and a look at the wiring is how you find the loose connection or backwards part.
Building and debugging a single-microcontroller circuit from a diagram is the scope; circuits with multiple integrated chips, or laying out and etching a custom PCB, are not expected.
#S2-PHY-HC-01
Using CAD software to lay out and simulate a build that mixes moving mechanical parts -- motors, linkages, a frame -- with the electronics that drive them, and refining the model before anything gets built, the way you'd rough out a robotic arm's structure digitally first.
Modeling and iterating a multi-part electromechanical design inside CAD is the scope; deep electronics theory or industrial automation practice is not expected.
#S1-PHY-IO-02
Picking a sensor and an output that fit the job -- a light sensor driving an LED, a button triggering a buzzer or a short motion -- and wiring and coding them so the system actually reacts to something happening in the real world.
A handful of everyday sensors and outputs on a hobbyist board is the scope; large component counts, industrial-grade hardware, or anything mission-critical are not expected.
#S2-PHY-IO-02
Building a system where a sensor's reading actually steers an output toward a target -- a fan that speeds up as a room gets warmer -- and choosing which sensor to use by weighing accuracy, response time, and cost against each other.
The feedback loop can be conceptual, simulated, or partly built depending on the setup; a fully optimized, precision, or industrial-grade control system is not expected.
#S1-PHY-PP-06
Running a physical computing build through real version control -- separate branches for, say, the sensor code and the display code, commits with messages that actually explain the change, and merging everyone's work back together, conflicts and all.
Everyday branch-commit-merge collaboration, including untangling a simple conflict, is the scope; hosting your own repository server or using advanced moves like rebasing or cherry-picking is not.
#S1-PHY-PP-07
Looking at one specific physical computing build and asking who it actually helps or leaves out, tying the answer to concrete design choices -- a switch placed out of reach, a part that wears out fast -- rather than speaking in generalities.
A grounded evaluation of a single real project against one or two concerns like accessibility or safety is the scope; sweeping global-impact studies or formal policy analysis are not required, though they're fine as a reach extension.
#S1-PHY-PP-08
Thinking through what someone could do if they got their hands on your device -- pull data off it, tamper with it, impersonate it -- and matching that against real defenses like a PIN pad, encrypting what it sends, or a case that resists prying.
Reasoning about physical-access threats and matching defenses is the scope; running an actual penetration test or a formal security audit is not.
#S2-PHY-PP-06
Running a physical computing build the way a small engineering team would -- a Kanban board tracking tasks like prototyping, wiring, and testing, regular standups, and responsibilities and conflicts handled fairly across the team.
Classroom-scale use of a real methodology like agile is the scope; professional project-management software or leading a multi-team effort with outside stakeholders is not.
#S2-PHY-PP-07
Grounding a judgment about a physical computing project's effect on people in some actual small-scale research -- a survey, a few interviews -- and narrowing the case to one or two concerns like accessibility or sustainability plus a practical constraint like cost.
A locally-grounded evaluation tied to your own project and a small amount of real research is the scope; formal sociological studies or global policy analysis are not expected.
#S2-PHY-PP-08
Carrying a physical computing project through the full engineering design cycle -- sketches, a written plan, testing notes, reflection -- and showing, on paper, where a diverse user's actual needs changed a design decision.
Documenting the design process and how user needs shaped it is the scope; following a formal project-management framework or using a professional version control system is not required here.
Programming
#MS-PRO-PD-12
Naming a repeated block of steps and turning it into a procedure is what makes code easier to read and reuse.
Recognizing the opportunity and creating a simple procedure is the task; procedures with parameters or return values, or large modular systems, are not expected.
#MS-PRO-PD-13
Documentation -- looking up what a function does, searching an error message -- is a normal, expected part of writing and fixing a program.
Using teacher-provided or self-selected, grade-appropriate documentation is the expectation; reading professional-level docs is not.
#MS-PRO-PD-14
Code, images, music, and text used in a project all belong to someone, and giving credit -- knowing the difference between learning from someone's work and copying it -- is part of making anything.
Basic attribution and ethical awareness are the goal; studying copyright law or licensing one's own code is not.
#MS-PRO-PD-15
Building a program with a partner goes better with real collaboration habits -- sharing ideas while planning, giving and taking feedback, working respectfully on shared tools.
Classroom-level teamwork practices are the expectation, not formal frameworks like Agile/Scrum or professional project-management software.
#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.
#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.
#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.
#MS-PRO-RD-17
Tracing through a piece of code -- watching what a loop repeats, what a conditional branches on, what a variable holds at each step, what a procedure does when it's called -- is how you show you actually understand what it does.
Tracing execution is the task; debugging the code, testing it, or analyzing procedures that take parameters or return values is not.
#MS-PRO-RD-18
Code an AI tool generated still needs a human check -- do the functions it calls actually exist, does the logic hold up, is it readable -- before it's trusted.
Evaluating given AI-generated code is the task; generating code with AI themselves, or judging code beyond their own level, is not expected.
#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.
#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.
#MS-PRO-TR-19
Finishing a program means actually testing it -- checking inputs and outputs, isolating a procedure, giving and getting feedback in a code review -- and writing down what changed and why.
Simple, systematic techniques and basic commenting are the expectation; debugging software, unit-testing frameworks, and version control are not.
#MS-PRO-TR-20
Real feedback from real users -- especially about what's hard to use or hard to access -- should actually change the next version of a program.
Incremental, awareness-driven improvement is the goal; formal accessibility audits or frameworks are not expected.
#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.
#MS-PRO-VD-16
A program that stores several kinds of data in variables -- numbers, text, true/false -- can update them, make decisions based on them, and repeat actions using them.
Working with individual variables (incrementing, accumulating, converting) is the scope; lists, dictionaries, and other data structures are not expected here.
#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.
Software Development
#S1-SWD-DD-01
Picking the right built-in linear structure -- a stack for undo history, a queue for a print line, a dynamic array for a growing list of readings -- is what makes storing and retrieving data efficient for a given problem.
Using library-provided linear structures and their methods is the expectation; implementing a data structure's internals or moving on to dictionaries, trees, graphs, or heaps is not.
#S1-SWD-DD-02
As a program grows, structuring it around abstraction -- separating what a piece does from how it's built underneath -- is what keeps adding features from turning into a rewrite.
Making deliberate structural and abstraction choices for a single-machine application is the scope; distributed infrastructure and formal complexity analysis or performance tuning are not.
#S1-SWD-DD-03
An IDE's everyday tools -- autocomplete and error highlighting while typing, breakpoints and variable inspection while debugging, built-in commits while collaborating -- are what make day-to-day coding faster and more reliable.
Using these built-in IDE features fluently is the expectation; understanding how they work internally or building custom build configurations is not.
#S2-SWD-DD-01
Choosing between a dictionary, tree, graph, or heap -- and being able to say in practical terms which is faster or lighter for a given job, like looking up a record versus finding a shortest path -- is the next step up from linear structures.
Selecting and applying built-in implementations with a plain-language efficiency comparison is expected; implementing the structures from scratch or using Big O notation is not.
#S2-SWD-DD-02
Sketching out a few different user personas and mapping their journey through a product -- where they'd get stuck, what they'd need -- gives design decisions something concrete to point back to.
Creating personas and journey maps to justify design choices is the task; validating those personas with market research or shipping a fully working application is not.
#S2-SWD-DD-03
Building a project in visible rounds -- plan, build, test, review, write down why -- one added feature at a time, is what iterative development looks like in practice.
Structuring work into documented iterative cycles is the expectation; adopting a named formal methodology like Agile or Scrum with its specific ceremonies is not.
#S2-SWD-DD-04
Speeding up a slow algorithm -- swapping linear search for binary search on sorted data, say -- means recognizing which data structure or divide-and-conquer strategy would fit better, then measuring the improvement.
Improving an existing algorithm using known data structures and paradigms is the scope; inventing new algorithmic paradigms is not.
#S1-SWD-PP-08
Building software as a team means using version control for real -- branches, pull requests, resolved conflicts -- while actively pulling in teammates' different perspectives on design, usability, and ethics, plus giving proper credit for reused code and media.
Working within a classroom-scale team repository is the expectation; administering version control infrastructure or connecting it to automated deployment pipelines is not.
#S2-SWD-PP-09
Running a project with a real process like Scrum or Kanban only counts if equity concerns -- accessibility, bias -- are treated as requirements that can push back a deadline or force a rewrite, not nice-to-haves.
Applying an industry-standard process and project-management tools to a classroom-scale project, with ethical tradeoffs explicitly justified, is the expectation; managing project budgets, using enterprise project-management software, or handling stakeholders outside the classroom is not.
#S1-SWD-TR-06
An AI-assisted IDE feature can summarize what an unfamiliar function does or flag a likely bug, turning an unreadable stretch of legacy code into something a student can act on.
Using existing AI-assisted IDE features for comprehension and debugging is the point; configuring or fine-tuning the underlying model, or wiring in outside AI tools, is not.
#S1-SWD-TR-07
A solid test plan doesn't just check that a program works on normal input -- it deliberately tries edge cases, bad input, and unusual user behavior across the whole project.
Systematically writing and applying test cases, including AI-suggested ones, to a multi-function project is the scope; building automated testing frameworks, running large-scale QA, or security or penetration testing is not.
#S2-SWD-TR-07
On a bigger, multi-file project, the IDE's AI-assisted testing and refinement features -- generating a starter test suite, suggesting a faster rewrite of a slow loop -- speed up work a student then has to review and judge, not just accept.
Using and critically evaluating IDE-integrated testing and optimization tools on a high-school-scale project is expected; deep performance profiling, hardware-level analysis, or enterprise-scale statistical test reporting is not.
#S2-SWD-TR-08
Tracking down a bug in a project with multiple files and outside libraries means using a real debugging method -- narrowing the search in half, tracing how a value changes across functions -- not just guessing and rereading code.
Applying formal debugging methods and advanced IDE debugger features to logical errors in a multi-file project is the scope; operating-system-level debugging like assembly or memory-register analysis is not.
#S1-SWD-UX-04
Running an interface through an accessibility or design-critique tool and using what it flags -- weak contrast, cramped spacing -- is how a design gets refined rather than just judged by eye.
Evaluating and refining an existing interface with established tools and principles is the task; creating original graphics or a full design system is not.
#S1-SWD-UX-05
Running software through a structured heuristic review -- checking it against known usability and accessibility criteria -- surfaces where it fails users who differ in ability, language, or background.
Evaluating against established criteria and guidelines drives the design decisions here; actually testing with real users or inventing new accessibility solutions beyond existing guidelines is not expected.
#S2-SWD-UX-05
Watching real people struggle or succeed with an interface, and writing up what specifically went wrong, turns a vague sense that 'it's confusing' into usable feedback.
Conducting and documenting a peer- or classroom-scale usability evaluation is the expectation; formal research ethics approval, outside participants, specialized eye-tracking tools, or statistics beyond simple averages are not.
#S2-SWD-UX-06
An interface that reflows sensibly from phone to desktop, and stays usable for people with different needs, is the product of actually applying UI design principles rather than just picking colors.
Building one working responsive, accessible interface is the goal; supporting every possible device and operating system or mastering a responsive design framework is not.
Systems & Security
#MS-SYS-HW-30
Choosing between computing systems means weighing storage, connectivity, and accessibility features against a user's actual needs -- and naming at least one societal, environmental, or ethical cost that comes with the choice.
Comparing systems at a feature level is the scope; detailed technical specs like processor architecture are not expected.
#MS-SYS-HW-31
Specialized computing devices -- a robot, a vehicle's control unit, a medical imaging machine, a farm sensor -- all use the same input/output/processing/storage pattern to get real industry work done.
Describing how a chosen device works at that level is the task; building or programming the device is not.
#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.
#MS-SYS-IM-36
Making a computing system genuinely usable by people with different needs -- captions, adjustable text, alternative input devices -- is something a team can propose and refine together, then test with peers.
Proposing and peer-testing design improvements is the task; building accessible hardware from scratch or professional usability testing is not.
#MS-SYS-IM-37
Access to computing isn't even -- income, physical ability, geography, and community resources like libraries or Wi-Fi hotspots all shape who actually gets to use a computing system.
Investigating examples of this digital divide, using provided data, maps, or local surveys, is the scope; large-scale statistical analysis or policy evaluation is not.
#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.
#MS-SYS-NT-34
A message crossing a network gets split into packets, encoded, sent independently, and reassembled at the other end -- and things like congestion or bad hardware can cause packets to get lost along the way.
Modeling this process and naming causes of packet loss is the task; detailed protocols like TCP/IP or configuring real hardware are not.
#MS-SYS-NT-35
The internet keeps working because it's built from many interconnected devices each playing a role -- routers directing traffic, servers hosting data, clients requesting it -- with enough redundant paths that losing one piece doesn't break the whole thing.
A conceptual explanation of roles and resilience is the goal; configuring real networking equipment or explaining protocols in technical detail 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.
#MS-SYS-SE-32
Confidentiality, integrity, and availability each protect data in a different way, and seeing what breaks when one of them fails -- a leaked password, an altered grade, a blocked website -- is how the CIA triad becomes real instead of abstract.
Explaining the effects in relatable contexts like school accounts, gaming, or social media is the goal; professional security audits or deep cryptography are not.
#MS-SYS-SE-33
Phishing, malware, ransomware, and social engineering all exploit some mix of human behavior and system weakness, and knowing basic defenses -- strong passwords, multifactor login, spotting suspicious activity -- is the practical response.
Identifying attack types and prevention strategies is the scope; actually testing network defenses or analyzing how malware is built is not.
#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.
X+CS
#S1-XCS-XC-01
A core CS idea -- data representation, algorithmic thinking, abstraction -- can explain why a technique works in another subject entirely, like how turning text into word counts lets a literature class detect an author's style patterns that close reading alone would miss.
Explaining the conceptual connection between the CS idea and the other field is the goal; actually building a working computational model to solve an advanced problem in that field is not expected.
#S1-XCS-XC-02
Computational thinking -- breaking a problem into parts, spotting the variables that matter, sketching out the steps -- can be aimed at a problem that's native to another subject, like laying out on paper how a biology student would track a shrinking prey population over several generations.
Designing and documenting the approach as pseudocode or a flowchart is the expectation; actually coding, running, and refining a working solution is not.
#S1-XCS-XC-03
A real computing tool borrowed by another field, such as a machine learning system trained on labeled scans to flag tumors in medical imaging, can be picked apart to show the computing concept underneath it and the concrete difference it made in that field.
Explaining how the technology works and what changed because of it is the scope; rebuilding the technology from scratch or tracing its full societal and policy fallout is not.
#S1-XCS-XC-04
Ordinary data moves -- sorting, filtering, grouping, calculating a new column -- can turn a messy, real dataset from another subject into something that reveals a pattern, like turning raw county voting records into a picture of turnout by district.
Applying existing computational methods to a dataset that runs fine on a personal laptop is the task; inventing new algorithms or handling data too large for ordinary hardware is not expected.
#S1-XCS-XC-05
Judging whether an algorithm actually serves another discipline well means choosing the right yardsticks for it -- how accurate it is, how it holds up as the problem grows, how well it fits real-world constraints -- like checking a mapping app's routing not just for the shortest path but for whether it respects road closures or wheelchair access.
Choosing metrics and reasoning in plain terms about accuracy-versus-efficiency trade-offs is the expectation; formally deriving algorithmic complexity with Big O notation is not.