Time: about 10 minutes. Checkpoint: cp08-disclosure.
You will need: your prompts and outputs from Units 4 and 6, and your
verification results from Unit 5. If you did the optional Unit 7, bring your claim
sorting as well; the pack does not require it.
Three short tasks, then the checkpoint. 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.
| # | Item | Where you made it |
|---|---|---|
| 1 | Original prompt | Unit 4 |
| 2 | Generated output or code | Unit 4 |
| 3 | Verification result | Unit 5 |
| 4 | Discrepancy notes | Unit 5 |
| 5 | Revised prompt | Unit 6 |
| 6 | Final result | Unit 6 |
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 — the checkpoint
python3 selfcheck.py run cp08-disclosure # or use the browser self-check
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 5 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 9 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
For learners checking their own work, and for instructors marking or discussing it.
cp08-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. Ask the learner to 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 6 interface contract, verified by running the checker over n = 0 to 20 and n = 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 ones I derived from the recurrence by hand, 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 instructor's instinct treats the second as the weaker submission, that is the scheme failing, not the learner. 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."
The learner's own confidence is also not the evidence. Ask what "thoroughly" consisted of: what they 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 a learner has
pasted the record in place of item 8, the tool has already told them 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. A learner who reports only step 3 has written 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, and learners notice this themselves. It is a good moment.
- Reported defects that are not defects are as informative as missed ones, and learners under-record them because they feel like non-events. Ask for them specifically.
The intended landing point is step 5: the learner adds tests they did not previously have, because the exercise revealed which parts of their own program were never really being checked. If that happens, the extension has done its job regardless of how the AI performed.
For instructors
- The module states no assessment policy. It says only that the rules for AI use in assessed work are set by the learner's own institution or course. That is deliberate: this module is not the source of such a policy and must not read as though it were. If your institution has one, supply it alongside the module rather than writing it into the unit text.
- The evidence pack is private and is not collected.
course/learner-evidence-template.mdcarries the completion criteria and the learner checks their own pack against them. It is not submitted, not marked, and not reviewed by default. Treating it as a coding assessment inverts the design: the pack evidences a verification habit, not programming ability. - Equal status between the routes. If a learner chooses to show you a pack, read table-based and automated packs against the same four defence criteria. The routes differ in medium, not in standard.
- Item 5 is signposted, not taught. The privacy paragraph is a boundary
reminder. If it starts growing into a privacy lesson during review, that is
scope creep away from
course/course-map.md. - The Ada section is the one to protect in editing. It is the place where a reviewer's own view most easily hardens into the module's position. It should read as unresolved, 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.