Time: about 14 minutes. Checkpoints: cp17-disclosure and
cp17-scope-the-claim.
You will need: your prompts and outputs from Units 7 and 10, your verification
results from Unit 8, your claim sorting from Unit 16, and the eleventh row you
wrote in the Unit 3 activity — the real piece of your own work you said you would
or would not check.
Four short tasks, then the checkpoints. The optional CS extension at the end sits outside the core time budget.
Task 1 — assemble the evidence pack (about 4 minutes)
Open course/learner-evidence-template.md and fill in items 1 to 6 from work
you have already done. You are collecting, not producing. The pack stays with
you: it is not submitted and nobody collects it.
That file opens with a table of everything the pack holds and which unit each
part came from, generated from course/evidence-pack.yml so that it cannot
drift from what the units actually ask you to keep. Work down it rather than
from memory.
Two things go in before item 1, and they are easy to forget because you wrote them before the pack existed: the verification sentence from Unit 0, and the task classification table from Unit 1. Unit 18 asks you to look back at the first of them.
Which unit item 3 and item 4 come from depends on your route. On the table-based and code routes they come from Unit 8, the Bernoulli comparison. On the route without the mathematics they come from Unit 9, the citation comparison — the same two items, established the same way, against sources rather than against a table.
If you took the Python route, add your self-check record:
python3 selfcheck.py progress --evidence
That prints Markdown. Paste it in.
If you took the table-based route, attach the table you built and the comparison you made instead. This is not the lesser route. The pack is evidencing that you established what correct looked like, compared against it, and can account for the difference — and a hand-built table evidences that as directly as a checker run does.
If item 4 is empty because nothing ever disagreed, say so explicitly and say what you checked. "No discrepancy found, having compared X against Y" is a result. A blank space is not.
Task 2 — write the disclosure (about 2 minutes)
Use the template on the student page. Two or three sentences.
Cover: what you used AI assistance for, at which stage, and what you did about the output afterwards.
Then read it back and apply one test:
Does any sentence in this disclosure argue that the work is correct?
If yes, that sentence is in the wrong statement. Move it to Task 3. A disclosure that has started arguing for correctness has stopped being a disclosure.
Task 3 — write the defence (about 4 minutes)
Two sentences. This is the shortest task and the hardest one.
Sentence one: what your final result is, which specification or convention it is correct under, what check you ran, and what the check showed.
Sentence two: the discrepancy, assumption, or convention you had to resolve, and how you resolved it.
Then run this checklist against what you wrote
- [ ] Does it name a specific check, not "I verified it"?
- [ ] Does it say what the check showed, not just that it was run?
- [ ] Does it name the specification or convention the check was against?
- [ ] Is the evidential basis independent of the system whose output is under review, rather than another assertion from that system?
- [ ] Does it rely on the model's confident wording, unsupported self-rating, or tool identity as proof? If so, remove that. Tool identity belongs in the disclosure. A confidence measure belongs in a defence only if it has been validated and calibrated for the relevant task, which this activity does not provide.
- [ ] Could a reader who does not trust you, and who cannot see your screen, tell what evidence exists?
That last question is the real one. A defence is written for a sceptical reader, not a sympathetic one.
Task 4 — turn it on your own work (about 4 minutes)
Everything so far has been about Bernoulli numbers, which is a case chosen so that "correct" is decidable. Your own work is not usually like that, and a method you can only run on the tidy case is not a method you have.
Go back to the eleventh row of your Unit 3 triage: the thing you personally use an AI system for, or are about to. If you wrote "I would not have checked that", this is where that becomes useful rather than embarrassing.
Write five short lines about one artefact from your own subject or work — one you have generated, or one you are about to:
- What it is, in a sentence, and what it would be used for.
- Which kind of claim it makes. Exact and checkable, source-dependent, a judgement, or a low-risk draft you will rewrite anyway. More than one may apply; privacy and consequence override "low risk".
- What could fail, and how you would notice. Not "it might be wrong" — the specific failure, and its symptom.
- The check you would actually run, with the reference it would use, and how long it would take. If no independent reference exists, say that: it is a finding, not a gap in your answer.
- What you could then honestly claim, and what would remain unchecked.
Add it to your pack as item 9. Nobody collects it. The point is that the method has now been run twice: once where the answer was decidable, and once where you had to decide what "checked" would even mean.
If you have someone to show it to — a tutor, a colleague, a study partner — a pack is a much better thing to discuss than a finished piece of work, because it shows what you did rather than what you produced.
Task 5 — the checkpoints
python3 selfcheck.py run --unit 17 # or in the browser
Both routes ask the same question and give the same diagnostics. Do this after Tasks 2 and 3, not before: the checkpoint asks you to sort statements into disclosure and defence, and it is a different exercise once you have written both yourself.
Optional reflection
Not assessed, not required, and worth five minutes if you have them.
In Note G, Lovelace wrote that the Analytical Engine "has no pretensions whatever to originate anything" (Lovelace 1843, Note G).
Write one paragraph. Not on whether she was right about language models — that question is genuinely open, and the student page explains why a short confident answer to it should be distrusted. Write instead on this:
Which parts of the work in your evidence pack did you originate, on your own understanding of the word, and how would you show it to somebody else?
The interesting answers are usually not about the code.
Optional CS extension
Optional. Outside the core time budget. It does not gate anything, and the module is complete without it.
Take a small routine — twenty or thirty lines is plenty. Your Unit 8 solution works, or anything of your own.
Pick one of three jobs and ask an AI system to do it:
- Translate the routine into another language you can read.
- Review it and report defects.
- Debug it after you have introduced a fault deliberately.
Then produce a test-based account, which is the whole point of the exercise:
- Before, write down what your tests currently cover. Not what you think the code does — what is actually checked.
- Run those tests against whatever comes back. For a translation, port the tests too, and note honestly whether porting them was harder than porting the code.
- Record where the assistance helped, with evidence. A defect it reported that your tests had not caught is evidence. A defect you already knew about is not.
- Record where it did not, with evidence. Reported defects that are not defects. Real defects it did not report. Changes that altered behaviour your tests did not cover — which is the most instructive category, because it tells you where your test suite is thin.
- State what you would now add to your tests, and why.
Note the shape of step 5. The most durable value in this exercise is usually not the code that came back. It is finding out which parts of your own program were never really being checked.
Add the account to your evidence pack as an appendix, marked optional.
Before you finish
Your pack should contain all eight items, with the disclosure and defence as separate statements that do not do each other's jobs. Check that once more.
Then, if the work is for assessment, check what your own institution or course permits and requires. This module does not set those rules.
That is the practical work finished. Unit 18 closes the module by naming the general question behind it, and your pack is what you take into it.
Marking guidance — open this once you have done the activity, to check your own work
Read this after attempting the activity.
cp17-disclosure is a comprehension check on the distinction taught in this unit,
so this key discusses the distinction rather than listing the checkpoint's
options. Checkpoint answers live in course/lab/checkpoints.py and nowhere
else.
Citation shorthand. (Lovelace 1843, Note G) = Note G, in Lovelace's
translation of Menabrea, "Sketch of the Analytical Engine invented by Charles
Babbage", in Taylor (ed.), Scientific Memoirs, vol. 3, 1843. Full entry in
course/references.md.
The distinction, in one table
| Disclosure | Defence | |
|---|---|---|
| Answers | How was this made? | Why is this right? |
| Is about | process and provenance | evidence |
| Contains | what, at which stage, what you did next | what you checked, what it showed, against which specification |
| May cite | the tool/version when required or materially useful | test results, checked reasoning, primary sources, measurements, qualified review |
| Does not establish correctness by itself | — | confident wording, unsupported self-rating, tool identity |
| Fails by | omission or vagueness | asserting rather than evidencing |
The single most useful test: a disclosure that starts arguing for correctness has stopped being a disclosure, and a defence that reports only what was used has never started being one.
Task 2 — marking the disclosure
A sound disclosure names the use, the stage, and what happened afterwards. It is two or three sentences and it is boring. Boring is correct.
Accept:
"AI assistance was used to draft the first version of the routine. The output was revised after verification: it used the wrong sign convention for B1 and returned floats. I re-specified and replaced it."
Query:
"AI was used, but everything was carefully checked and the final answer is correct."
The first clause is a disclosure and the rest is an unevidenced defence wedged into it. Neither statement is now doing its job: the disclosure has become vague about what was actually used, and the correctness claim has no check attached. Split it in two and watch what happens: usually the correctness half turns out to have nothing behind it, which is exactly why it had to lean on the disclosure for support.
Query:
"I used AI."
True, and useless. A reader cannot tell what to check. Ask: used for what, when, and what did you do with the output?
Note on tool names. Learners often assume naming the tool and version is the whole disclosure. It is not. Include those details when required or when they aid reproducibility or review, but also state the scope, stage, and subsequent action. A product name alone does not tell the reader how the work was made.
Task 3 — marking the defence
The four criteria: a specific check, a stated outcome, a named specification or convention, and no appeal to authority.
Accept — automated route:
"The routine is correct under the Unit 10 interface contract, verified by running the checker over every n from 0 to 30, which reported no divergence from the oracle. The discrepancy I found was float output at higher indices, reported as
not-fraction, resolved by requiring exact Fraction returns."
Accept — table-based route:
"My table is correct under the first Bernoulli convention, B1 = -1/2, verified by comparing every value against B4 as I derived it from the recurrence by hand and the rest as published in the module's reference table, which agreed at every index. The discrepancy I found was at B1, where the generated version gave +1/2; I traced it to the second convention and corrected the specification."
These are of equal weight. If a marking scheme, a rubric, or an instinct treats the second as the weaker piece of work, that is the scheme failing, not the work. Both name a specification, a check, an outcome and a resolution. That is the whole standard.
Reject:
"The code is correct — the AI is very reliable for this kind of task and the output was detailed and well commented."
Nothing here is evidence. Reliability in general says nothing about this instance; detail and comment quality are properties of the text, not of its correctness. This is the failure the checkpoint is built around.
Reject:
"All tests passed."
Which tests, showing what, against what specification? A routine that returns Lovelace's indexing passes any test written by someone who also assumed Lovelace's indexing. Passing tests are evidence only in combination with a stated specification — which is why the third criterion exists and why it is the one most often missing.
Query:
"I checked it thoroughly and I am confident it is right."
Your own confidence is not the evidence either. Ask yourself what "thoroughly" consisted of: what you compared, observed, sourced or reproduced. The answer is often good and simply was not written down.
Common misconceptions in this unit
"Disclosure is the responsible part; defence is showing off." They are two halves of one obligation. Honest provenance plus an unchecked answer is an honest wrong answer.
"If I disclose, I am covered." Disclosure transfers no accountability. This is
cp00-contract returning at the end of the module, and it is worth naming the
callback out loud.
"If it is correct, disclosure is a formality." It is not. The reader needs to know how the work was made in order to know what to check and how much of your own judgement stands behind it.
"The no-code pack is the lightweight one." Addressed above. Watch for it in peer discussion as well as in marking.
"A passed checkpoint is a defence." The self-check record is a result. A
defence is an account of why a result means what you say it means.
selfcheck.py progress --evidence prints this caveat itself; if you pasted the
record in place of item 8, the tool has already said so.
The Ada reflection
There is no answer key for this and there should not be.
The unit's position is that whether a language model originates anything is a genuinely contested philosophical question, and it turns on what "originate" is taken to require — intention, understanding, and purpose on one reading; novelty and non-specification on another. Both readings are held by serious people (Lovelace 1843, Note G is the source of the quotation; the interpretive question is not settled by it).
What to accept: any position argued from a stated meaning of the word.
What to challenge, in either direction: a position that treats the question as already closed. "Lovelace settled this in 1843" and "that is obviously obsolete" are the same error wearing opposite clothes — both skip the step where you say what origination would require.
The productive discussion prompt is the one in the activity: which parts of your own work did you originate, and how would you show it to somebody else? Learners usually arrive at the specification, the choice of what to verify, and the judgement about what counted as a discrepancy — rather than at any text they wrote. That is the right destination, and it is better reached than asserted.
The CS extension
Optional, outside the core budget, and not a gate.
The assessable content is step 4, where the assistance did not help, and within that the third category: changes that altered behaviour the tests did not cover. Reporting only step 3 produces a testimonial rather than an account.
Two things worth watching for:
- Translation exercises expose test coverage faster than review exercises do. Porting the tests is usually harder than porting the code, which is worth noticing when it happens to you.
- Reported defects that are not defects are as informative as missed ones, and they are easy to under-record because they feel like non-events. Record them anyway.
Step 5 is where this lands: you add tests you did not previously have, because the exercise revealed which parts of your own program were never really being checked. If that happens, the extension has done its job regardless of how the AI performed.
What this unit is not
- It states no assessment policy. The rules for AI use in assessed work are set by your institution or your course, not by this module. Nothing here overrides them, and nothing here is a substitute for reading them. If you are unsure what your rules are, that is the question to take away from this unit.
- Your evidence pack is private and is not collected.
course/learner-evidence-template.mdcarries the completion criteria and you check your own pack against them. It is not submitted, not marked and not reviewed. It evidences a verification habit, not programming ability — so a pack from the table route and a pack from the Python route are read against the same four defence criteria. The routes differ in medium, not in standard. - The privacy paragraph is a boundary, not a lesson. It marks where the question starts; it does not answer it.
- The Ada section is left unresolved on purpose. It is the place where a reader's own view most easily hardens into a settled position. It should read as open, because it is.
Your private activity record
Browser storage is not a permanent copy
Progress is kept only in this browser, profile and device. Private browsing, clearing site data, removing the profile, a browser reset, storage eviction or device loss can erase it. Keep important answers and contributions separately.
These notes stay in this browser unless you download a backup or activity log.