A cloud lab someone else can rerun
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract.
Coding onramp · 4h estimated · six activities
Before you begin
- Coding onramp; inspect the worked fixture before beginning.
- A text editor/spreadsheet for the manual route. Hosted Python/Jupyter for code exercises; applicable dependencies are in requirements.txt.
- For actual AI calls, a legitimate available cloud service and authorised learner credentials; no particular provider or country is mandatory.
Free original, non-accredited practice. Self-review is not independent assessment. No particular provider, payment platform or country is mandatory; use a legitimate available route or explicitly labelled manual practice.
Open a fresh runtime
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Record runtime version, inputs and access constraints before executing any cell. Inspect the supplied input before using any tool. Write the decision rules in your own words and calculate one small result independently. The reference output is an answer key for this deliberately bounded fixture, not proof of general capability. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run.
Worked example
SOURCE (authored fixture):
{
"rows": [
{
"id": "a",
"amount": 12
},
{
"id": "b",
"amount": 0
},
{
"id": "c",
"amount": "unknown"
},
{
"id": "d",
"amount": 8
}
]
}
INDEPENDENT FIXTURE TARGET:
{
"accepted": 3,
"rejected": [
"c"
],
"total": 20
}Your practical task
- Record runtime version, inputs and access constraints before executing any cell.
- Open input.json and expected.json from the practice pack; keep an unmodified original.
- Record a manual prediction and the relevant rule before consulting the answer key.
- Perform one small change and predict its effect before rerunning.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Open a fresh runtime — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- Restart the hosted runtime: the same supplied input must still total 20.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Separate data from secrets
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Read the fictional rows as data; use a runtime secret only for an optional hosted API call. Establish a baseline before changing prompts or code. Keep the original input immutable. Record expected values, observed values and whether each comparison passed. If the expected file conflicts with a justified policy, investigate rather than forcing a convenient match. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
Worked example
MANUAL BASELINE / compare every named field
{
"accepted": 3,
"rejected": [
"c"
],
"total": 20
}
Keep a separate observed-result column; the answer key is not a model response.Your practical task
- Read the fictional rows as data; use a runtime secret only for an optional hosted API call.
- Open input.json and expected.json from the practice pack; keep an unmodified original.
- Record expected and observed values separately; explain every mismatch.
- Perform one small change and predict its effect before rerunning.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Separate data from secrets — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- Change amount 8 to 9: expected total becomes 21.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Build a pure preparation cell
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Return accepted counts and totals before requesting any narrative. Build one inspectable transformation or bounded AI prompt. Keep calculation and validation deterministic where possible. If you make a permitted hosted call, save the actual response separately from the authored examples and verify its material claims; the supplied reference never simulates a live model. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
Worked example
PROJECT CONTRACT:
Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
HOSTED REFERENCE: open hosted-lab.ipynb or run reference.py with all fixture files together.
EXPECTED CONSTRUCTED RESULT:
{
"accepted": 3,
"rejected": [
"c"
],
"total": 20
}Your practical task
- Return accepted counts and totals before requesting any narrative.
- Open hosted-lab.ipynb and the reference code from the practice pack; keep an unmodified original.
- Record expected and observed values separately; explain every mismatch.
- Perform A missing credential must skip a live model call, not invent a response.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Build a pure preparation cell — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- A missing credential must skip a live model call, not invent a response.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Restart and rerun
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Run every cell in order after a restart and compare the deterministic result. Change one assumption at a time and predict the result first. Retain the failure, the revision and the rerun evidence. A failure is useful information: hiding a bad output or editing a test target after seeing the answer destroys the value of the experiment. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
Worked example
CHANGE TESTS — predict before running: 1. Restart the hosted runtime: the same supplied input must still total 20. 2. Change amount 8 to 9: expected total becomes 21. 3. A missing credential must skip a live model call, not invent a response. Keep the original expected.json unchanged.
Your practical task
- Run every cell in order after a restart and compare the deterministic result.
- Open failure-tests.md from the practice pack; keep an unmodified original.
- Record expected and observed values separately; explain every mismatch.
- Perform Restart the hosted runtime: the same supplied input must still total 20.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Restart and rerun — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- Restart the hosted runtime: the same supplied input must still total 20.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Hand a notebook to someone else
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Remove private paths and provide an explicit no-service fallback. Review what the fixture cannot establish. Explain who owns the decision, where human approval is needed and which access or professional constraints remain. Do not describe a small educational success as production readiness, certification, legal compliance or a guarantee. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run.
Worked example
REVIEW BOUNDARY: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs. ACCESS / NOT TESTED: unavailable provider, unsupported language and absent external feedback must remain explicit.
Your practical task
- Remove private paths and provide an explicit no-service fallback.
- Open README.md and your evidence log from the practice pack; keep an unmodified original.
- Record the human decision owner, limitations and any untested service access.
- Perform one small change and predict its effect before rerunning.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Hand a notebook to someone else — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- Change amount 8 to 9: expected total becomes 21.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Ship a reproducibility bundle
A reproducible notebook starts with declared inputs and a clean runtime, not a screenshot. Separate deterministic preparation from an optional hosted model call. Temporary notebook storage can disappear; retain the original file and the output contract. Package inputs, notebook, results and failure log without credentials. Deliver a reproducible bundle rather than a screenshot alone. Include inputs, rules, output, failure tests, a short README and residual limitations. Ask another person to follow the instructions if possible; self-review and actual external review must be labelled separately. Policy for this project: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
Worked example
HANDOFF MANIFEST: input.json — immutable source expected.json — fixture answer key actual.json — result actually observed evidence-log.csv — baseline plus three changes README.md — reproduction and access route limitations.md — unresolved failures, rights, approvals and scope Never bundle a credential.
Your practical task
- Package inputs, notebook, results and failure log without credentials.
- Open README.md and your evidence log from the practice pack; keep an unmodified original.
- Record the human decision owner, limitations and any untested service access.
- Perform one small change and predict its effect before rerunning.
- Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
Evidence to keep
- Ship a reproducibility bundle — a saved, inspectable artefact tied to the supplied rule.
- A baseline or change-test record with expected/observed results and a limitation.
Mistakes to watch for
- A missing credential must skip a live model call, not invent a response.
- Treating a supplied answer key, an authored example or self-review as independent field validation.
Check your understanding
Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?
No-service / offline route
Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.
Capstone self-review
Score each criterion 0 (missing), 1 (partial), or 2 (demonstrated). A self-review pass needs at least 8/10 and 2/2 on the critical safety/limits criterion. This is learner practice feedback, not verified assessment.
- Defined task and preserved input: Original input and the project policy are retained; the actual question is clear.
- Checked baseline: The supplied baseline reconciles field by field; unsupported live-run claims are absent.
- Three failure/change tests: All three specified changes have predictions, observed results and explanations.
- Repeatable handoff: Another person can follow the README; supporting practice evidence and unresolved limits are included.
- Safety, rights and access honesty — critical: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs. Regional access route is legitimate; credentials and private data are absent; manual/constructed work is clearly labelled.
Review questions
For the supplied fixture, what is the expected accepted?
3
The independent answer key only validates this constructed fixture. Preserve the source, rerun counterexamples, and disclose what was not tested.
How should you handle the project rule: Reject non-numeric amounts; preserve zero; never embed account keys in cells, URLs or exported outputs.
State the rule, test it, and record exceptions or unresolved failures.
Rules, source provenance and counterexamples make an output inspectable; an attractive result does not override policy.
If mainstream providers do not serve your region, what is the honest route?
Check legitimate available alternatives, or label the manual/fixture route and its limits.
Access includes country, identity, language, cost and data terms. Do not bypass restrictions or invent a live result.
Practice files
- README.md
- evidence-log.csv
- expected.json
- failure-tests.md
- hosted-lab.ipynb
- input.json
- lab_engine.py
- reference.py
- requirements.txt
References and editorial limits
Original authored practice material; deterministic fixtures build-tested. Not independently expert-reviewed or learner-validated. Time estimates unvalidated.