A running total must remember what earlier iterations added. If the program resets that total to zero inside every loop iteration, the next addition starts again from nothing. The loop may run without an error message while producing the wrong answer.
The quick case uses the integer list [4, 7, 2]. Initialise total to zero before the loop, then add each value to the existing total. The successive totals are 4, 11 and 13.
In the faulty version, total is set to zero again at the beginning of each iteration. The recorded totals after addition become 4, 7 and 2. The final output is the last value, not the sum.
That is a logic error rather than necessarily a syntax error. The statements can be valid Python and the program can finish normally. What fails is the relationship between the variable’s intended meaning and the repeated assignments.
For students, the useful move is to state what total should mean after each iteration. It should equal the sum of all values processed so far. A trace then shows exactly where the reset breaks that meaning.
For parents, a three-row paper table is enough to uncover the problem. Ask what value remains just before the next item is added. There is no need to install software or introduce a complicated program.
The official subject reference is the 2027 G3 Computing syllabus, K349, which includes variables, iteration, tracing and debugging. The Python documentation supports the language behaviour used here. The examples and test cases are original educational work, not official questions or model answers.
Our main contract is to output the sum of a supplied list of integers, with an empty list defined to give zero. Input collection and validation are separate tasks. We will also distinguish a full-list total from a count, a running display and totals that intentionally restart for different groups.
Subject references: SEAB 2027 G3 Computing K349 · Python documentation: control flow and for loops. Use the correct examination-year syllabus and school instructions. This guide does not imply that every eduKate branch offers the subject.
eduKateSG · SEC Subject Explainers
Find your next learning step
Choose the question closest to yours, or follow the complete worked guide.
ROUTE 4 · CHAPTERS 12–15
Place resets at the right scope
Handle zero and negative values without changing the meaning
Full chapter index · Practice route · Connected eduKate guides · Broader subject guide
Choose a chapter
Chapters 1–4
Chapters 5–8
Chapters 9–12
Chapters 13–16
Chapters 17–20
Chapters 21–21
The worked case at a glance
| Iteration | Current value | Correct running total | Faulty running total |
|---|---|---|---|
| 1 | 4 | 4 | 4 |
| 2 | 7 | 11 | 7 |
| 3 | 2 | 13 | 2 |
Correct: initialise once for the full calculation
values = [4, 7, 2]
total = 0
for value in values:
total = total + value
print(total)Faulty: reset before every addition
values = [4, 7, 2]
total = 0
for value in values:
total = 0
total = total + value
print(total)CHAPTER 1 OF 21 · Read the calculation contract
1. State what the program must output
Begin with the output contract: given the supplied integer list, produce one final sum of all its values. For [4, 7, 2], that sum is 13.
The phrase all its values matters. A program that returns only 2 has reported a value from the list but has not met the contract. A program that prints 4, 11 and 13 has displayed running totals rather than only the single final result requested.
These may be useful outputs in other tasks. The question determines which is correct here.
Write the expected answer independently before tracing the program. Four plus seven plus two gives thirteen. This provides a reference that does not merely repeat whatever the code happens to produce.
The contract also defines the empty-list result as zero. That choice is appropriate for this sum task, but it should not be copied into every aggregate problem. An empty minimum-value task has different requirements.
A useful first note states input type, required result and output timing. Integers are supplied; every value contributes; one result is produced after processing.
This makes later debugging focused. If the code finishes normally but returns the wrong kind of result, the problem is still real. Correct execution means following the language’s rules; correct output means also satisfying the task. A student should check both instead of treating the absence of an error message as proof that the program has solved the intended problem.
An accumulator is a variable used to combine contributions over repeated steps. In this guide, total stores the sum of the values processed so far.
Before any value has been processed, total is zero. After processing 4, it should be 4. After processing 4 and 7, it should be 11. After all three values, it should be 13.
This meaning is more useful than a vague description such as “the variable for the answer”. It tells us what must be true during the loop, not only at the end.
The update uses the old total and the current value to calculate a new total. It preserves earlier contributions while adding the next one.
If an assignment replaces total with zero during every iteration, that earlier information is lost. The variable may still be named total, but its contents no longer match the intended running-sum meaning.
A good variable name helps, but the assignments determine behaviour. Renaming a faulty variable does not repair the repeated reset.
For a paper trace, write the meaning above the table: sum of processed values. After each row, compare the stored number with that definition. This gives the student a reason to accept or reject a state rather than merely copy numbers from the code. The same method transfers to other accumulators when their meaning is defined clearly, such as a count of qualifying items or a total for one particular group.
CHAPTER 3 OF 21 · Read the calculation contract
3. Understand assignment as a state change
The statement total = 0 assigns zero to the variable. It does not add zero to whatever total previously held. Any earlier value in that variable is replaced.
The statement total = total + value works differently. The right-hand expression uses the current stored total and current value, then assigns the resulting sum back to total.
For example, if total is 4 and value is 7, the expression on the right gives 11. The variable then stores 11. The previous contribution of 4 is included in the new result.
If total is reset to zero immediately before that update, the right-hand expression uses zero instead. It gives 7, not 11. The update statement itself may be correct while its starting state has been damaged.
This is why reading only the addition line is insufficient. The preceding assignments matter.
A useful trace can include total before reset, total after reset and total after addition for the faulty version. Those separate columns reveal exactly where information disappears.
Do not interpret the equals sign here as a timeless algebraic equation that must hold for all values simultaneously. In the program, it is an assignment executed at a particular point. The order changes the state used by later statements. Keeping that sequence clear helps students understand why two valid assignments placed in a different order can produce a different result, even when the same variable names and numbers appear.
CHAPTER 4 OF 21 · Trace the accumulator
4. Place the initial value before the repeated work
For the correct full-list sum, set total to zero once before processing the list. Then repeat only the addition of each current value to the existing total.
The initial zero represents the sum before any elements have contributed. It supplies a defined starting state without discarding later progress.
The loop body should preserve the accumulator’s meaning across iterations. After the first addition, the next iteration should begin with the stored result still available.
In Python, indentation identifies which statements belong to the loop body. A reset indented inside the loop is repeated. A reset placed before the loop at the outer level is executed before that repeated work.
This is not merely a formatting preference. Moving a statement into or out of the loop can change how often it executes and therefore what state the program retains.
For the displayed examples, both versions have an initial total before the loop so that empty input has a defined result. The faulty version additionally resets inside each iteration. That repeated reset is the bug being isolated.
A useful explanation says why the placement matters: total must begin at zero for a new complete calculation, then retain accumulated values until that calculation is finished. The student should not memorise “zero always goes outside” without understanding the scope. Later grouped examples will show that a reset can be correct inside an outer loop when it begins a genuinely new subtotal rather than erase progress within one.
The correct version begins with total equal to zero. The first current value is 4. The update adds 4 to the existing zero, so total becomes 4.
At this point, one list value has been processed. The stored total matches the sum of that processed portion.
A trace row should label the current value and the total after the update. If it also includes a before column, the first before value is zero. Keep the timing convention consistent across rows.
The first iteration does not distinguish the correct and faulty versions in our main case. The faulty version also resets to zero and adds 4, giving 4.
That agreement is useful evidence about testing. A program can look correct at the first step while carrying a bug that appears only when earlier progress needs to be retained.
Do not stop the trace after a convenient matching row. The contract concerns all three values.
A good interim explanation is, “After the first item, total is 4 and should remain available for the next addition.” That last phrase prepares the critical check.
The student’s task is not simply to identify a number that looks plausible. It is to connect the state with its meaning. The first row establishes a correct partial total; the next row will show whether the program uses or destroys that progress. This makes tracing an investigation of the algorithm rather than a mechanical exercise in filling table cells.
The second current value is 7. The correct version enters this iteration with total still equal to 4. It calculates 4 plus 7 and stores 11.
Now two values have been processed. Their sum is 11, so the accumulator’s intended meaning remains true.
The important information is the value carried into the iteration. If total were zero at that point, the program would not be preserving the first contribution.
A useful trace row therefore makes the transition visible: before update 4, current value 7, after update 11. These labels prevent the current item from being confused with the running result.
The loop does not need to reread every earlier value to reconstruct 4. The accumulator stores the combined result needed for the next step.
Do not call 11 the final answer yet. It is the sum of the processed portion, while 2 remains unprocessed. A correct partial result can still be the wrong output if reported too early.
For an explanation, connect state and progress: “After processing 4 and 7, total is 11.” That sentence identifies both which data has contributed and what is stored.
This is the step where the faulty version diverges visibly. The correct program uses 4; the repeated reset discards it. Comparing the two versions here is often more revealing than looking only at their final printed numbers, because it shows the exact moment at which the intended meaning is broken.
The final current value is 2. The correct version enters with total equal to 11, adds 2 and stores 13. All list values have now been processed.
Under the contract, the program outputs 13 once after the loop. The stored total and the required result now refer to the same complete set of values.
The successive after-update totals are 4, 11 and 13. These are partial sums, not three independent answers to the final-output question.
A useful final check calculates the sum separately and confirms that every value appears once. Four, seven and two contribute to thirteen; none is omitted or duplicated.
Do not assume that a rising total is the definition of correctness. It rises here because all values are positive. A later negative-value example will show a correct total decreasing.
The correct explanation concerns inclusion, not direction: after each iteration, total equals the sum of the values processed so far.
For a school answer, state the final output and the reason the placement of the initialisation matters. A bare 13 may answer an output question, but an explanation question needs the relationship between the stored state and the loop.
This completes the main correct trace. The next comparison keeps the same input and addition statement while introducing a repeated reset. That controlled difference makes it possible to identify the cause of the wrong result rather than attribute it vaguely to the loop.
The faulty version sets total to zero at the start of every iteration, then adds the current value. On the first iteration it produces 4. On the second, it discards 4, returns to zero and produces 7. On the third, it discards 7 and produces 2.
The final output is therefore 2. It is the last current value, not the sum of all three values.
The addition statement still adds the current value to total. The problem is that total has just been replaced with zero, so earlier contributions are no longer part of the expression.
A clear trace has a reset column. Before the second reset, the stored value is 4; after it, zero. Before the third reset, the stored value is 7; after it, zero.
This makes the failure local and visible. The student does not need to guess whether Python forgot the list or whether the final print statement is broken.
Do not describe the bug as “the loop only runs once”. It runs three times in this case. The wrong state is recreated on every pass.
A useful explanation says, “Each repeated reset erases the accumulated result before the next addition.” That sentence connects the placement of the assignment to the observed output. It is more accurate than saying that loops cannot hold totals or that all initialisation inside any loop is automatically wrong.
CHAPTER 9 OF 21 · Test the faulty loop
9. Distinguish a logic error from a syntax error
The faulty statements can be valid Python. The loop can visit each item and the program can finish normally. No syntax error is required for the result to be wrong.
A syntax error concerns whether the code follows the language’s form. A logic error concerns whether the executed steps meet the intended task. The repeated-reset case demonstrates the second kind.
This is why a successful run is limited evidence. It shows that execution reached an output under those conditions, not that the output is the required sum.
The connected testing guide develops that broader habit. Here the trace supplies the missing evidence by comparing state changes with an independently known result.
Do not repair a logic error through random punctuation or repeated reruns. Identify the first point where the variable’s contents no longer match its intended meaning.
For [4, 7, 2], that point is the second iteration’s reset, which removes the earlier 4 before adding 7.
A useful debugging note records input, expected output, observed output and the state change that caused the mismatch. This turns “it gives the wrong answer” into a specific diagnosis.
The student can then make a targeted change and retest. Understanding the failure matters because a different input may hide the same bug. A program that happens to output a correct number on one case can still contain the repeated-reset logic that fails when the data changes.
CHAPTER 10 OF 21 · Test the faulty loop
10. Explain the faulty result for any non-empty list
The reset-inside behaviour can be explained beyond the three-item trace. At the start of each iteration, the reset makes total zero. The next update therefore computes zero plus the current value. After that update, total equals that current value, regardless of what earlier items contained.
For any non-empty finite list under this displayed version, the last iteration leaves total equal to the final item. The output follows from the repeated assignments, not from a special property of [4, 7, 2].
This also explains masking cases. If the earlier items happen to sum to zero, the true full sum equals the final item, so the wrong method produces a matching output for that input. The match does not establish correct accumulation.
A useful explanation combines a general statement with one trace. The trace makes the state changes concrete; the statement explains why the same pattern persists when the list changes. This is stronger evidence than checking many similar inputs without identifying the repeated operation that causes the fault.
CHAPTER 11 OF 21 · Test the faulty loop
11. Choose tests that expose lost earlier values
A one-item list such as [4] is not enough to expose this bug. Both versions return 4 because there is no earlier contribution to preserve for a second iteration.
The main list [4, 7, 2] is more revealing. The correct sum is 13, while the faulty output is 2. Earlier values clearly matter.
A two-item case such as [6, 5] also works: the correct output is 11 and the reset version returns 5. This smaller case can make the lost contribution easy to inspect.
Do not choose only cases whose earlier values sum to zero. For [4, -4, 2], the correct sum is 2, which matches the last value. The faulty version also outputs 2, so that case alone masks the bug.
The empty list is another masking case under the displayed versions because total is initialised before the loop in both. No iteration occurs and both output zero.
A useful test set therefore includes more than one nonzero contribution and an expected answer calculated independently. The goal is to separate correct accumulation from last-value behaviour.
Record why each test is chosen. “Tests whether earlier contributions survive into a later iteration” explains more than calling it normal data. This reasoning helps students build evidence that targets the suspected fault rather than collect several inputs that all happen to give the same reassuring result.
CHAPTER 12 OF 21 · Place resets at the right scope
12. Handle zero and negative values without changing the meaning
Zero and negative integers are allowed by the main contract. The accumulator should include them according to ordinary addition, not skip them merely because the total might stop rising.
For [4, -7, 2], the correct successive totals are 4, -3 and -1. The decrease after adding -7 is correct. A running total is not required to be monotonic.
The faulty reset version produces 4, -7 and 2 after its additions, finishing at 2. The distinction remains the same: earlier values were discarded.
For [4, 0, 2], the correct totals are 4, 4 and 6. Adding zero preserves the earlier total. The faulty version resets before the zero and produces zero at that iteration.
This is a useful counterexample to the idea that a repeated zero assignment is harmless because zero is neutral for addition. Adding zero is neutral; replacing the stored total with zero is not.
Keep the operation clear. total plus zero and total assigned zero have different effects.
A student can explain the relationship without relying on positive-only examples: after each update, total equals the sum of the processed values, whether that sum rises, falls or stays the same. That meaning supports a more reliable trace and prevents a visual expectation of steadily increasing numbers from becoming the test for correctness.
CHAPTER 13 OF 21 · Place resets at the right scope
13. Define the empty-list result explicitly
The main contract defines the sum of an empty supplied list as zero. In the correct version, total is initialised to zero before the loop. With no values to process, the loop body does not execute and the final output remains zero.
The displayed faulty version also has an outer initialisation, so it returns zero on empty input. That agreement does not repair the repeated-reset bug for non-empty lists.
If a different faulty program initialises total only inside the loop, empty input may leave no assigned total before the output statement. That is a separate version and should not be confused with the one displayed here.
The distinction matters when diagnosing a question. Read the actual code rather than assume every reset bug has the same empty-input behaviour.
Do not generalise this task’s zero result to every aggregate. A minimum-value function or an average calculation needs its own empty-input contract.
The connected empty-list guide explains why empty and a list containing zero are different states. Here both can produce the same sum while still containing different data.
A useful answer states the result and the reason: zero remains because no additions occur after the defined initialisation. This is stronger than saying that the program ignores the empty list. It identifies a deliberate starting state and shows how the loop’s execution conditions preserve it when no iterations are available.
CHAPTER 14 OF 21 · Place resets at the right scope
14. Keep a total separate from a count
A total adds the values supplied. A count records how many items or qualifying events have been processed. The variables may both change inside a loop, but their updates have different meanings.
For [4, 7, 2], the sum is 13 and the number of items is 3. Replacing the sum update with an increment of one would calculate a count, not the required total.
A clear design might use total and count as separate variables, each initialised once for the same full-list calculation. total increases by the current value; count increases by one per processed item.
Do not call the count an index without checking the convention. After processing three items, a count of three is not the same as the final zero-based index two. The connected index guide develops that distinction.
The point is not to introduce unnecessary variables into a simple sum. It is to preserve each variable’s job when a task later needs both quantities.
A useful annotation states what each update retains. total represents accumulated value; count represents processed-item quantity. If either is reset every iteration, its own earlier progress is lost.
Students can use the same tracing method for both: write the intended meaning, inspect the before and after states and compare them with the processed portion. Clear names and stable meanings prevent a program from returning a plausible number that belongs to a different question.
CHAPTER 15 OF 21 · Place resets at the right scope
15. Distinguish one final output from running totals
If the correct total is printed after every addition, the program displays 4, 11 and 13 for the main list. Those are valid running totals, but the main contract asks for one final sum.
The placement of the output statement therefore matters as well as the placement of the reset. Printing inside the loop and printing after the loop answer different output-timing requirements.
Do not diagnose every multiple-output result as an accumulation failure. The stored totals may be correct while the output format does not match the task.
Conversely, moving the print statement outside does not repair a reset inside the loop. It merely prints the final wrong value once.
A useful debugging approach separates state correctness from output correctness. First check whether total retains all processed contributions. Then check when and how the required result is displayed.
This creates a clear two-part explanation. The accumulator update can be right while the output placement is wrong; either can be repaired without changing the other unnecessarily.
For a school task that actually requests running totals, printing inside may be appropriate. Follow the contract rather than memorise that print always belongs outside a loop. The general principle is the same as for initialisation: placement determines frequency and scope. A statement should execute where its intended job belongs, not where a familiar template happens to put it.
Resetting inside a loop is not always wrong. Suppose a separate task needs one subtotal for each group of values. The subtotal should restart when a new group begins, not before every item within that group.
Use fictional groups [4, 7] and [2, 5]. Their subtotals are 11 and 7. A combined total across both groups would be 18, but that is a different output requirement.
In a nested-loop design, a group subtotal can be set to zero inside the outer group loop and before the inner item loop. It then retains contributions within that group and restarts for the next group.
If reset inside the inner loop, the same lost-progress bug returns: the subtotals become the last values 7 and 5 instead of 11 and 7.
This example explains why “never initialise inside a loop” is too broad. The relevant question is when a new calculation begins and which contributions must remain available.
Keep the separate task labelled. Do not add the groups into the original three-item list without saying the input contract changed.
A useful explanation names the boundary: reset once per group, accumulate once per item. That wording connects code structure to the data structure and prevents a placement rule from becoming an empty slogan. The student can then reason about new grouping problems rather than rely on the appearance of indentation alone.
CHAPTER 17 OF 21 · Practise independently
17. Initialise a new calculation rather than reuse stale state
A full-list sum should begin from the state defined for that calculation. If an earlier calculation left total at 13 and a new list is processed without resetting appropriately, the new result may include stale data.
This is a different placement problem from resetting too often. One version discards progress during the calculation; the other carries progress from a calculation that should already be finished.
For a separate new list [2, 5], the required sum is 7. Starting from an old total of 13 would produce 20 if no fresh initialisation occurs.
The correct boundary is therefore neither “reset everywhere” nor “never reset”. Reset when a genuinely new total begins, then preserve state across the iterations that belong to it.
If the task uses a function, an initialisation within that function can establish a fresh local total for each call. The exact implementation should follow the school task and permitted constructs.
Do not introduce global state merely to solve a small sum problem unless the task requires it. The learning point is to define the lifetime of the accumulator.
A useful design note states which data belongs to one result. Once that scope is clear, the location of initialisation becomes easier to justify. The student can explain why total is zero before the new calculation and why it must not return to zero while values from that same calculation are still being combined.
CHAPTER 18 OF 21 · Practise independently
18. Use the final sum as an input to later calculations carefully
A later task might ask for the average of the supplied values. That requires both the completed sum and the number of values, with an appropriate rule for empty input.
For the non-empty main list, the sum is 13 and the count is 3. The arithmetic mean is 13 divided by 3, approximately 4.33 when rounded to two decimal places.
This extension does not change the sum algorithm’s purpose. First obtain the required total correctly. Then use it in the later calculation according to the task.
Do not divide by the last value 2 as though it were the count. Do not use a reset total that contains only 2 and call the result a valid mean.
Also do not divide by zero on an empty list. The sum contract’s zero output does not automatically define an average for no data. A separate average task needs an explicit empty-input policy.
The extension shows why a small accumulator bug can affect later outputs. A program may run through several valid operations after losing earlier contributions, yet every later result built on the wrong total can be misleading.
A useful debugging strategy checks intermediate quantities at the point they are supposed to become complete. Verify total and count before interpreting a later average. This preserves the meaning of each stage rather than treat a final decimal result as evidence that all earlier processing was correct.
CHAPTER 19 OF 21 · Practise independently
19. Connect tracing with the eduKate learning ecosystem
The test-data guide is the natural companion when a student treats a successful run as proof of correctness. Use it to choose cases that distinguish full accumulation from last-value behaviour.
The empty-list guide clarifies why empty input and a zero-valued item are different even when the sum result matches. The index-and-value guide helps when the loop variable’s role or a count becomes confused with stored data.
The input-validation guide addresses acceptance rules, not the accumulation logic itself. Valid integer data can still be processed incorrectly, so keep input validity and algorithm correctness separate.
Data-response skills help create trace columns with stable meanings. Writing and Revision supports a precise diagnosis. Critical Thinking supports choosing a test that would expose the suspected fault rather than only confirm a convenient example.
Choose one route according to the current obstacle, apply a concrete change and return to the program. The ecosystem is useful when it improves the next trace or test, not when it replaces an independent attempt.
The broader Computing guide and official syllabus provide the subject map and examination-year requirements. This article has a narrower job: explain how repeated assignments can destroy an accumulator’s intended state. Keeping that focus clear gives students a reusable debugging question: what should this variable remember at this point, and which statement changed it?
CHAPTER 20 OF 21 · Practise independently
20. Practise with independent traces and tests
First, trace the correct and reset-inside versions for [6, 5]. The correct total is 11; the faulty final value is 5. Identify the exact assignment that removes the earlier contribution.
Second, use [4, -7, 2]. The correct final total is -1. Explain why a decreasing running total is not evidence of a bug.
Third, use [4, -4, 2]. Both versions finish at 2. Explain why this matching result does not prove that the reset version is correct for all allowed inputs.
Fourth, use an empty list under the displayed versions. Both output zero because both have an initial value before the loop. Distinguish this from a different version that initialises only inside.
Fifth, process the separate groups [4, 7] and [2, 5]. State where a subtotal should reset and why the correct subtotals are 11 and 7.
Finally, write an explanation without merely saying “indentation is wrong”. Name the accumulator’s meaning, the repeated reset and the lost earlier values. A strong answer should connect structure to state. After each test, compare the result with an independently calculated expectation and explain why the input is informative. That turns tracing into evidence about the algorithm rather than a record of whatever output happens to appear.
A running total must preserve earlier contributions until the intended calculation is complete. For [4, 7, 2], initialising once and accumulating gives 4, 11 and 13. Resetting to zero inside every iteration gives 4, 7 and 2 instead.
The program can be syntactically valid while logically wrong. The useful check is whether total equals the sum of the values processed so far at each stage.
Keep placement tied to scope. A new full calculation needs a fresh initial state. A group subtotal can restart at a group boundary. Neither principle justifies erasing progress before every item within one total.
For the next independent attempt, state the variable’s meaning, trace the before and after values and choose a test that makes earlier contributions matter. Then check that the output appears at the point required by the contract.
Use the connected guides and official reference for their different purposes, and follow school instructions for assessed work. The aim is a student who can locate the statement that breaks the intended meaning, make a targeted repair and verify it with evidence. That is more reliable than rerunning valid-looking code and hoping a plausible final number means the loop has done the right job.
Continue learning across eduKate
Choose the skill that addresses the current difficulty, apply one change, then return to the subject task.
| Connected guide | Learning purpose |
|---|---|
| English Across School Subjects | Distinguish current value, total, index and count. |
| Data-Response Questions | Keep one row per iteration and preserve the state between rows. |
| Critical Thinking | Choose tests that can reveal a fault, including cases that mask it. |
| Writing and Revision | Explain why a reset changes the output rather than simply moving code. |
| Learning Transfer | Apply the state-and-scope method to grouped calculations. |
Continue with the right subject route
Test data and debugging: inspect more than a successful run
Empty lists: define the task before choosing an answer
Indexes and stored values: track different quantities
Broader subject introduction · SEC all-subject syllabus directory
Bring the actual task, an independent attempt and teacher feedback to a learning discussion. This guide does not promise a grade outcome or advertise an unverified class offering.
Sources and scope
Python documentation: control flow and for loops
The references establish subject scope and the limited background identified in the text. All worked cases and practice situations here are original educational explanations, not official questions, specimen answers or a marking scheme.
Continue this four-part subject series
G2/G3 Design & Technology: Why a Timer Is Not Automatically Feedback Control
G2/G3 Nutrition & Food Science: Why an Emulsion Is Not the Same as a Solution
G2/G3 Art: Why a Colour Palette Is Not Yet a Colour Strategy