Describe the rule
Inputs are the information a system receives. Rules transform them into outputs. Start with a written example so another learner can predict the result.
Write an input-rule-output diagram.
Good automation starts with a process you can explain without a computer.
Build a small spreadsheet, block-code or text-code tool that supports your project. Test normal inputs, edge cases and recovery from an error.
Inputs are the information a system receives. Rules transform them into outputs. Start with a written example so another learner can predict the result.
Write an input-rule-output diagram.
Choose a spreadsheet or coding tool that matches the task. One clear working rule is more valuable than many unexplained features. Keep versions so you can compare changes.
Build a minimal version and save an example input and output.
Check empty input, unexpected values and boundaries. Explain errors clearly and preserve the user’s work where possible. Do not hide failure behind a success message.
Record at least five tests, including two edge cases.
Readings are 10, 12, 11, 50 and blank. The mean of four observed values is 20.75; the median is 11.5. Blank is missing, not zero. The 50 may be genuine or an error: investigate and document your decision rather than deleting it.
Write your own answer before opening the explanation. Then improve one sentence using what you learned.
The mean becomes 16.6 across five values, changing the claim. A missing-value policy and data dictionary must say what is absent, which units apply and how the summary is calculated.
Build a spreadsheet or block-code version and compare it with hand calculations. Include five tests and a clear error message.
Try programs and simulated sensor inputs in a browser. Use the simulation route without buying hardware.
Public aggregate tables for practising source checks, units and comparisons. Record the year and limitations.
The Builder converts blank input with Number(''), which returns 0. Why can a calculator show a misleading successful result? Write the first validation check.
Scratch space: not saved. Copy useful reasoning into your private workbook.
Choose a fictional club service, a water-data investigation, or an accessible information tool as your capstone. Keep the same problem brief through your budget, prototype, tests, revision and final defence. The crew exercises teach a method; apply that method to your chosen project and explain any adaptation. Simulation is a complete route.
60–90 minutes · Paper or browser · No purchase required
“My cost calculator works for 30 units.”
“What does it do with zero, a blank entry, −2, or the word ‘thirty’?”
Write a prediction before you reveal the worked reasoning.
Build a cost calculator on paper, in a spreadsheet or JavaScript. Inputs: quantity, price and unit cost. Formula: quantity × (price − unit cost). Use the budget lab as a reference result, not as a substitute for your own build.
A variable names a value. Write quantity=3, price=250, unitCost=170. Trace the multiplication to 240. A condition chooses a branch: if quantity is missing, nonnumeric, negative or not whole, show an explanatory error.
Implement the formula and validation in your chosen medium. A function groups that operation; a loop can run the same function on several test rows. Do not use eval or execute user-entered code.
Record expected and actual results for 3, 0, blank, −2, ‘thirty’, and 1.5 units. Zero is valid; blank and the last four invalid cases must not become a believable total. Fix and rerun failures.
Predict a result first. Change an input, compare the output and explain why it changed. These fictional models are learning aids.
Contribution/unit: KES 80.00 Revenue: KES 7500.00 Total cost: KES 8100.00 Surplus / loss: KES -600.00 Break-even: 38 units (check contribution and assumptions)
Tool inputs reset when you leave. Download results or record them in your private mission workbook.
For 3 units at 250−170, the result is 240. For 0 it is 0. Number('') produces 0 in JavaScript, so check an empty string before conversion. A good failure message says which input needs correction. Testing one ordinary example misses that bug.
Finding the answer is not evidence of mastery. Explain it, test a changed input and record your own work.
Extend to two products using a list and a loop. Explain whether prices may contain decimals while quantities must remain whole.
Input | Expected output | Actual output | Pass/fail | Fix Variables and units: Rule or pseudocode: Test 1 normal: Test 2 zero: Test 3 blank: Test 4 negative: Test 5 text: Test 6 fractional quantity:
Choose a twist. Use paper, a sketch or a conversation.
Optional practice. Copy useful observations into your workbook; choosing a twist does not record completion.
Compare ideas with someone you know. Sharing is optional.
Work through Build a rule you can trace with a focused prompt. Your notes stay private unless you choose to paste an excerpt here.
Use fictional examples. Leave out names, contact details, passwords and private records.
Requires an active learning profile. Your provider may charge you; API billing is separate from ChatGPT. EaseBrain has no paid-key fallback.
Key clears after each attempt. EaseBrain saves only a daily request count, not your key, prompt or answer. OpenAI’s data policies apply. Up to 500 output tokens and 20 attempts a day; no automatic retries. These limits do not guarantee a spending ceiling.