Independent Problem Solving and Digital Fluency: The Math101 Learning Framework

This is a working architecture, not a pile of apps. It connects mathematical reasoning, coding, information judgement, digital organization, AI literacy and self-regulation while keeping assessment honest about what a learner can do independently.

The design rules

1. Start with a problem, not a product. A website, game or graph is evidence only when the learner can connect it to the original question.
2. Represent before automating. Sketches, tables, equations, examples, flowcharts and plain-language algorithms expose reasoning.
3. Predict before execution. Prediction creates a claim that output can confirm or challenge.
4. Debug from evidence. The goal is not avoiding error; it is locating and learning from mismatch.
5. Fade help deliberately. Model, prompt, cue, then remove support and test a fresh task.
6. Assess transfer. Repeating a tutorial demonstrates repetition. A changed constraint reveals whether the idea travels.
7. Make assistance visible. Peers, tutors, templates, calculators, documentation and AI can support learning; the portfolio records their roles.
8. Design for access. Remove barriers that are irrelevant to the intended capability, while preserving the capability itself.
9. Separate curriculum alignment from credential claims. A framework may align with expectations without becoming an approved course or credit.
10. Treat data and people responsibly. Privacy, consent, accessibility, bias, security and real-world consequences belong inside technical work.

These rules reflect, but do not reproduce, Ontario's coding progression. The province's Grades 1–8 mathematics overview places coding within algebra and mathematical problem solving; the 2021 Grade 9 mathematics course continues with variables, relationships, modelling and coding. Math101 extends beyond those policy expectations and should be labelled accordingly.

The six-level capability rubric

The levels describe performance on a named capability under stated conditions. They are not grades, ages or personality labels.

A learner may be Level 5 at auditing a graph and Level 2 at writing a loop. Report the profile, not one inflated “digital native” score.

The rubric across six dimensions

For any task, examine:

• Problem framing: Can the learner state the goal, givens, constraints, stakeholders and success criteria?
• Representation and algorithm: Can they choose a useful model and organize a finite, testable process?
• Tool execution: Can they use an appropriate calculator, spreadsheet, code environment, search tool or AI system without the interface taking over the reasoning?
• Testing and debugging: Can they predict, test normal and boundary cases, find the first mismatch and revise one cause at a time?
• Explanation and evidence: Can they justify the result, cite sources, distinguish observation from inference and name uncertainty?
• Transfer and responsibility: Can they adapt the idea and identify privacy, accessibility, bias, security or human-impact concerns?

Age bands: same architecture, different evidence

Placement should follow demonstrated prerequisites and access needs, not age alone.

Early elementary: Grades 1–3

Emphasis: sequence, precise language, patterns, spatial movement, sorting, prediction and noticing errors.

Evidence might include a paper route algorithm, a repeating-number machine, instructions revised after a “human robot” misinterprets them, or a block sequence the learner predicts before running. Reading, spelling and fine-motor demands should be kept separate from the reasoning target.

An independent learner in this band can usually create a short sequence for a new but familiar goal, test it and repair an omitted or out-of-order step. “Create” can mean inventing a maze and writing fair instructions—not building a polished app.

Junior elementary: Grades 4–6

Emphasis: loops, nested structure, geometric construction, growing patterns, variables as changing quantities, data tables and constraints.

Evidence might include creating a repeated geometric design, generalizing a growing pattern, comparing candidate solutions in a fixed-perimeter problem, or explaining why a loop stops. Learners begin to record test cases and distinguish an example from a general rule.

Intermediate: Grades 7–9

Emphasis: decomposition, variables and parameters, conditions, transformations, simulation, data relationships, line fitting, model limits and multi-step debugging.

Evidence might include modelling a distance or cost relationship, adapting a simulation, auditing a misleading visual, tracing changing state or testing an algebraic model at boundary values. Grade 9 work can connect explicitly to MTH1W without pretending this framework is the course.

Secondary: Grades 10–12

Emphasis: functions, structured data, modular design, spreadsheets and text-based code, research and source evaluation, privacy/security, reproducibility, AI-output auditing and projects with real users or constraints.

Evidence might include a transparent comparison tool, a data investigation with limitations, a mathematical simulator, an accessibility repair, or a small automation with failure handling. A sophisticated interface is optional; an inspectable decision trail is required.

Postsecondary and adult learners

Emphasis: disciplinary application, unfamiliar systems, data provenance, collaboration, version history, documentation, maintainability, professional judgement and the boundary between assistance and authorship.

Tasks should fit the learner's actual context: auditing a formula-heavy spreadsheet, cleaning a small public data set, testing a model, documenting an analysis, automating a repetitive task, or evaluating an AI-supported workflow. Do not send every adult through child-themed projects to prove the same prerequisite.

Entry diagnostic: forty-five to ninety minutes, low stakes

The diagnostic is a map for instruction, not an IQ test or disability screen. Record the tool, time, language, access supports, references and prompts used.

Task 1: instructions and ambiguity

Give a familiar goal—navigate a grid, organize a morning routine or transform a simple shape. Ask the learner to write or arrange precise steps. Follow them literally and ask for a repair.

Reveals: sequencing, assumptions, communication and response to feedback.

Task 2: predict and trace

Show a short block, pseudocode, spreadsheet formula chain or text program. Ask for the output and a line-by-line table of changing values before execution.

Reveals: mental model, variable tracking and whether recognition depends on running the tool.

Task 3: build from a neutral start

Give a small task drawn from familiar content, with an empty page/file and documentation or syntax card available.

Reveals: planning, recall of structure, tool control and productive use of references.

Task 4: diagnose a seeded bug

Insert one conceptual error—not a trick typo. Provide the intended behaviour and one failing example. Ask the learner to locate the first divergence, explain it and repair it.

Reveals: debugging strategy rather than random editing.

Task 5: transfer

Change one meaningful constraint: size, starting value, representation, input range, audience or tool. Ask what must change and what remains invariant.

Reveals: abstraction and flexible understanding.

Task 6: audit a generated answer

Provide a plausible answer containing one mathematical, evidentiary, privacy, accessibility or logic problem. It may be human- or AI-generated. Ask for claims, checks, sources and a corrected version.

Reveals: critical digital and AI literacy. Do not require AI use to assess AI literacy.

Task 7: teach-back and assistance map

Ask the learner to explain one decision in their preferred communication mode and mark each source of help.

Reveals: ownership, metacognition and communication—not speaking performance.

Diagnostic record

For each task, record:

Nine modules

Each module can be compressed, expanded or revisited. The framework is spiral-shaped: later projects reuse earlier thinking.

Module 1: Instructions, algorithms and representations

• Define an algorithm as a finite, ordered process for a purpose.
• Move among words, diagrams, tables, equations, flowcharts and code.
• Identify ambiguity, missing cases and assumptions.
• Compare two correct processes for clarity or efficiency.

Assessment: create and revise instructions for a fresh task, then explain one representation change.

Module 2: Decomposition, patterns and abstraction

• Break a large goal into testable subproblems.
• Identify repetition and relationships.
• Separate essential structure from surface detail.
• Generalize from several examples without treating examples as proof.

Assessment: adapt a known pattern to a changed context and name what stayed invariant.

Module 3: Data and representation

• Distinguish a question, variable, observation and data value.
• Collect or use data with attention to provenance and consent.
• Choose tables and visual forms that match the question.
• Notice missingness, misleading scales, selection effects and overclaiming.

Assessment: create one honest representation and audit one misleading alternative.

Module 4: Code, control and changing state

• Use sequence, repetition, conditions, variables, parameters and functions at an age-appropriate level.
• Predict state before running.
• Connect code to mathematical or real-world meaning.
• Use blocks, pseudocode, spreadsheets or text code according to the target and access needs.

Assessment: build from a neutral start, trace execution and modify one constraint.

Module 5: Testing, debugging and uncertainty

• Define expected behaviour before testing.
• Choose normal, boundary, invalid and counterexample cases.
• Find the first mismatch rather than patching the final symptom.
• Distinguish a passed test from proof of correctness.
• Document remaining uncertainty.

Assessment: repair a seeded conceptual defect and justify the test set.

Module 6: Mathematical modelling and decision making

• Name purpose, quantities, assumptions and constraints.
• Build a simple model and compare it with reality.
• Explore how changing parameters affects conclusions.
• Communicate what the model leaves out and who could be affected.

Assessment: use a model for a decision, then identify a condition under which it should not be trusted.

Module 7: Digital research, organization, privacy and security

• Search with a clear question; prefer primary authority for rules and current facts.
• Record title, owner, date, URL and the claim supported.
• Organize files, names, versions and backups so work can be reproduced.
• Minimize personal data; recognize phishing, unsafe permissions and credential risks.
• Design documents and interfaces for accessible use.

Assessment: produce a short sourced brief and a reproducible folder or version trail.

Module 8: AI literacy and responsible tool use

• Explain in age-appropriate terms that generative systems produce outputs from learned patterns and can be wrong.
• Separate fluent wording from evidence.
• Protect private or confidential information.
• Examine bias, representation, labour, environmental and human-accountability questions at an appropriate depth.
• Use AI for questions, hints, critique or alternatives without outsourcing the target capability.
• Cite or disclose use according to the teacher's or institution's rules.

UNESCO's AI Competency Framework for Students provides a current external reference for human-centred, ethical, technical and design competencies. Math101's module is an adaptation, not a UNESCO certification.

Assessment: audit an output, verify consequential claims through sources or calculation, revise it and document the tool's role.

Module 9: Independent project and portfolio defence

• Frame a problem that is small enough to finish and meaningful enough to test.
• Define users, constraints and success evidence.
• Keep early attempts, decisions, failures and revisions.
• Obtain consent before using another person's data, story or image.
• Test with users or realistic cases where safe.
• Present the result, limitations, assistance record and next version.

Assessment: product plus process portfolio plus a short defence in an accessible communication mode.

A sample ten-week implementation

Use this as a planning template, not a claim that every learner reaches every level in ten weeks. Eight-week programs can combine adjacent weeks; twelve-week programs can add guided practice and a second transfer task.

Recommended rhythm for each week:

• one short retrieval or trace from earlier learning;
• one explicit model with the teacher thinking aloud;
• guided practice with immediate feedback;
• one independent attempt;
• one transfer, audit or explanation;
• a two-minute assistance and reflection log.

Research on retrieval does not justify turning every lesson into a high-stakes quiz. In controlled experiments, recalling previously studied material improved delayed retention more than restudying it, even when restudy felt more fluent. See Roediger and Karpicke, *Test-Enhanced Learning*. Here, brief retrieval is used as learning evidence and practice; it is not a complete theory of instruction.

Assessment system: product, process and fresh performance

Use three evidence channels:

1. Product

What does the solution do? Is it accurate, usable, accessible and appropriate for its stated purpose?

2. Process

How was it made? Inspect the plan, source notes, prediction, drafts, version history, test cases, debugging record, feedback and assistance log.

3. Fresh performance

What can the learner now do in a small new task? Use a changed constraint, delayed recreation, trace, seeded bug or explanation. This protects both the learner and assessor from confusing polished assistance with independent capability.

Do not average everything into one mysterious percentage. Report at least:

• the capability and rubric level;
• the conditions and accommodations;
• a short evidence citation to the portfolio item;
• what is secure, emerging and next;
• whether the demonstration was guided, independent or collaborative.

Ontario's Growing Success remains the official provincial assessment-policy source for Ontario schools. This Math101 system is a proposed enrichment and tutoring structure; a school must apply its governing policy and professional judgement.

AI, calculator and code guardrails

The goal is not to ban useful tools. It is to prevent a tool from silently replacing the capability being claimed.

Declare the task mode before work begins

Calculator rule

A calculator is appropriate when arithmetic is not the target and the learner can estimate, choose the operation, interpret the display and detect an implausible result. Delay it when the assessment specifically targets an arithmetic fact or procedure. Never infer weak reasoning from use of an approved access tool.

Code-assistant and autocomplete rule

During learning or production, generated suggestions may be useful. Require prediction, line-level explanation where material, tests, changed constraints and disclosure. During an independent demonstration, turn off solution-generating features unless operating them is the capability being assessed.

Generative-AI rule

Before use, ask:

1. Does the teacher, school, employer or client permit it for this task?
2. Would entering this information expose personal, confidential, copyrighted or protected material?
3. Which thinking must remain the learner's?
4. How will claims, calculations and citations be verified?
5. How will the use be disclosed?

After use, the learner annotates what they accepted, rejected and changed. A confident explanation after reading an answer is weaker evidence than a delayed, fresh solution.

UNESCO's Guidance for Generative AI in Education and Research supports age-appropriate, privacy-conscious and human-centred governance. Local rules control actual submissions.

Accommodations that preserve independence

The Ontario Human Rights Commission's accessible-education policy explains that accommodation must be individualized and support equal participation while bona fide academic requirements remain. A generic framework cannot prescribe an individual's accommodation plan; involve the learner, family where appropriate, school and qualified professionals.

Ask four questions before approving or rejecting a support:

1. What exact capability is being assessed?
2. Which part of the task is an irrelevant barrier?
3. Could the support perform the essential reasoning instead of providing access?
4. What condition should be recorded so the result is interpretable?

Examples:

• If assessing algorithm design, a syntax card can remove a memory barrier.
• If assessing debugging, a screen reader can provide access; another person identifying the faulty line would replace the target reasoning.
• If assessing explanation, AAC, signed, typed, diagrammed and spoken responses can all be valid.
• If assessing collaboration, role assignment can provide access, but the portfolio must show each contribution.
• If assessing AI-output audit, AI may generate the sample being audited; it should not generate the learner's audit.

Portfolio specification

Create one folder or binder per learner with:

1. Profile and consent: preferred name, goals, accessibility plan, privacy boundaries and approved tools—no unnecessary diagnosis details.
2. Baseline: dated diagnostic samples and conditions.
3. Plans and representations: sketches, tables, algorithms and success criteria.
4. Build history: meaningful versions, not only the polished final file.
5. Prediction and test log: expected/actual outcomes, edge cases and unresolved issues.
6. Debug record: first mismatch, hypothesis, change and result.
7. Sources and data record: source owner, title, date, link, supported claim, permissions and provenance.
8. Assistance ledger: person/tool, date, prompt or help type, what was accepted and how it was verified.
9. Accessibility note: supports used and why they did not replace the target capability.
10. Transfer samples: at least one changed-context task and one delayed demonstration.
11. Audit: critique of a claim, model, visualization, code sample or AI output.
12. Reflection: what became independent, what still needs guidance and the next deliberately small target.

Minimal assistance ledger

The ledger is not a confession sheet. It makes collaboration honest and lets progress become visible as help is faded.

Parent checklist

Before the program:

• We know this is not an Ontario credit or certification.
• The learner helped set a meaningful goal.
• Access needs, privacy boundaries and permitted tools are documented.
• We will value explanation and revision, not just polish or speed.

During the program:

• I ask “What did you predict?” and “How did you test it?” before “Is it finished?”
• I do not take the mouse or write the essential step to end frustration quickly.
• I can distinguish a hint, example, collaboration and completed solution.
• AI and adult help appear in the assistance ledger without shame.
• The workload remains age-appropriate and does not crowd out sleep or core school obligations.

At review:

• I can see a fresh or delayed performance, not only a showcase project.
• The report names conditions and specific capabilities.
• A changed-constraint task demonstrates transfer.
• The next goal is small enough to teach and observe.
• We are not using “independent” to mean “no accommodations.”

Teacher or tutor checklist

Planning:

• Write the target as an observable capability.
• Identify prerequisite knowledge and irrelevant access barriers.
• State task mode and tool rules before work begins.
• Prepare a model, guided practice, independent task and transfer task.
• Choose accessible tools and an alternative if the first tool blocks participation.

Evidence:

• Collect prediction, process, product and fresh-performance evidence.
• Record prompt level instead of quietly over-scaffolding.
• Use conceptual seeded bugs, not “gotcha” syntax errors.
• Ask for normal, boundary and invalid tests where appropriate.
• Separate individual and group evidence.
• Audit citations and AI-generated claims before publication.

Feedback:

• Name the first successful decision and first breakdown.
• Give one actionable next step.
• Fade help and recheck on a new example.
• Report limitations and conditions honestly.
• Escalate accommodation questions through the appropriate school process rather than improvising a denial.

What this framework does not claim

• It is not an official Ontario curriculum document.
• It is not a school, inspected private school, course code, transcript entry, microcredential or OSSD credit.
• “Aligned with” an expectation does not mean “approved by” the Ministry of Education.
• Completion does not establish university readiness, professional competence or employability by itself.
• The rubric has not been presented here as a psychometrically validated standardized test.
• A ten-week outline does not guarantee a fixed level of progress.
• A portfolio can still contain heavily assisted work; fresh performance and disclosure make interpretation stronger, not perfect.
• The research cited supports design choices at a general level. It does not validate the entire Math101 framework as an evaluated intervention.

Ontario explains that private high schools may grant OSSD credits only when inspected and authorized to do so; non-inspected providers cannot award those credits. See the Ministry's private-schools page. For a proposed credit, ask the student's school or board for the exact course code, authorized provider, curriculum policy, hours, assessment plan and transcript process before enrolment or payment.

One-page implementation record

Use this at the start of any cycle:

Learner and date: Age band / context: Meaningful goal: Target capability: Current rubric level and evidence: Next rubric level: Tool and task mode: Permitted references, calculators, collaboration and AI: Accessibility supports: Privacy/data boundary: Independent demonstration: Transfer task: Portfolio artifacts: Review date: Credit status: non-credit Math101 framework unless separately documented by an authorized school.

Bottom line

Digital fluency is not the ability to make a machine produce something impressive. It is the ability to keep human purpose, reasoning, evidence and responsibility visible while using tools well.

Start at the learner's actual level. Teach explicitly. Allow access. Fade intellectual help. Test a fresh case. Keep the process. Credit every source of assistance. Then move from recognize to guided, independent, transfer, explain/audit and create one capability at a time.

Sources

• Ontario Ministry of Education: Math curriculum for Grades 1–8 — official curriculum overview and coding progression.
• Ontario Ministry of Education: Curriculum and Resources — current official curriculum portal.
• Ontario Newsroom: Modernized Grade 9 mathematics — official Grade 9 coding and modelling context.
• Ontario Ministry of Education: Growing Success — provincial assessment, evaluation and reporting policy source.
• Ontario Ministry of Education: Private schools — official explanation of inspection and authority to grant OSSD credits.
• Ontario Human Rights Commission: Policy on accessible education for students with disabilities — accommodation, individualization and bona fide academic requirements.
• W3C: Web Content Accessibility Guidelines 2.2 — digital accessibility standard.
• UNESCO: AI Competency Framework for Students — external AI competency framework.
• UNESCO: Guidance for Generative AI in Education and Research — privacy, inclusion, human agency and age-appropriate use.
• Long and Magerko: What Is AI Literacy? — research synthesis of AI-literacy competencies.
• Wing: Computational Thinking — foundational computational-thinking article.
• Scherer, Siddiq and Sánchez Viveros: cognitive benefits meta-analysis — evidence and limitations concerning programming transfer.
• Scherer, Siddiq and Sánchez Viveros: programming instruction meta-analysis — evidence on instructional approaches and conditions.
• Roediger and Karpicke: Test-Enhanced Learning — experimental evidence on retrieval and delayed retention.
• K–12 Computer Science Framework — external map of computer-science concepts and practices; not Ontario policy.