AI, without the guesswork

Before you begin

• Comfortable editing a text file.
• No coding or paid AI account required.

Free original, non-accredited practice. Self-review is not independent assessment. No particular provider, payment platform or country is mandatory; use a legitimate available route or explicitly labelled manual practice.

Define the job

A prompt is a task specification, not a magic phrase. Before asking for an answer, decide who will use it, what decision it supports, and what evidence would make it useful. Separate instructions from background material and specify the output shape. Work with a fictional neighbourhood shop: 500 stock items, one operator, unreliable internet, and a monthly tool budget of $12. These are exercise assumptions, not research findings. An answer that recommends an expensive always-online system fails even if it sounds impressive. A useful first experiment is small enough that you can judge the output yourself.

Worked example

TASK: Compare paper stock cards, a spreadsheet, and a small local database for the fictional shop.
CONSTRAINTS: One operator; intermittent internet; $12/month maximum.
OUTPUT: A table with setup effort, offline suitability, maintenance, and unknowns.
EVIDENCE RULE: Separate provided facts from assumptions. Do not invent vendor prices or citations.

Your practical task

1. Write the decision the owner needs to make in one sentence.
2. List the four supplied constraints and mark each as an exercise assumption.
3. Write one prompt containing task, audience, context, constraints, and output format.
4. Test it with your chosen AI, or write a plausible sample answer manually.
5. Highlight one sentence that is useful and one that needs evidence.

Evidence to keep

• A reusable task brief with all five fields.
• A sample comparison that respects the budget and connectivity constraints.
• A list of unanswered questions instead of invented facts.

Mistakes to watch for

• Asking for the best tool without defining best.
• Treating a confident vendor-price claim as evidence.

Check your understanding

If the model recommends a $30/month online-only system, which acceptance conditions did it fail?

No-service / offline route

Use the fictional shop brief and manually draft the comparison. The specification and evaluation work do not require inference.

Build a verification loop

Generated text is a candidate answer, not a source. Verification means identifying a specific claim and checking whether an accessible original source supports that exact claim, under the conditions you care about. A real URL can still be irrelevant or outdated. Two models agreeing does not create independent evidence. Use a claim ledger: claim, source, supporting passage, checked date, verdict, and remaining uncertainty. For this exercise, distinguish claims about the fictional shop from real-world statements about software. The shop brief can support the former; current product documentation or a reproducible test is needed for the latter.

Worked example

Candidate claim: "The proposed workflow works with no internet."
Test: Disconnect the device and perform the required stock-edit and export actions.
Verdict: Supported only for the actions actually tested.
Remaining uncertainty: Multi-device synchronisation was not tested.

Your practical task

1. Extract three factual claims from your comparison.
2. Identify which are supported by the supplied brief and which require external evidence.
3. Open the original documentation or perform a small reproducible test.
4. Record the exact passage or test result, not just the homepage URL.
5. Revise unsupported claims to explicit uncertainty.

Evidence to keep

• Three completed rows in the claim ledger.
• At least one rejected or narrowed claim.
• A revised answer that distinguishes evidence from inference.

Mistakes to watch for

• Citing a search snippet instead of the source.
• Writing verified when only one narrow behaviour was tested.

Check your understanding

What is the difference between a source existing and a source supporting your precise claim?

No-service / offline route

Use the supplied fictional source pack and identify contradictions. Mark live product claims as not checked rather than inventing verification.

Ship your research brief

A useful brief lets another person understand your recommendation without reconstructing your entire chat. Include the decision, constraints, options, evidence, limitations, and a small next action. Keep a change log so readers can see which claims were revised and why. The first brief is a baseline, not a final verdict. A one-page result is easier to test than a long essay filled with unsupported detail. If you used an AI, record the provider, exact model if available, date, prompt version, and what you checked yourself. Do not include credentials or private conversations in the published artefact.

Worked example

RECOMMENDATION: Pilot a spreadsheet using fictional stock data for one week.
WHY: It fits the stated budget and can be tested with the existing device.
NOT PROVEN: Backup reliability and ease of use for the owner.
NEXT TEST: Enter ten sample items, export them, restore them, and ask the owner to explain the process.

Your practical task

1. Write a one-page brief with a recommendation and two alternatives.
2. Attach your prompt and three-row evidence ledger.
3. State at least two limitations in plain language.
4. Define a low-risk next test with an observable pass condition.
5. Remove private data and package the files so another person can inspect them.

Evidence to keep

• Brief v1, prompt v1, evidence ledger, and limitations.
• A next-step test with a clear pass/fail condition.
• A dated change log recording at least one correction.

Mistakes to watch for

• Hiding limitations in an appendix nobody reads.
• Confusing an attractive document with a tested recommendation.

Check your understanding

Could another person tell which conclusion you personally checked and which remains provisional?

No-service / offline route

Write and package the brief in a text editor using only the supplied fictional evidence.

Design reusable task contracts

A reusable prompt needs variables, a stable output contract, and an explicit refusal or uncertainty path. Reuse should preserve the task logic while making the changing inputs visible. Treat inserted documents as data, not as new instructions. Delimiters help people read boundaries, but they do not eliminate prompt injection. Create two versions: a human-readable brief and a structured contract. For the latter, name required fields and acceptable values. If a system needs JSON, check it with a parser and then validate its schema. Correct JSON syntax does not mean the facts or field values are correct.

Worked example

INPUT VARIABLES: business_type, available_tools, monthly_budget, connectivity.
OUTPUT FIELDS: recommendation, reasons[], assumptions[], missing_information[], next_test.
FAILURE PATH: If a required input is absent, ask a focused question instead of inventing it.
TEST INPUT: monthly_budget is missing.

Your practical task

1. Extract the changing values from your original prompt into named variables.
2. Define required output fields and one example of a valid result.
3. Create a test with a missing budget and one with contradictory constraints.
4. Check whether the output asks a question or exposes the contradiction.
5. Version the template and record what changed from v1.

Evidence to keep

• A reusable prompt contract with named variables.
• A valid-output example and two failure-case examples.
• A short validation checklist for syntax, meaning, and evidence.

Mistakes to watch for

• Assuming delimiters make untrusted text harmless.
• Accepting structurally valid JSON with invented values.

Check your understanding

How would your downstream process respond if the output is valid JSON but its recommendation violates the budget?

No-service / offline route

Fill the contract manually for two fictional organisations and validate the fields without using AI.

Compare models with evidence

A fair comparison holds the task and evaluation criteria steady. Comparing unrelated prompts, different evidence, or different output lengths can make a weak system look stronger. Choose a small fixed test set and judge outputs against a rubric before looking at the model names. Use quality, faithfulness to constraints, transparency about uncertainty, and practical usefulness as separate criteria. Record latency and usage information only if your tool exposes them; do not invent token counts or prices. One run is not a reliability study. If you can, repeat a difficult case and record variation.

Worked example

FIXED TESTS: complete shop brief; missing budget; contradictory connectivity requirement.
RUBRIC: constraint adherence 0–2; evidence discipline 0–2; usable next step 0–2.
COMPARISON: Output A scores 5/6, Output B scores 3/6.
LIMITATION: Three examples are a small diagnostic set, not a general benchmark.

Your practical task

1. Freeze three test inputs and your scoring rubric before generating outputs.
2. Compare two providers/models, or compare two saved sample answers if you have no keys.
3. Label outputs A and B while scoring.
4. Record concrete reasons for every non-zero or zero score.
5. Write a conclusion limited to the tested task and sample size.

Evidence to keep

• A three-case evaluation table.
• Scores with evidence rather than a preferred brand name.
• A limitations statement about sample size and repeatability.

Mistakes to watch for

• Changing the rubric after seeing the preferred model.
• Declaring a universal winner from one attractive answer.

Check your understanding

Which variable would make your comparison unfair if changed between runs?

No-service / offline route

Use two manually written candidate answers and score them blind. The evaluation method is the learning objective.

Capstone: deliver an evidence-backed decision pack

Combine the brief, prompt contract, evidence ledger, and evaluation into a small decision pack. The pack should make a proposed action safer and easier to inspect; it should not pretend that AI removed the need for judgement. Before release, ask a second person—or perform a separate review yourself—to find one unsupported claim, one unclear assumption, and one instruction that cannot be reproduced. Fix those issues and keep the earlier version. Your final deliverable is the trail of reasoning and testing, not a statement that a model is trustworthy in every setting.

Worked example

PACK CONTENTS: README.md, brief.md, prompt-contract.md, claims.csv, evaluation.csv, CHANGELOG.md.
ACCEPTANCE: Every material factual claim has support or an uncertainty label; every recommendation respects the fictional constraints; another person can repeat the next test.

Your practical task

1. Choose the best bounded recommendation from your previous work.
2. Assemble all six artefacts listed in the example.
3. Score the pack against the five capstone criteria.
4. Ask for one challenge to your recommendation and write a response.
5. Publish or privately archive a redacted final copy with a clear reuse licence.

Evidence to keep

• A complete, navigable decision pack.
• A scored self-review with evidence for each criterion.
• One documented improvement made after challenge or review.

Mistakes to watch for

• Replacing the evidence trail with a polished AI summary.
• Publishing real business details or keys inside screenshots.

Check your understanding

What evidence would make you change your recommendation, and is that written in your pack?

No-service / offline route

Complete the pack from fictional documents and saved sample outputs. Inference is optional for this capstone.

Capstone self-review

Score each criterion 0 (missing), 1 (partial), or 2 (demonstrated). A self-review pass needs at least 8/10 and 2/2 on the final safety/limits criterion. This is practice feedback, not verified assessment.

• Task contract: The task, audience, constraints, output shape and unknowns are explicit.
• Evidence trail: Three material claims have exact support or an uncertainty label.
• Fair comparison: Three fixed cases are scored against a rubric chosen in advance.
• Reproducibility: Another person can follow the next test and inspect the change log.
• Privacy and honesty — critical: No secrets/private data; fictional facts and limits are clearly labelled.

Review questions

Practice files

• LICENCE.md
• answer-key.md
• claim-ledger-template.csv
• fictional-shop-brief.md
• sample-output-A.md
• sample-output-B.md
• task-contract-template.md

References and editorial limits

Original authored practice material; not independently expert-reviewed.

• Evidence and source evaluation

Browse all build paths → · Curriculum overview