CHECKPOINT 1  -  SET A  -  ANSWER KEY  -  OPEN ONLY AFTER YOU FINISH THE SET
Every output and traceback below was copied from a real run of the named file.
Captured with Python 3.13. On 3.11 and 3.12 the marker lines under the code in a traceback differ; line numbers and the last line do not.
Mark each part complete, partly there or missing against 'What a complete answer contains'.

QUESTION 1   [Mechanism]
  (a) The handbook text went into the context: it is part of the input sent to the model with each question. The weights were set during training, before Priya ever used the model, and they do not change during use (inference). The model predicted each answer from its fixed weights plus the handbook text in context. Nothing was learned or stored in the model.
  (b) The new chat does not contain the handbook, and an internal handbook was not in the training data. The model cannot answer from it. It may say it does not know, or it may produce a plausible but invented answer. The colleague must supply the handbook again to get good answers.
  What a complete answer contains
   - (a) The handbook is in the context, sent as input with each question; the weights were fixed in training and did not change during the chat; all three terms are used correctly.
   - (b) The new chat has no handbook in its context; it was not in the training data either; so the model cannot answer from it and may invent something plausible.
        Standard | Example answer and why
        Meets | "Uploading put the handbook into the context, which is sent to the model with every question. The weights came from training and didn't change. Nothing was learned. Tomorrow's new chat has no handbook in context and the handbook was never in the training data, so the model can't answer from it and may make something up that sounds right."
        Partly | "The model doesn't really learn from you, it just uses the conversation. The colleague won't get the same answers." Right direction, but no mechanism: it does not say the handbook is sent as input, does not mention fixed weights, and gives no reason for (b).
        Misses | "It was trained on the handbook, but the colleague has a different account so the model won't share it." Accepts the upload-trains-the-model misconception, which is the misconception the item tests. The reason in (b) is about accounts, not about context.

QUESTION 2   [Mechanism]
  (a) The prompt is turned into tokens. The model computes a probability distribution over every possible next token. One token is picked (sampled) from that distribution and added to the text. The model repeats this, one token at a time, until the answer ends.
  (b) Sampling picks from the distribution, not always the single most likely token. Two runs can pick different tokens early, and every later token is then predicted from different text, so the wording diverges. The weights are the same in both runs, so it is not broken, and there is no mind to change: each run is a separate draw.
  (c) Lower temperature concentrates the choice on the most likely tokens, so the runs vary less. It does not make the answer more correct: the most likely continuation is still not checked against anything.
  What a complete answer contains
   - (a) Tokens; a distribution over the next token; one token sampled and appended; repeat until done.
   - (b) Sampling, a random draw from the distribution, as the reason the runs differ; same weights, so neither broken nor a change of mind.
   - (c) Less variation, and not more correct, with the reason.
        Standard | Example answer and why
        Meets | "It splits the prompt into tokens, works out how likely each possible next token is, picks one by sampling, adds it, and repeats. Because it samples, the two runs can pick different tokens and then everything after is different. Same model, same weights; it isn't broken and it didn't change its mind. Lower temperature makes runs more alike, but more alike isn't more correct, because nothing checked the likely answer against the facts."
        Partly | "It predicts the next word each time. There is randomness so you get different answers. Lower temperature gives the same answer, so it would be more accurate." Has prediction and randomness, but no distribution or sampling step, does not answer the two colleagues, and (c) wrongly equates consistency with correctness.
        Misses | "The model searches its database for the best safety reminder and gives a different one each time to be creative." Describes a lookup, not prediction, and gives the model intent.

QUESTION 3   [Mechanism]
  (a) Training data. A widely published public fact; very likely in the training data.
  (b) Context. The log is in this chat, so it is sent with the question.
  (c) Inaccessible. A private email the model was not trained on and that is not in the chat.
  (d) Inaccessible. It happened after the training data was collected and it is not in the chat. The model may still answer confidently; that answer is stale or invented.
  What a complete answer contains
   - Each part: the correct circle, and a reason that says where the information is. A correct circle with no reason, or a wrong reason, is partly there.
   - "Context, if I paste it in" for an inaccessible item has the right reasoning, but the question says the information has not been supplied. Count it partly there.

QUESTION 4   [Code reading and tracing]
  Captured output:
    Captured run: L18_A_q4.py (Python 3.13):
        123
        15
        4.0
  What a complete answer contains
   - All three lines exact. Quotes around a string are not held against you.
   - 4 instead of 4.0 is the right value with the wrong type, so that line is partly there: division with / always gives a float.
   - 15 on the first line is wrong: + between two strings joins them.

QUESTION 5   [Code reading and tracing]
  (a) The elif branch. fuel > reserve is 2400 > 2500, which is False, so the if branch is skipped. fuel > reserve - 200 is 2400 > 2300, which is True, so the elif branch runs and status becomes "CHECK". The else never runs.
  (b) Captured output:
    Captured run: L18_A_q5.py (Python 3.13):
        CHECK
        -100
  What a complete answer contains
   - (a) The correct branch; the first condition evaluated with the actual values and shown False; the second evaluated and shown True.
   - (b) Both lines exact. The second line is negative: -100. 100 misses the sign.

QUESTION 6   [Code reading and tracing]
  (a) Trace table, from the captured output:
        day | total after line 3
        1 | 2
        2 | 6
        3 | 12
        4 | 20
  (b) The last line printed is done 20.
  (c) 4 times. range(1, 5) stops before 5.
    Captured run: L18_A_q6.py (Python 3.13):
        1 2
        2 6
        3 12
        4 20
        done 20
  What a complete answer contains
   - (a) One row per pass with the right total. If you made one arithmetic slip and then applied the rule correctly to your own wrong running value, count only the first wrong row.
   - A fifth row for day = 5 is the off-by-one on range. Count that row as wrong, and count (c) as wrong only if the number you wrote disagrees with your own table. One off-by-one is one mistake, not two.
   - (b) Exact text. (c) 4.

QUESTION 7   [Code reading and tracing]
  (a) The loop keeps going while hours < 50, so it stops once hours is no longer below 50: the first time the test at the top finds hours at 50 or more. Yes, hours can end above 50. The test is only checked at the top of each pass, and the addition inside the loop can carry hours past the limit before the test sees it.
  (b) hours goes 10 -> 25 -> 40 -> 55. After the third pass, 55 < 50 is False, so the loop stops with checks = 3. Captured output:
    Captured run: L18_A_q7.py (Python 3.13):
        3 55
  What a complete answer contains
   - (a) A correct stopping condition is complete in itself: "it stops once hours is no longer below 50" says everything the first half asks. The second half needs a yes, with the reason: the test is checked at the top, so the update inside can overshoot.
   - (b) Both values. 3 50 has the count right and the overshoot wrong, so it is partly there.

QUESTION 8   [Code reading and tracing]
  (a) and (b): count_over takes a collection of values and a limit. It returns how many of the values are strictly greater than the limit.
  (c) Only 7 is greater than 5; the two 5s are not, because > is strict. So the first line is 1. Every value is greater than 1, so the second line is 5.
    Captured run: L18_A_q8.py (Python 3.13):
        1
        5
  What a complete answer contains
   - (a) Both inputs named.
   - (b) "How many", a count, with the comparison stated correctly: strictly greater than.
   - (c) Both lines. 3 on the first line counts the 5s and has missed the strict >.

QUESTION 9   [Fault diagnosis]
  (a) Line 4: total = total + h. It is the last frame in the traceback, inside average_hours.
  (b) The list week (line 8) contains the string "8" among numbers. Line 4 tries to add a float and a string, which Python does not allow. The error line names the types: 'float' and 'str'.
  (c) total = 13.5 and h = '8'. The first two values were added (6.5 + 7 = 13.5) before the string arrived. Captured from the check script:
    Captured run: L18_A_q9_check.py (Python 3.13):
        stopped with total = 13.5 and h = '8'
  What a complete answer contains
   - (a) Line 4. Line 9, the call, appears in the traceback, but the error was raised inside the function, so line 9 alone is partly there.
   - (b) Names the offending value, the string "8"; says why adding it to a number fails; says where it came from, line 8. "A type error" with nothing else is partly there.
   - (c) total is 13.5 (6.5 + 7); 13 or 21.5 is wrong. h is the string "8": writing it with quotes, or saying it is text, is complete. Writing 8 as a number misses the point, because the string is the fault.

QUESTION 10   [Fault diagnosis]
  (a) Captured output:
    Captured run: L18_A_q10.py (Python 3.13):
        Reminder sent to person 1
        Reminder sent to person 2
        Reminder sent to person 3
        Reminder sent to person 4
        Reminder sent to person 5
        Sent 5 of 6
  (b) No. The comment says six people numbered 1 to 6, but person 6 never gets a reminder and the count says 5. Line 5 holds the fault: range(1, staff) stops before its second number, so with staff = 6 it gives 1, 2, 3, 4, 5. It is off by one at the top end.
  (c) The corrected line is for person in range(1, staff + 1): and the program then sends six reminders, so its last line is Sent 6 of 6. Captured from the check script, repaired version:
    Captured run: L18_A_q10_check.py, repaired version, last two lines (Python 3.13):
        Reminder sent to person 6
        Sent 6 of 6
  (d) The colleague's version prints the same five reminders and then Sent 6 of 6. That is not a fix. Person 6 still gets no reminder, and the summary line now says they did. Before the change, the last line at least showed the problem; after it, the output looks right and is wrong. The original program never crashed either: it ran to the end and printed a plausible result. A crash tells you where to look. A silent wrong answer gets trusted and acted on, and this one would be found only when person 6 misses their shift.
  What a complete answer contains
   - (a) The exact output, including the last line.
   - (b) Names line 5, and says that range stops before its second number. Naming line 8 as the fault is wrong: it reports correctly what happened.
   - (c) A line that gives 1 to 6, such as range(1, staff + 1) or range(1, 7), and the new last line Sent 6 of 6. range(1, 6) is the same bug written out.
   - (d) Says what prints; says it is not a fix because person 6 is still missed and the report is now false; and gives a reason a silent wrong answer is worse than a crash: it gets trusted, and nothing points at the fault.
        Standard | Example answer and why
        Meets (d) | "It prints the five reminders and 'Sent 6 of 6'. Not a fix: person 6 still gets nothing, and now the summary lies about it. A crash would have been better than this, because a crash stops you and shows a line number. This runs, looks fine, and the only way anyone finds out is when person 6 doesn't turn up."
        Misses (d) | "It would work because the count is right now." Checks the summary line against the comment and not the reminders against the people. Accepts an output that looks right as evidence that the program is right.

QUESTION 11   [Method]
  (a) One decomposition that meets the standard:
   - Read the shift lines from the file into a list.
   - Keep only the shifts from the month in question.
   - Add up hours per volunteer for that month.
   - Decide, for one volunteer, whether their total is behind the requirement.
   - Produce the list of volunteers who are behind.
  (b) Any two of these, or others that are genuinely open:
   - What "behind" means: below a fixed monthly requirement, or below a share of it prorated to today's date? What is the requirement?
   - Which month: the current calendar month, or the last 30 days?
   - A volunteer with no shifts at all does not appear in the file. Do they count as behind? (They should, but the file alone cannot show them; a roster is needed.)
   - Is meeting the requirement exactly "behind" or not?
  (c) Example: is_behind(hours_worked, hours_required) returns True or False.
   - is_behind(8.0, 10.0) returns True.
   - is_behind(10.0, 10.0) returns False. Boundary: meeting the requirement exactly is not behind (stated assumption).
   - is_behind(12.5, 10.0) returns False.
   - is_behind(0, 10.0) returns True.
  What a complete answer contains
   - (a) At least three sub-problems, each something one function could do and describable in one sentence, which together cover the request end to end. Splitting by step of a recipe ("the first part of the code") instead of by responsibility does not meet it.
   - (b) Two things the request genuinely leaves open. "Use Python" or "make it fast" are not open questions about the request.
   - (c) A signature with named inputs and a stated return; three criteria that each name a specific input and expected result; one of them sits exactly on a boundary and says which side it falls on. "Works for edge cases" is not a criterion.
        Standard | Example answer and why
        Meets (c) | "is_behind(hours_worked, hours_required) -> True/False. AC1: (8.0, 10.0) -> True. AC2: (10.0, 10.0) -> False; exactly meeting the requirement is not behind. AC3: (12.5, 10.0) -> False."
        Partly (c) | A signature and three criteria such as "returns True when behind", "returns False when not behind", "handles edge cases". The signature is complete; two criteria state a testable direction but none names an input and expected result; there is no boundary.
        Misses (c) | "The function should work correctly and be efficient." No signature, nothing testable.

QUESTION 12   [Verification reasoning]
  (a) The reply makes up to five separable claims: the function returns the average of a list; the model tested it; it works for all inputs; it works for an empty list; and average([4, 6, 8]) returns 6.0. "I tested this" is itself a claim, not a fact you have been given.
  (b) The authority for what code does is running it, not the model's statement. "I tested this" is not evidence: the reply is predicted text, and the statement that it ran something is one more claim to verify. Evidence: run average([4, 6, 8]) and compare with 6.0; run average([]); run a few more inputs (one item, negatives) against "all inputs". Record each result.
  (c) It crashes. With an empty list, len(values) is 0, so line 5, return total / len(values), divides by zero. Captured run of the empty-list call:
    Captured run: L18_A_q12_broken.py (Python 3.13):
        Traceback (most recent call last):
          File "L18_A_q12_broken.py", line 8, in <module>
            print(average([]))
                  ~~~~~~~^^^^
          File "L18_A_q12_broken.py", line 5, in average
            return total / len(values)
                   ~~~~~~^~~~~~~~~~~~~
        ZeroDivisionError: division by zero
  The 6.0 example is true: L18_A_q12_check.py prints 6.0. The empty-list claim is false. One true example did not make the general claim true.
  What a complete answer contains
   - (a) At least three of the five claims (tested it; all inputs; empty list; the 6.0 example; returns the average), and "I tested this" is one of the three, listed as a claim rather than accepted as a fact.
   - (b) Names running the code as the authority; says the model's "I tested" is not evidence; names specific inputs to run.
   - (c) Predicts an error; names line 5; explains that len is 0. Naming ZeroDivisionError is not required.
        Standard | Example answer and why
        Meets | "Claims: it was tested; it works for every input including []; [4, 6, 8] gives 6.0. The model saying it tested is just more text, so it settles nothing. The authority is running the function: try [4, 6, 8], try [], try one number. For [], len is 0, so line 5 divides by zero and it crashes."
        Partly | "Check it in another AI or search online to see if the code is right. For an empty list it returns 0." Names a second model as the authority, which repeats the problem; the prediction in (c) is wrong.
        Misses | "The model said it tested it, so it's verified. It works for the empty list." Accepts the claim as evidence; no procedure.
