Year 7 · 75 minutes · Systems
Can correct code still pass the wrong numbers to a model?
A model’s inputs have a contract: units, order, scale and meaning. This synthetic environmental model expects Celsius but can receive Fahrenheit if a conversion is missing. Each step may run without an error while the complete pipeline gives a wrong result. Inspecting intermediate values and checking a known reference case reveals the mismatch.
Review Fahrenheit = Celsius × 9/5 + 32. Prepare equivalent values 0°C/32°F, 20°C/68°F and 35°C/95°F. Explain that the model is an illustrative linear score, not a real environmental forecast.
Identify a value, its units and its source. Useful earlier investigations: y6-sources Use pairs for investigation, with operator/reviewer swaps after each comparison. Keep individual predictions, journals and a short oral defence so group work does not hide understanding.
Australian Curriculum Version 9 · Digital Technologies: AC9TDI8P03, AC9TDI8P06. Selected aspects only. This activity contributes evidence; it does not cover the full descriptor or achievement standard. A programming descriptor is not claimed for merely moving controls. ACARA AI curriculum connection · V9 Technologies These are planning connections, not ACARA endorsement or exhaustive descriptor alignment.
Pass a paper value through sensor, conversion, normalisation and model stages.
Ask: “Does the number 68 tell us enough without a unit?”
Listen for: “No, 68°C and 68°F mean different temperatures.”
Predict the model result when Fahrenheit bypasses conversion.
Ask: “Which stage first receives an unexpected meaning?”
Listen for: “The normaliser expecting Celsius.”
Change the input unit, follow every intermediate value and compare equivalent temperatures. Toggle conversion only while keeping the physical temperature fixed.
Ask: “Why did no syntax error appear?”
Listen for: “The values were still numbers, just wrong for the contract.”
Load the edge case that converts an already-Celsius value as if it were Fahrenheit.
Ask: “Can adding more conversion make things worse?”
Listen for: “Yes, the conversion must match the actual input unit.”
Specify explicit unit metadata and one conversion boundary. Write checks for three equivalent pairs and an invalid unit.
Ask: “How will a future edit reveal this bug again?”
Listen for: “The reference-pair test will fail.”
Submit a stage trace and regression-test statement.
Ask: “Should we retrain the model to hide a unit bug?”
Listen for: “First repair the contract; otherwise the meaning remains wrong.”
Correct steps always make a correct system.
Send 68°F through a Celsius-trained pipeline without conversion. Predict the direction of the score error.
A double conversion produces valid numbers but incorrect meaning, so simply adding a conversion step is insufficient.
Define a unit-aware boundary and three equivalent-temperature regression tests plus an invalid-unit rejection.
Ask for the first invalid intermediate value rather than only the final error. Check that physically equivalent inputs yield equal model inputs after repair.
Use only 0°C/32°F and a precomputed conversion table before introducing variable temperatures.
Add feature-order and normalisation-version contracts; create a test that catches a swapped-column bug.
A unit-labelled pipeline trace and a regression-test contract.
Only fictional sensor readings are processed. This educational model must not control real equipment or environmental decisions.
Run thousands of Celsius/Fahrenheit equivalence cases through a linear model. Compare missing, correct and double conversion; verify correct-conversion parity within 0.00001 on the selected device.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| Pipeline diagnosis | Blames the final score | Finds the unit mismatch stage | Distinguishes missing from double conversion |
| Contract repair | Patches one numeric case | Defines units and tests equivalent inputs | Adds invalid-unit rejection and a reproducible regression suite |
Australian Curriculum Version 9 · Digital Technologies
References: AC9TDI8P03, AC9TDI8P06. Read the current source (checked 2026-09-07).
Evidence to assess: A unit-labelled pipeline trace and a regression-test contract.
Selected aspects only. This activity contributes evidence; it does not cover the full descriptor or achievement standard. A programming descriptor is not claimed for merely moving controls. Moderate the supplied illustrative responses against your school unit and current achievement standard.
These are planning estimates to test with your class. A short session develops one supported claim; it does not compress the whole senior project.
| Stage | 45 minute focus | 60 minute investigation |
|---|---|---|
| Readiness and prediction | 0–5 | 0–5 |
| Trace the supplied example | 5–13 | 5–15 |
| Author and run cases | 13–25 | 15–35 |
| Counterexample and redesign | 25–35 | 35–45 |
| Explain and discuss | 35–42 | 45–55 |
| Export and handover | 42–45 | 55–60 |
For a longer project, use three 50-minute sessions. Session 1 (0–50): readiness, model, hypothesis and initial cases. Export a project and record the next test. Session 2 (50–100): reopen, check settings, author counterexamples and revise the design. Export the changed project and identify unresolved evidence. Session 3 (100–150): independent peer test, final artefact, individual explanation and moderation. If using two 60-minute sessions, stop at minute 60 after saving the first comparison; use 60–120 for redesign, independent test and defence.
Entry check: Identify a value, its units and its source. Ask the learner to demonstrate it before choosing the level of support.
Preparation: allow about 15 minutes to run the starter, print the cards and check a project can be reopened. This estimate has not yet been measured in a classroom pilot.
Read the entry question aloud, model one row, and label the units. Offer the case table as a large-print sheet. Keep mathematical derivations optional until the learner can explain the comparison.
For one device, use a projector: one pair predicts, one operates, and the class records on paper. Swap roles after the first comparison. For individual access, support keyboard controls and a written table equivalent to each visual. Learners may explain orally or with an annotated diagram. Never require personal data, a recorded voice, or a photograph.
Mixed readiness: if the entry check is difficult, use the linked prerequisite and the first two case cards; retain the same central question. If secure, ask the learner to design an unseen test and state which explanation it could disprove.
Require a finite number, the exact unit and a non-empty source; reject rather than silently convert.
Starting parameters: Expected unit = C
4 cases calculated from your supplied inputs. Compare the evidence with your prediction.
| value | unit | source | accepted | reason |
|---|---|---|---|---|
| 20 | C | sensor-a | True | Contract satisfied |
| 68 | F | sensor-b | False | Unit mismatch |
| C | missing | False | Missing or non-numeric value | |
| hot | C | text | False | Missing or non-numeric value |
These are authored examples, not work collected from children. Assess reasoning using the lesson rubric, not whether the first prediction was correct.
Beginning: “It worked because the result looks right.” This identifies no exact case, control or measurement. Ask the learner to point to one row and say what happened.
Developing: “In the first case I recorded value: 20; unit: C; source: sensor-a; accepted: True; reason: Contract satisfied.” This cites evidence, but does not yet explain how the result follows from the rule. Ask the learner to trace the relevant step.
Secure: “For the first supplied case, value: 20; unit: C; source: sensor-a; accepted: True; reason: Contract satisfied. I can trace it using this mechanism: Require a finite number, the exact unit and a non-empty source; reject rather than silently convert. My result supports a claim about these supplied cases. It does not establish that the same result holds outside them.” Look for an accurate trace, the actual settings and a bounded claim; accept equivalent oral or visual evidence.
Extending: The learner constructs and reruns a new case, reports whether the first explanation survives, and defends a revised design. Use this concrete challenge: Create an input contract with units and a missing-data policy. Supply at least one valid and two invalid cases. Require the original and changed evidence and this boundary: A contract prevents these declared errors only; acceptable conversions must be designed explicitly.
Moderation: first assess independently against each lesson criterion. Compare the exact trace or artefact that led to your judgement. Resolve differences using evidence, not polished language. Keep each learner's individual explanation even when the artefact was produced in a group.