Year 11 · 120 minutes · Security
What must be true before a proposed action is allowed?
An assistant’s proposed action must pass several independent checks. Parsing establishes valid syntax. A schema checks fields, types and ranges. Authorisation checks whether the requested action is permitted for this actor and context. A well-formed booking for someone else can pass syntax and schema while failing authorisation. This lab runs a local dry-run validator, never a real booking or external tool.
Schedule two sessions. Read the fictional room-booking schema: room, duration, owner and action. Establish a fixed actor and allowed rooms. Rehearse malformed syntax, wrong types, extra fields and a different owner.
Read JSON and apply type, range and permission checks. Useful earlier investigations: y7-pipeline, y10-injection 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.
Queensland Digital Solutions 2025 v1.4: Unit 4 · objective 2, Unit 4 · objective 4, Unit 4 · objective 6, Unit 4 · objective 7. 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.
Sort examples into syntax, shape and permission failures.
Ask: “Does being a valid object prove the actor can perform it?”
Listen for: “No, structure and permission are different.”
Before validation, name the first gate that will reject each supplied payload.
Ask: “Why record the first failing stage?”
Listen for: “It makes the reason reproducible and helps avoid vague errors.”
Change one JSON field at a time and inspect parsed values, schema findings and authorisation result. Preserve fixed actor context.
Ask: “Can an extra owner field silently change who is acting?”
Listen for: “It should not; actor identity comes from trusted context.”
Submit well-formed schema-valid data requesting another owner’s action.
Ask: “Which gate must stop it?”
Listen for: “Authorisation, even though earlier checks pass.”
In session two, define ranges, reject unknown fields, test missing values and boundary durations, then replay a benign allowed case. Write a human confirmation rule for consequential actions.
Ask: “How do you avoid making safety a reason to reject every useful request?”
Listen for: “Test authorised success as well as failures.”
Present contract, test cases and dry-run traces, documenting how identity would be established in production.
Ask: “What does this browser not prove about real authentication?”
Listen for: “It uses a fixed synthetic actor and has no identity service.”
Valid JSON means a safe action.
Identify whether each payload fails parsing, schema or authorisation before running the validator.
A syntactically and structurally valid request for another owner passes early gates but must fail authorisation.
Create a bounded schema and least-privilege policy with tests for authorised success, extra fields, boundary values and forbidden owners.
Check learners cannot authorise themselves by editing a payload field. Require separate tests for each gate and a valid success path.
Use supplied payloads before free editing; show line-level syntax errors and a schema table.
Specify an idempotency key and replay policy to prevent a valid request from causing duplicate actions.
A tool contract and a replayable gate-by-gate validation suite.
All bookings are fictional dry runs. No messages, reservations or payments occur. Never enter real tokens or credentials. Senior syllabus connections require local confirmation.
Enumerate thousands of parsed-payload mutations with varied durations, owners and extra fields. Use GPU aggregation to separate schema-valid and authorised counts; JSON parsing remains visible in the browser lab.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| Gate reasoning | Confuses parsing with permission | Identifies each gate’s responsibility | Finds a trusted-context boundary violation |
| Contract design | Validates only the happy path | Tests types, ranges and authorisation | Rejects unknown fields, tests boundaries and documents identity assumptions |
Queensland Digital Solutions 2025 v1.4
References: Unit 4 · objective 2, Unit 4 · objective 4, Unit 4 · objective 6, Unit 4 · objective 7. Read the current source (checked 2026-09-07).
Evidence to assess: Data exchange specification, executable validator and failed-case evidence.
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. A supporting classroom task, not a QCAA-approved assessment instrument. Teachers must set their own assessment conditions and confirm alignment with their course. Other jurisdictions require local mapping.
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: Read JSON and apply type, range and permission checks. Ask the learner to demonstrate it before choosing the level of support.
Preparation: allow about 25 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.
Parse JSON; validate required fields, exact types, range, extra fields and an independent action allowlist.
Starting parameters: Allowed actions = read, Required fields = action,duration, Maximum duration = 30, Reject extra fields = True
4 cases calculated from your supplied inputs. Compare the evidence with your prediction.
| case | accepted | issues |
|---|---|---|
| 1 | True | All declared checks passed |
| 2 | False | Action not permitted |
| 3 | False | Duration type or range |
| 4 | False | Extra extra |
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 case: 1; accepted: True; issues: All declared checks passed.” 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, case: 1; accepted: True; issues: All declared checks passed. I can trace it using this mechanism: Parse JSON; validate required fields, exact types, range, extra fields and an independent action allowlist. 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: Author a schema and permission policy. Test a valid action, extra field, wrong type and unauthorised action. Require the original and changed evidence and this boundary: This is a small explicitly declared schema, not a complete JSON Schema implementation.
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.