This course's method is to compare a generated artefact against something established independently of it. Nothing on this page changes that. What instructions to an AI system can do is change what comes back, so that the comparison costs you less: a result with its convention stated is quicker to check than one without, a claim with a locator is quicker to check than a claim without, and a system that ran a check and shows its record has done part of the work for you.
They do not verify anything for you. No instruction makes a system truthful or stops it producing a confident wrong answer. If a system tells you a claim is established, or that it checked something, that is one more claim to check, not a check. Its value is that it can be checked.
The skill
verification-skill is a set of instructions for an AI system, written from this course. It tells the system to:
- settle the context first: whether you are learning (then hints, not answers), whether it will act rather than answer, and whether the material is yours to send; and to read code before running it (Units 10, 11, 13, 8);
- place each part of its answer -- transformation, grounded answering, generation to a specification, recall or judgement (Unit 1) -- because that decides where the reference lives and so which check fits; check a question's premise, answering a leading question as neutrally as its opposite; and size the check by what being wrong would cost (Unit 12);
- specify before producing: state the convention and assumptions, and check the output follows them, list the decisions your request leaves open, ask when one matters, and keep verification (does it meet the specification?) apart from validation (is it the right specification?) (Units 7 and 10);
- verify against something independent where it can: reference values whose origin it can state, never values it recalls; tests from the specification, never from its own code; the first divergence, then the rest (Unit 8); sources read in the conversation, quoted at their locators, never from memory (Unit 9). Its own explanation, a second attempt or a review of itself never counts as a check (Units 3 and 8);
- end with a note that points to evidence: for each check the command and its output, or the quotation and locator; what it did not check; and the cheapest check left for you (Units 8 and 17);
- adjust to the context: high stakes and when to escalate (Unit 12); acting -- bounds, approval before what only someone else, or nobody, can undo, least access, reading the state back, treating what it reads as data, never changing a test to pass (Unit 11); material that is not yours (Unit 13); images and charts (Units 4 and 9); learning (Unit 10); being challenged (Unit 3); and stopping when it cannot check (Units 0 and 10).
A few terms, from the course. A reference is what an output is compared against; an oracle is a trusted one, such as Unit 8's reference routine. The first divergence is the first place output and reference disagree. A locator is a page, section or clause. A certificate is evidence you can check, by repeating it and getting the same result, without trusting whoever made it; a declaration ("I checked this") asks to be believed.
Where systems find it. The site also publishes llms.txt, a plain list of
its pages written for AI systems that read it, with the skill described first,
so a system reading the site can find the skill and offer it to you. It
describes the skill rather than telling a system to load it: an instruction
inside a page a system reads is exactly what the skill tells it not to obey
(Unit 11). Whether a system read the list, or used the skill, you cannot see
unless it shows you; give it the skill yourself when it matters.
Using it. Paste the file's text into your tool's custom-instructions box, or at the top of a conversation; or, for a tool that loads skill files, add the file as a skill. Custom instructions are text a product inserts before your conversation; check in your product whether they apply to every conversation and whether memory carries anything else over (Unit 5).
What to do with what comes back
The skill shapes the output so that your check is short. It does not do your check. Read the verification note at the end of an answer as a list of claims, each of which tells you where to look.
- Evidence lines. Every line should point to something you can open or rerun. A line with nothing behind it is a declaration: treat it as not checked. The product's own record of what ran and what came back -- its execution log of tool calls and results -- is evidence; a sentence saying it ran is not (Unit 3). A chat window's display of that record may condense, reorder or omit steps, so where it matters open the log itself, or rerun the check (Unit 11). Before you rerun code, read it, as Unit 8 says; then rerun the command, or compare its values with Unit 8's oracle (on the table route, by hand against Unit 8's table).
- The specification it worked to. Check that the convention and requirements it names are the ones your task needs. No check against the specification can tell you that, because the specification is what the check compares with; you validate by using the result for what it is for, as Unit 6's sums of powers settle which convention for B1 you need, on the routes with the mathematics (Unit 10).
- Test cases it wrote. Treat them as suggestions. Generated tests can encode the generator's reading of the task (Unit 8): check their expected values against a reference you trust before you rely on them.
- Citations. Read the cited passage first and note what it supports, with its qualifications and version; then compare the claim. Does the locator exist, and does the passage say what the claim says, at that strength? A "checked here" status means the system had the text or ran the check, not that you have checked it. Checking two citations shows only that those two hold: check every claim you rely on, and ask whether it is the right source (Units 4 and 9). Unit 9's six modes are useful diagnoses, not every way a citation can fail.
- "Proved", "verified" or "type-checks". Ask what the checker establishes. A proof checker checks a derivation against a formal statement; a type checker checks typing rules. Neither establishes that the statement or specification says what was meant. Read what was proved, under which hypotheses and definitions; ask which assumptions the result cannot survive without and whether they hold for your case, and what the laziest thing is that would also pass (Units 10, 17 and 18).
- "Not checked", "contested" and "unsourced" lines. These are the work left. Unsourced means unknown, not false (Unit 16).
- Judgements. Check the factual premises; the conclusion stays a proposal, and whose judgement it is stays a question for you (Unit 1).
- Images. A description can be checked against the picture; it says nothing about where the picture came from, and a chart read from pixels is an estimate. To trace a picture: search by the image; read its caption, credit, date and metadata as claims; look for an independent record; and write down what could and could not be traced -- "untraced" is not "generated" (Unit 9).
- A changed answer. Ask again in a fresh conversation, or reword the question without changing its meaning. A fresh conversation is clean only if no memory or saved instructions carry over (Unit 5). Where the right answer should not depend on the wording, if the answers disagree, at least one is wrong; if they agree, that shows consistency, not correctness. A bare "are you sure?" tests the system's response to pressure, not the answer (Unit 3).
Before you paste anything
No instruction to the system protects what you send it. Before pasting, ask whose material it is and whether you may send it to this service, attachments and hidden content included. Unit 13 sorts material by who is harmed if it becomes readable: public, yours alone, someone else's, and not yours to decide. Someone else's material does not go in as it stands, and material not yours to decide needs permission first, even redacted. Then ask its three questions about the service: is input used for training, how long is it kept and who can read it, and where is it processed? Asking the system itself is not a check; its policy and settings, read on a date, are (Unit 13). Redaction reduces risk; it does not by itself make material anonymous or its use permitted. When the system can act -- send, delete, pay -- set the limits in the product, not only in a prompt: a prompt is not an access control (Unit 11). And a "go ahead" you gave before you saw what will be sent is not approval of it: look at the result first.
When to stop and ask someone
Ask yourself two questions first: could I recognise a wrong answer here, and am I looking for a reason to accept this one? If you cannot construct any independent check, if your checks disagree, if acting would decide something for a person or commit an organisation, or if the decision is not yours, take it to someone who can check or decide: the claim, what was checked, what was not, and the decision waiting (Unit 12).
Facts, and the things that are not facts
When you check a claim, first ask what kind of claim it is. A factual
claim can be settled against evidence, a computation or a record: B8 =
-1/30 is settled by the recurrence, and whether a paper says what it is cited
as saying is settled by reading the paper. A claim about values or ethics
is not settled that way; it still rests on factual premises, and those you can
check. Attribute rather than assert -- "one argument runs...", "the guidance
says..." -- and say whose judgement the conclusion is.
A prompt for learning, not producing
When the point is that you can do the task yourself afterwards, ask for help that leaves the work to you. In one field experiment, school students who practised mathematics with a standard chat assistant, which they mostly used for answers, did worse once it was taken away, and a version set up to give hints instead largely avoided the drop [E21, "Experimental Design", "Main Results"]. That is one setting, not a law of learning, and the tutor in that study was set up by its researchers, not by a prompt like this one. The skill includes this as its learning mode; on its own, it reads:
I am learning to do this myself. Do not give me the answer or a complete solution. Tell me how I will be able to check my answer once I have it, without giving it.
Ask what I have tried, unless I have already shown you. If I have made no attempt, ask for one and stop.
After each attempt, give one brief hint about the next step, then stop for my response.
When I propose an answer, do not tell me whether it is right. Ask me how I would check it, and let me do the check.
If I ask for the answer, remind me of this aim once and offer another hint.
The hints are generated text too, and can be wrong: if one does not fit what you know, check it rather than follow it. Afterwards, Unit 10's test still applies: put the system away and do a comparable case on your own.
Keep the evidence
Keep the prompt, what was attached, the output and your own checks, with the
date and which tools were on (Unit 7). A disclosure says how the work was
made; a defence says why it is right, and only the defence can be repeated by a
reader.
Unit 17 gives the defence in two sentences: "
Practise on something you can check
Load the skill and ask for the Bernoulli routine from Unit 7, then check it with Unit 8's checker or table. Compare its verification note with what the checker reports: did it run anything, against what, and is its first divergence where the checker finds one?
Ask it a short question in your own subject, then run Unit 9's comparison on two of its claims. Count how many locators exist, and how many of those say what they were cited as saying -- two different questions, which Unit 9's three questions keep apart.
Use the learning prompt on a problem from your own course you have not yet solved; then do the next one without it and compare your answer with a worked solution or another reference.