Year 12 · 150 minutes · Governance
What would make a system’s public claims defensible?
An assurance case connects a claim to evidence, assumptions, limitations and accountable owners. This browser graph checks whether required links exist, tests pass and evidence is current under a declared review date. It does not decide that a system is safe or that evidence is persuasive. A passing structural check can still rely on a weak test. Defensible design requires human scrutiny, narrowly worded claims and a route to withdraw them when conditions change.
Plan three 50-minute sessions. Read the fictional assistant release brief and supplied tests, dates and role owners. Fix a review date for reproducible freshness checks. Prepare a panel rubric that rewards honest limitations over a confident launch recommendation.
Distinguish a claim, relevant evidence, an assumption and a defeater. Useful earlier investigations: y11-contract, y12-ablation, y12-govern 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 7, Unit 4 · objective 8. 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.
Read 'The assistant always gives reliable answers' and ask what evidence could support it.
Ask: “Could twenty passing cases justify always?”
Listen for: “No, the claim is broader than the evidence.”
Inspect graph nodes before validation and predict unsupported, failed or stale claims.
Ask: “Which claim depends on an expired test?”
Listen for: “The linked test date is outside the stated review period.”
Connect claims to tests, limitation notes and accountable roles. Edit review dates and inspect validation reasons. Keep the underlying test outcomes fixed during one comparison.
Ask: “Did adding a link improve the evidence itself?”
Listen for: “No, it made the argument traceable but the test may still be weak.”
Use the edge case with all structural links present but only one trivial test.
Ask: “Can a green structural check prove readiness?”
Listen for: “No, relevance and coverage need human review.”
Narrow claims to the evaluated scope, attach failed cases and limitations, specify owners and withdrawal conditions. Add a new peer-designed challenge and revise the launch recommendation accordingly.
Ask: “What observation would make you withdraw this claim?”
Listen for: “A relevant failure, changed conditions or stale evidence beyond the review policy.”
Present a release, limited pilot or stop decision to peers. Answer challenges by navigating to evidence, then record unresolved objections.
Ask: “Who acts if the evidence stops supporting the claim?”
Listen for: “The named owner under the review and withdrawal process.”
A polished demo is enough evidence to deploy.
Identify the graph’s unsupported and stale claims before running its structural checks.
A fully linked, current graph can still rest on one irrelevant passing test; structural completeness is not substantive assurance.
Build a scoped release case linking claims, tests, limits, owners and expiry; defend a recommendation and withdrawal trigger.
Use a viva: ask the learner to navigate from a public claim to its test, limitation and owner. Require a substantive critique even if structural checks pass.
Begin with two claims and three test records. Provide sentence frames for scoped claims and explicit limitations.
Introduce a changed deployment condition and require an impact analysis across every dependent claim before deciding whether the release case remains valid.
A defensible release case with an evidence graph, public claims, limitations, owners and a recorded oral defence.
The release system is fictional and no deployment is triggered by the lab. Use role names rather than personal contact details. Real community work needs school approval and local senior syllabus mapping.
Validate large synthetic claim-evidence graphs, propagate stale or failed evidence through dependency matrices on GPU, and inspect why graph completeness cannot measure argument quality.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| Traceability | Lists evidence without claims | Links claims, tests, limits and owners | Handles freshness, failures and withdrawal |
| Defensibility | Uses a polished demo as proof | Scopes claims to relevant tests | Answers counterarguments and revises the decision from evidence |
Queensland Digital Solutions 2025 v1.4
References: Unit 4 · objective 2, Unit 4 · objective 4, Unit 4 · objective 7, Unit 4 · objective 8. Read the current source (checked 2026-09-07).
Evidence to assess: System/evidence relationships, release criteria and a defended recommendation.
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: Distinguish a claim, relevant evidence, an assumption and a defeater. 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.
Build dependency links by claim ID. Surface unknown links, cycles, failed tests, missing evidence and unresolved defeaters.
Starting parameters: The supplied cases define the inputs.
This is an argument structure check. A green structural result is not a release decision.
| id | claim | dependencies | issues |
|---|---|---|---|
| C1 | Answers stay inside supplied evidence | failed tests; unresolved defeater | |
| C2 | External send is unavailable | Structure complete; relevance still needs review | |
| C3 | Pilot can proceed within scope | C1,C2 | unresolved dependency C1 |
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 id: C1; claim: Answers stay inside supplied evidence; dependencies: ; issues: failed tests; unresolved defeater.” 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, id: C1; claim: Answers stay inside supplied evidence; dependencies: ; issues: failed tests; unresolved defeater. I can trace it using this mechanism: Build dependency links by claim ID. Surface unknown links, cycles, failed tests, missing evidence and unresolved defeaters. 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: Build a claim graph with your own evidence, failed tests and dependencies. Defend a bounded release or a decision to stop. Require the original and changed evidence and this boundary: An internally consistent graph does not establish evidence relevance or truth; independent review remains necessary.
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.