Valid input meets the rules the program checks. Accurate data correctly represent the relevant fact or source. An input can satisfy the first condition and fail the second.
That is the quick answer in this G3 Computing explainer. If a quantity field accepts whole numbers from one to six, an entered five can pass the check even when the original request was for three. The validation rule has not established what the person actually intended.
The official SEAB 2027 G3 Computing syllabus K349 includes input validation and action on invalid data, alongside testing and debugging. This article develops the limits and purpose of validation through an original classroom case. It is not an official specimen question, a full software specification or an examination marking scheme.
Our fictional system records quantities for a paper-based classroom materials request. It uses invented item codes and no personal information. The main practice rule accepts one digit from 1 through 6. Blank input, letters, decimal notation, leading zeroes and surrounding spaces are rejected in this deliberately simple interface.
Those format choices belong to this teaching case. Another system could choose to normalise spaces or accept a different representation, but it would need a clear requirement and appropriate checks.
The source request says quantity 3. Someone enters 5. Five is an allowed value, yet it does not match the source request. We will use that small example to distinguish acceptance, copying checks, source quality and correct processing.
Parents and students can work through the examples entirely on paper. The goal is not to distrust every number. It is to understand what a check establishes, what it leaves open and which next check addresses the actual uncertainty.
Official subject references: SEAB 2027 G3 Computing K349. Use the syllabus for the correct level and examination year, and the school’s instructions. This page does not imply that every school or eduKate branch offers the subject.
eduKateSG · SEC Subject Explainers
Find your next learning step
Choose the question closest to yours, or continue through the complete worked guide.
ROUTE 3 · CHAPTERS 8–11
See why a check digit is not a complete accuracy guarantee
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
The worked case at a glance
| Input or record | Acceptance under the stated rule | Accuracy question |
|---|---|---|
| 3 | Accepted | Matches the supplied source quantity 3. |
| 5 | Accepted | Does not match the supplied source quantity 3. |
| 0 or 7 | Rejected | Outside the allowed set. |
| Blank, x, 03 or 3.0 | Rejected | Does not satisfy the case’s one-digit rule. |
CHAPTER 1 OF 18 · Understand valid and accurate
1. Define validity in relation to explicit rules
A value is valid for a field when it meets the relevant acceptance rules. The rules depend on what the system is intended to do.
In our classroom case, the field accepts one digit from 1 to 6. The rule combines a representation requirement with an allowed range. It does not claim that every real materials request must use those limits.
The value 5 meets the rule. The value 7 does not. A blank entry does not. These decisions can be made without knowing the original requested quantity.
This is the strength and limit of validation. It can check defined properties of the input, but it cannot automatically know every external fact behind that input.
Students should therefore complete the sentence “valid according to…” rather than treating validity as a universal property. A value can be acceptable in one field and unacceptable in another.
For example, 5 may be valid as a quantity in this interface but unsuitable as a month name. The characters have not changed; the purpose and rules have.
A useful written answer identifies the specific rule: “The input is accepted because it is a single digit within the allowed range.” This is stronger than “It is valid because it looks correct.”
Do not add requirements after seeing a difficult case unless the exercise explicitly asks you to revise the design. First evaluate the input against the stated specification.
Parents can ask, “Which rule did it pass?” If the learner cannot identify a rule, the word valid may be functioning as a vague synonym for good.
The central habit is specificity. Validation is valuable because it can apply clear conditions consistently. Its value becomes harder to assess when the conditions are left implicit or when acceptance is confused with truth.
CHAPTER 2 OF 18 · Understand valid and accurate
2. Follow the original request through the record
The fictional source request specifies quantity 3 for an invented classroom item. The input field receives 5.
Both are allowed quantities under the main rule. The validation process can accept 5 without discovering the copying mismatch.
A simple record separates three fields: source quantity, entered quantity and acceptance result. For this case they are 3, 5 and accepted.
The record should not replace the source value with the entered value merely because the program accepted it. That would hide the discrepancy rather than resolve it.
Students can describe the problem precisely: “The entered quantity passes validation but does not match the supplied source request.” The sentence identifies both the successful check and the remaining error.
Do not say that the validation algorithm has necessarily malfunctioned. If its job is to accept digits 1 through 6, accepting 5 is consistent with that job.
The wider system may still need another safeguard, such as a suitable confirmation or comparison with the source. Which safeguard is appropriate depends on the requirements and context.
Our case is deliberately small so that the distinction is visible. It is not a recommendation for managing real orders, purchases or personal records.
A parent can ask the student to point to the evidence for the actual requested quantity. It comes from the supplied source, not from the fact that 5 lies within the allowed range.
Then ask what would happen if the source itself were wrong. A copying comparison could establish a match while leaving the source's accuracy unresolved.
This layered reasoning is useful: acceptance checks the input against rules; a source comparison checks whether it was copied consistently; further evidence may be needed to establish whether the source describes the real situation correctly.
CHAPTER 3 OF 18 · Understand valid and accurate
3. Separate the range from the representation
A range describes allowed values, while a representation rule describes how those values may be expressed. The two questions are related but distinct.
In our case, the allowed quantities are one through six inclusive. The interface also requires a single digit. That is why the text 03 is rejected even though it could represent the number three in another system.
The rejection follows the case's format rule, not a universal law that leading zeroes are always wrong. Some identifiers depend on them, and different systems can define different input formats.
Likewise, 3.0 could represent a whole numerical value after conversion, but this simple interface does not accept decimal notation. Its specification asks for one digit.
Students should avoid assuming that a mathematical equivalence automatically means an interface accepts every equivalent representation. Software must define what forms it recognises and how it interprets them.
Conversely, a system can intentionally normalise input before applying a rule. If that is the design, the normalisation must be understood and tested rather than happening accidentally.
A clear answer might say: “The value is numerically within the intended range, but its supplied representation does not meet this interface's one-digit requirement.”
That sentence separates two reasons that are often collapsed into “wrong type”. It also makes it easier to decide whether the requirement or the implementation needs attention.
Parents can use a paper card with 3, 03 and 3.0. Ask which are accepted in this case and why. The answer should refer to the stated rule.
The broader lesson is that computers operate on representations as well as abstract values. Good requirements make the relationship explicit, and good explanations avoid treating every rejected representation as evidence that the underlying mathematical quantity is meaningless.
The phrase “from 1 through 6” includes both 1 and 6. These values lie at the allowed boundaries and should be accepted under the main rule.
Zero and 7 fall just outside the allowed range. They should be rejected. The exact boundary decisions matter because small comparison errors can exclude valid values or admit invalid ones.
For example, a rule described as greater than 1 and less than 6 would accept only 2, 3, 4 and 5 if restricted to whole numbers. That is not the same range as 1 through 6 inclusive.
A student should translate the words into clear acceptance decisions before considering any code. A small table containing 0, 1, 6 and 7 can expose whether the intended endpoints are understood.
Our interface's one-digit format also rejects negative notation and decimal strings. Those are additional representation decisions rather than reasons to blur the range definition.
Do not assume that a boundary is automatically invalid because it is an edge case. A boundary can be valid or invalid depending on the requirement.
Nor does acceptance at the boundary prove accuracy. If the source requested 3 and the entry is 6, the input remains valid under the range rule while failing to match the source.
Parents can ask, “Does the rule include the endpoint?” This helps the learner focus on the wording rather than guess from familiarity with another exercise.
When a task uses symbols, read them with the same care. Less than differs from less than or equal to. The practical consequence is which inputs are accepted.
The aim is a precise connection among words, conditions and outcomes. Boundary reasoning becomes easier when the student can explain the acceptance decision before running a program, rather than using the program's behaviour as the only guide to what the rule should mean.
CHAPTER 5 OF 18 · Choose the right checks
5. Use a presence check for the right purpose
A presence check asks whether required input has been supplied according to the field's definition. It does not establish that the content is meaningful or accurate.
In the main case, a blank input is rejected. That prevents the system from proceeding as if a required quantity had been entered.
However, the text x is present too. Presence alone does not establish that it is an allowed quantity. Another rule must address its content.
This is a useful example of checks working together. One check answers whether input exists; others address representation and range. Passing one does not imply passing them all.
The treatment of spaces also needs a requirement. In our deliberately simple case, surrounding spaces are rejected rather than silently removed. Another interface might trim them first, but that would be a defined design choice.
Students should not assume that a string containing spaces must count as meaningful input. Nor should they assert that every programming language handles it the same way. The application logic determines what happens.
A good explanation names the limitation: “The presence check catches a missing entry, but it cannot distinguish an allowed quantity from an arbitrary present character.”
Parents can ask the learner to compare three paper inputs: blank, x and 3. All three need to be considered against the full rule, not just the presence condition.
The exercise also shows why a helpful error message matters. If the input is blank, the user needs to know what is required. A message saying only “Error” leaves the next step unclear.
The point is not to maximise the number of checks. It is to choose checks that address specific requirements and understand the question each one answers.
CHAPTER 6 OF 18 · Choose the right checks
6. Use length and format checks without promising truth
A length check concerns the amount of input, such as the number of characters. A format check concerns an expected pattern or structure.
Our simple quantity interface requires one digit from 1 to 6. A length check can reject 03 because it contains two characters. It cannot by itself distinguish 3 from x, because both contain one character.
A format or allowed-character rule can address that distinction. The checks have different purposes even when they contribute to one overall acceptance decision.
For a separate fictional example, an item code might use the letter Q followed by four digits. Q1042 fits that pattern. Q12 and 1042 do not fit the specified structure.
Yet Q1042 could still be the wrong code for the requested item. A pattern match does not establish that the user selected the intended record.
Students should therefore avoid writing “The format check ensures the code is correct” without qualification. It ensures conformity to the defined format, not correctness in every possible sense.
The exact pattern belongs to the fictional example. It is not a standard for real product codes or a claim that all identifiers should have the same length.
A parent can ask the learner to invent two different inputs that both pass the format. This reveals immediately that the check does not identify a unique external truth.
Then ask which additional information would distinguish them for the task. It might be a source request or an appropriate lookup, depending on the requirements.
The broader lesson is that structure is useful evidence about structure. It should not be asked to establish a different property without another argument. Clear explanations preserve that boundary while still recognising the value of rejecting malformed input.
CHAPTER 7 OF 18 · Choose the right checks
7. Understand what an existence check establishes
An existence check can ask whether an input appears in the relevant set of records. In our fictional item-code extension, it could check whether Q1042 is listed in the supplied item table.
If the code is absent, the system can reject it or follow another specified action. This can prevent an unknown code from being treated as a recognised item.
If the code exists, that establishes membership in the checked record set. It does not prove that the code is the one the user intended.
Suppose Q1042 and Q1043 both exist. A user who enters the second when the source request names the first may pass the existence check while selecting the wrong item.
The check also does not automatically establish stock availability, suitability or permission to use the item. Those are different conditions unless the record and requirement explicitly connect them.
Students should name the relevant data source: “The code exists in the supplied item table.” This is more precise than “The code is real.”
The table itself may be incomplete or outdated in another scenario. Our paper exercise can use the supplied table as the defined reference, while recognising that real systems need arrangements for maintaining their records.
Do not invent a missing item or a database error to explain an outcome. Use the information given and identify any relevant uncertainty.
Parents can ask, “Exists where?” That question turns a broad claim into a checkable statement about a particular set.
The aim is to understand the scope of the lookup. Existence is a useful property, but it is not a universal certificate of accuracy, current status or appropriateness. A strong answer says exactly what the lookup confirms and what another check would still need to establish.
CHAPTER 8 OF 18 · Handle the input process
8. See why a check digit is not a complete accuracy guarantee
A check digit is calculated from other parts of a code according to a defined method. It can help detect certain input or transmission errors.
The method matters. Different schemes detect different kinds of error, and a matching check digit is not proof that every character or external fact is correct.
For a deliberately simplified classroom illustration, imagine a three-digit payload whose check value is the last digit of the sum of those three digits. The payload 123 produces a check value of 6.
The payload 132 also produces 6. Swapping those two digits would not be detected by this simple illustrative rule. This is not a recommended real identification scheme; it demonstrates a limitation.
A student should not generalise that all check-digit systems miss exactly the same errors. The example shows only what this stated rule can and cannot distinguish.
Even a stronger scheme does not establish that a correctly structured identifier belongs to the intended person or item. That requires other information and appropriate procedures.
The official Computing syllabus includes check digits among validation methods. This chapter does not prescribe a particular commercial standard or ask students to design a security mechanism.
A useful explanation is: “The check value can reveal some inconsistencies in the code, but matching it does not prove that the selected record is the intended one.”
Parents can ask the learner why two different payloads can share the same check value under the toy rule. The answer comes from the calculation, not from an assumption that the program is unreliable.
The broader skill is to evaluate a check against the errors it is designed to detect. A method can be useful without catching every possible mistake. Understanding that limitation helps students describe its purpose accurately rather than dismissing it or promising too much.
CHAPTER 9 OF 18 · Handle the input process
9. Place checks before the operations that depend on them
A program should not perform an operation on input before establishing the conditions that operation needs. The sequence of checks can therefore matter.
In our simple interface, one sensible paper algorithm first checks whether the raw input has exactly one allowed digit. Only after acceptance does it use the corresponding quantity in later calculations.
If a program attempts an unsafe conversion before checking unsuitable text, it may encounter a run-time problem. The exact behaviour depends on the language and implementation, which this article does not specify.
The educational point is the dependency: an operation may assume something about the input. The program needs to establish or handle that assumption appropriately.
Students can draw a short sequence on paper: receive input, evaluate the acceptance rule, take the specified action, and use the value only if the required condition is met.
Do not confuse this with a universal order for every validation system. Some checks may need parsed values; others concern the raw representation. The design should make those dependencies clear.
For our one-digit case, the accepted set can be stated directly as the characters 1 through 6. There is no need to invent a complicated conversion routine to understand the rule.
Parents can ask, “What has the program assumed at this step?” This often reveals why an error occurs before a later check is reached.
A test should include unsuitable text as well as valid values, because a normal input may never expose the sequencing problem.
The aim is controlled handling. A program should have a defined response when input does not meet an operation's assumptions, rather than relying on the hope that users will always enter the expected form.
CHAPTER 10 OF 18 · Handle the input process
10. Choose the invalid-input action from the situation
Rejecting an input is only part of the behaviour. The system also needs an appropriate next action.
For an interactive classroom exercise, the requirement might ask the user to enter the quantity again after a clear message. For non-interactive input, a task may specify stopping rather than repeatedly asking someone who is not present.
The official G3 Computing syllabus explicitly connects invalid-data handling with the input context. Students should read the actual requirement rather than assume that every program must re-prompt forever.
In our fictional interactive case, a useful message could state the accepted form: “Enter one digit from 1 to 6.” It explains the next step without pretending to know the intended quantity.
The program should not silently replace an invalid 7 with 6 unless that transformation is part of a justified requirement. Such a substitution changes the user's data and may hide the problem.
Likewise, inserting a default 1 can create an apparently valid record that does not reflect the request. A default is a design decision with consequences, not a neutral repair.
Students can evaluate an error path by asking what happens to the invalid value. Is it discarded, retained for a defined purpose, or accidentally used in a calculation?
Parents can ask the learner to follow the path after rejection. If the answer stops at “It says invalid”, the behaviour may not yet be fully understood.
A helpful program response supports correction while preserving data meaning. It does not embarrass the user or make a misleading assumption about what they meant.
The broader lesson is that validation belongs within a process. The acceptance rule, message, retry or exit behaviour and subsequent use of data need to fit together. A correct condition can still sit inside a poorly designed interaction if the next action is unclear.
CHAPTER 11 OF 18 · Handle the input process
11. Use source comparison to address a copying mismatch
To detect the main case's mismatch, someone or some appropriate process needs to compare the entered quantity with the relevant source request.
The source says 3 and the entry says 5. That comparison identifies a discrepancy that the range rule cannot detect because both values are allowed.
This is often discussed as checking or verifying data entry. The important idea is what is compared, not merely attaching a second technical word to the process.
A confirmation screen could show the entered quantity for review, but displaying it does not guarantee that anyone notices an error. The effectiveness depends on the design and how the confirmation is used.
Double entry can also have limitations. Entering the same mistaken value twice may produce agreement without a correct match to the original request.
Students should avoid saying that a particular method guarantees accuracy. Explain what kind of mismatch it can reveal and what assumptions it relies on.
In the paper exercise, the supplied source gives a clear comparison. In a real setting, the appropriate reference and authorised procedure would depend on the system. This article does not prescribe handling of personal, financial or sensitive records.
Parents can ask, “What are we comparing the input with?” If the answer is only “the allowed range”, the original accuracy question remains unanswered.
Then ask whether the comparison is independent enough to catch the relevant error. Repeating the same assumption may not add much evidence.
The aim is to select a safeguard that matches the uncertainty. A copying mismatch needs a comparison with the intended source, while a malformed string needs a format rule. Using the right check for the right problem is more useful than adding many checks whose purposes are unclear.
CHAPTER 12 OF 18 · Follow the evidence
12. Keep source accuracy separate from copying accuracy
Suppose the entered quantity matches the source request exactly. That establishes a successful match for the comparison, but it does not automatically establish that the source itself is correct.
The source might contain an earlier mistake, or the underlying request might have changed. Those possibilities require appropriate evidence; they should not be assumed to have happened in our main case.
This distinction prevents a chain of agreement from being mistaken for independent truth. Several records can repeat the same original error.
For the fictional classroom exercise, the source quantity 3 is the given reference. We can use it to evaluate copying accuracy without claiming to have investigated a real request.
If the task asks only whether the input matches the source, answer that question. Do not turn every simple comparison into an unbounded discussion of uncertainty.
If it asks whether the record is accurate in the wider situation, identify what further reference would be relevant. Be specific rather than writing that “anything could be wrong”.
Students can separate three statements: the input is accepted; the input matches the supplied source; the source reflects the intended real-world quantity. Each statement needs its own basis.
Parents can help by asking which statement the current evidence supports. This encourages careful confidence rather than habitual doubt.
The distinction is also useful when using online information or a generated answer. Repetition across several places may reflect copying rather than independent confirmation. The student should consider the source relationship.
The aim is calibrated reasoning. We can report a confirmed match without claiming more than the comparison establishes. That is a stronger answer than either announcing complete certainty or refusing to trust any record at all.
CHAPTER 13 OF 18 · Follow the evidence
13. Remember that correct processing cannot repair every wrong input
A program can apply its calculations correctly to an accepted but inaccurate input. The output may then be internally consistent and still wrong for the intended situation.
Imagine a fictional worksheet where each requested unit requires two tokens. The source quantity is 3, so the intended total is 6 tokens. If the program accepts an entered 5 and multiplies it by two, it outputs 10.
The multiplication is correct for the entered value. The mismatch arises earlier, where the entered quantity differs from the source.
Students should locate the stage rather than call every wrong final answer a calculation bug. Requirements, input, processing and output can contribute different kinds of problem.
This does not mean the overall system is satisfactory merely because the multiplication works. The system's requirements may need an appropriate way to reduce the relevant input risk.
The example uses invented tokens and no real payment. It exists to make the dependency visible: later results depend on earlier information.
A trace table can show the accepted input and the resulting calculation. That helps establish what the program actually did. It cannot, by itself, prove the external input was accurate.
Parents can ask, “Was the operation wrong, or did it operate on the wrong value?” The answer may identify a much more useful next step than changing the multiplication.
Students should also avoid assuming that a plausible output confirms the input. Ten tokens may look reasonable, yet plausibility is not a match to the source request.
The broader lesson is end-to-end reasoning. A correct program step is evidence about that step. To evaluate the intended outcome, follow the information through the whole process and identify where its meaning or value may have changed.
CHAPTER 14 OF 18 · Follow the evidence
14. Do not confuse validation with permission or security
A well-formed item code does not establish that a user is authorised to act on the corresponding record. Validation and permission answer different questions.
Our paper-based quantity case contains no accounts, passwords or access controls. It should not be treated as a model for securing a real application.
The distinction is still educationally useful. A value may meet a format rule and exist in a table, yet another rule may be needed to decide whether the requested action is permitted.
Students should avoid statements such as “The input is validated, so the system is secure.” That conclusion is much broader than the checks described.
Likewise, a range check does not establish that stored records cannot be changed incorrectly, that every error path is safe or that the user understands the result. These are separate design concerns.
There is no need to add a large security checklist to a simple school answer. Respond to the task. If it asks about validation, explain the relevant acceptance rules and their limits.
For a conceptual extension, distinguish three paper labels: acceptable form, recognised record and allowed action. A single input can pass one stage without establishing the next.
Parents can ask which question the student is answering. This helps prevent impressive technical vocabulary from replacing a precise explanation.
The aim is not to discourage learning or make every small program feel dangerous. It is to help the learner understand the scope of a method.
Clear boundaries support better design. When students know what validation does, they can use it effectively and recognise when another requirement needs another kind of control. Calling one method a complete solution makes both the method and the wider problem harder to understand.
CHAPTER 15 OF 18 · Follow the evidence
15. Test the stated rule and its limit separately
A useful test set for our interface includes valid boundary inputs 1 and 6, an ordinary valid input such as 3, and invalid inputs such as blank, 0, 7, x, 03 and 3.0.
The expected acceptance decisions should be written before observing the program's behaviour. Otherwise, students may treat whatever happens as the correct answer.
The test set checks the defined acceptance rule. It does not test every possible property of a larger system.
Now add the main accuracy scenario: the source request is 3 and the entered value is 5. The expected validation result is accepted, but the expected source-comparison result is mismatch.
This is not a failed validation test. It is a demonstration of the check's boundary. The validation rule behaves as specified while another question remains unresolved.
A clear test record can therefore have separate columns for input, expected acceptance, actual acceptance and match to source where relevant. Do not collapse all these into a single unexplained “pass”.
Students can also identify which condition each case examines. Blank concerns presence, 03 concerns the one-character rule, and 7 concerns the allowed set or upper range.
Avoid selecting only examples that make the program look successful. A useful test probes where misunderstandings or implementation errors might appear.
Parents can ask the learner why a particular case was chosen. “Because it is different” is less informative than “It checks whether the upper endpoint is included.”
The broader testing lesson links back to the subject's general testing guide. Here the focus is narrower: distinguish testing that the rule is implemented correctly from establishing that an accepted value accurately represents the intended request.
CHAPTER 16 OF 18 · Test and explain
16. Write a precise explanation instead of a slogan
A short answer can demonstrate strong understanding if it identifies the rule, the evidence and the limit.
For the main case: “The input 5 passes validation because it is a single digit in the allowed range 1 to 6. However, the source request specifies 3, so the accepted input does not match the source.”
This answer explains why acceptance and inaccuracy can coexist. It does not accuse the program of failing to perform a check it was never designed to perform.
If asked how to address the mismatch, identify an appropriate comparison with the source or confirmation process, while recognising the method's limits. Do not merely say “add more validation”.
A vague answer such as “Validation checks correctness” can be improved by naming the property being checked. Is it presence, length, range, format or membership in a record set?
Students should also distinguish an observed result from an intended result. “The program rejected 6” reports behaviour. “It should accept 6 under the inclusive rule” states the requirement. The difference identifies a possible implementation problem.
Parents can ask the learner to replace one broad word with a specific relationship. “Wrong” might become “outside the allowed range” or “does not match the source”.
This precision need not make the writing long or stiff. Ordinary sentences can carry the distinction clearly.
Follow the command word in the actual task. A request to identify a check may need a brief answer; a request to justify its use requires a reason connected to the situation.
The aim is explainable confidence. The student can say what the program establishes, show why and identify what remains beyond that evidence. That is more useful than memorising that validation is either a guarantee or an unreliable obstacle.
Begin with a small written specification. For example, use the one-digit quantity rule from this article and a supplied source request.
List several inputs before deciding their outcomes. Include an ordinary valid value, each boundary and a few different kinds of invalid representation.
For each input, write the expected acceptance result and name the relevant rule. Then separately compare any entered quantity with the source where the exercise provides one.
Next, consider the action after rejection. Does the task specify another interactive attempt or a non-interactive exit? Describe the path without inventing a user who can answer when none exists.
Finally, follow one accepted value into a simple fictional calculation. Ask whether correct processing would still produce the wrong intended outcome if the accepted input did not match the source.
This sequence uses no personal information and requires no live system. It develops the reasoning before implementation details become distracting.
A parent can ask questions while leaving the classification and explanation to the student. Giving the accepted set immediately may remove the chance to practise reading the requirement.
If a mistake occurs, identify its category. Was the range misread? Were representation and value confused? Was acceptance treated as proof of source accuracy? Each category suggests a different repair.
Keep the practice focused. A few well-explained cases can reveal more understanding than a long list of unexplained ticks.
Progress appears when the learner begins to ask “Valid according to which rule?” and “Accurate compared with which reference?” independently.
Those questions transfer to forms, spreadsheets and other data tasks. The particular one-to-six rule is disposable. The durable skill is to connect a check with the property it can actually establish, then select further evidence for any wider claim.
Can valid input be inaccurate? Yes. In the main case, 5 is allowed but does not match the source request for 3.
Does that mean validation is useless? No. It can reject defined unsuitable inputs consistently. Its purpose is valuable even though it does not establish every external fact.
Is 03 always invalid? No. It is rejected by this case's one-digit rule. Another system might allow or normalise it, and some identifiers require leading zeroes.
Does an existence check prove the right item was chosen? It proves membership in the checked set. A different existing code can still identify the wrong intended item.
Does a matching check digit guarantee accuracy? No. Its error-detection ability depends on the method, and it does not establish every external relationship.
Will entering the same value twice catch every copying error? No. The same mistake can be repeated. Explain the comparison and its assumptions rather than promising a guarantee.
Should every invalid input trigger another prompt? Follow the context and requirement. Interactive and non-interactive input can require different actions.
Can correct processing produce the wrong intended output? Yes, if it operates correctly on an inaccurate input. Trace the value and locate the stage of the mismatch.
What should a parent ask? “Which rule passed?” and “What reference would establish the intended value?” These questions make the distinction clear without requiring the parent to write the program.
The central idea is to match confidence to the check. Acceptance is evidence that the defined conditions were met. Accuracy requires an appropriate connection to the relevant fact or source. Understanding both helps students design clearer rules, test them honestly and explain results without claiming that a green tick proves everything.
Continue learning across eduKate
Choose one connected skill, then return to the worked case and apply it. These guides support subject learning; they complement the official syllabus and the school task.
| Connected guide | How to use it here |
|---|---|
| How to be Good at Critical Thinking | Match confidence to the property that a check establishes. |
| How English Works | English Across School Subjects | Read acceptance rules and inclusive boundaries precisely. |
| How to Study for Data-Response Questions | Keep the source, entered value and result in separately labelled fields. |
| How English Works | Writing and Revision | Explain why acceptance and inaccuracy can coexist in the same case. |
Continue with the right subject route
Read the broader subject guide or use the 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.
Official sources and scope
The official sources establish the subject scope. Worked examples and practice situations here are original educational explanations, not SEAB questions, official model answers or a marking scheme.
Continue this practical subject series
What Is G2/G3 Design and Technology? | Why a 3D Sketch Does Not Replace Working Views · What Is G2/G3 Nutrition and Food Science? | Why Per Serving and Per 100 g Can Give Different Rankings · What Is G2/G3 Art? | Why Drawing a Cup from Observation Is Different from Drawing Its Symbol