brightlab.Made for curious mindsBrightlab
Year 11 · Security
What must be true before a proposed action is allowed?
Go to the investigation ↓A tool contract and a replayable gate-by-gate validation suite.
Take this investigation into Python: open the interactive Marimo notebook →
Does a well-formed action satisfy your contract?
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.
Before this lesson: Read JSON and apply type, range and permission checks. Useful earlier investigations: The number that changed its meaning; When the document gives orders.
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.
Read JSON and apply type, range and permission checks. Useful earlier investigations: The number that changed its meaning; When the document gives orders.
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.
ACARA V9 AI curriculum connection ↗ · Technologies ↗
A complete teaching sequence · 120 minutes
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.
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.
| 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 |
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.
All bookings are fictional dry runs. No messages, reservations or payments occur. Never enter real tokens or credentials. Senior syllabus connections require local confirmation.
Shared device? Turn remembering off. A project file lets you continue on another device.
Your browser is the laboratory
Identify whether each payload fails parsing, schema or authorisation before running the validator.
Trusted actor: class-team. Allowed rooms: reef-room and garden-room. Action must be book; duration an integer 15–120; owner must equal the trusted actor; extra fields are rejected. A valid request for another owner must not pass.
The experiment opens after your prediction.
There is no penalty for being surprised.
Apple Silicon · PyTorch MPS
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.
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 y11-contract-mac-pathway.zip -d y11-contract-mac cd y11-contract-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
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.
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 y11-contract-dgx-pathway.zip -d y11-contract-dgx cd y11-contract-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 tool contract and a replayable gate-by-gate validation suite.
Download the editable handout →