brightlab.Made for curious mindsBrightlab
Year 12 · Governance
What would make a system’s public claims defensible?
Go to the investigation ↓A defensible release case with an evidence graph, public claims, limitations, owners and a recorded oral defence.
Take this investigation into Python: open the interactive Marimo notebook →
What evidence would justify this particular release claim?
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.
Before this lesson: Distinguish a claim, relevant evidence, an assumption and a defeater. Useful earlier investigations: Valid JSON, invalid action; Which change earned the improvement?; Who gets a say before launch?.
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.
Distinguish a claim, relevant evidence, an assumption and a defeater. Useful earlier investigations: Valid JSON, invalid action; Which change earned the improvement?; Who gets a say before launch?.
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.
ACARA V9 AI curriculum connection ↗ · Technologies ↗
A complete teaching sequence · 150 minutes
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.
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.
| 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 |
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.
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.
Shared device? Turn remembering off. A project file lets you continue on another device.
Your browser is the laboratory
Identify the graph’s unsupported and stale claims before running its structural checks.
Three claims concern grounded answers, no external-send capability and current evidence. Tests: answerability 18/20 passed, permissions 6/6 passed, evidence expires after day 10. Review begins on day 5; some links and all owner/limitation fields are missing.
The experiment opens after your prediction.
There is no penalty for being surprised.
Apple Silicon · PyTorch MPS
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.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download Mac Studio investigation ↓unzip y12-assurance-mac-pathway.zip -d y12-assurance-mac cd y12-assurance-mac bash setup-mac.sh source .venv/bin/activate python experiment.py --device mps --output results marimo edit notebook.py
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
NVIDIA DGX Spark · PyTorch CUDA
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.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download DGX Spark investigation ↓unzip y12-assurance-dgx-pathway.zip -d y12-assurance-dgx cd y12-assurance-dgx bash run-dgx.sh # Open the localhost notebook URL printed by the container.
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
A defensible release case with an evidence graph, public claims, limitations, owners and a recorded oral defence.
Download the editable handout →