Topic 05 / Practical AI Integration & SkillsIn progress
The model is the easy part. The reusable brief is the work.
A demo takes an afternoon. The distance between a demo and something an organisation can rely on is everything on this page — and almost none of it is about which model you picked.
The demo always works. That is exactly what makes it dangerous.
01 / Ten prompt cards
What makes this repeatable is not the prompt.
Any task at all. The shape every other card is a special case of.
Set
Who it is for, what it must not do, one example of a good answer and one of a bad one, and the shape you want back.
Brief
The one thing that is different about this run.
Guardrails
If you cannot describe what a wrong answer looks like, the brief is not finished.
Role-play is not a technique. “You are an expert engineer” changes nothing that context would not.
Say the output shape — a table, five bullets, a diff — or you will get an essay.
One task per prompt. Two tasks returns mush on both.
Check
Read the output as if a stranger wrote it. Would you accept it from them?
Turn source material you already have into a document with a fixed shape. Not for producing content the sources do not contain.
Set
The heading skeleton in order, two or three sentences of house voice, the glossary, and the primary source material itself.
Brief
Which sections this pass, which sources cover them, roughly how long each runs.
Guardrails
If the source is silent, the output says not stated. It does not fill the gap.
Give it the primary material, never your summary of it.
Fixed heading order. If it reorders or invents headings, the brief was too loose.
Numbers are quoted from source, never computed, unless you supplied the arithmetic.
Check
Pick three factual claims at random and trace each back to a line in the source. If one fails, the whole document is suspect.
Generate a set of images that read as one series. Not for a single hero image, where a photographer is the better spend.
Set
A house-style block: light direction and quality, ground colour, lens and aperture, palette, the single accent, and the negative list. Prepended unchanged to every prompt in the set.
Brief
One scene per image, two to four sentences, subject-led rather than concept-led.
Guardrails
No legible text, ever. Models render printed matter as convincing gibberish, and gibberish is the loudest tell there is.
Photography words, not render words. Lens, aperture, ISO, window light, grain — never octane, hyperrealistic, 8K, cinematic.
Ask for wear. Dust, fingerprints, a scuffed bench. Perfect surfaces read as CGI.
One accent colour, and only one. Three saturated colours and the set falls apart.
Check
Lay the whole set out as a contact sheet before committing any of it. One frame brighter or warmer than its neighbours gets regenerated, not colour-corrected.
Turn messy input — PDFs, transcripts, email threads — into a fixed schema.
Set
The schema itself, with a type and an allowed range for every field, and a not stated value for each one.
Brief
The documents, and which fields matter most this pass.
Guardrails
Define the schema before the prompt. A model with nowhere to put uncertainty invents certainty.
Every field needs a not stated option, or you will get plausible fabrication.
Ask for the source line alongside each value. Unsourced extraction cannot be audited.
Never let it normalise units silently — extract as written, convert afterwards.
Check
Spot-check the fields that were hardest to find. Those are the ones it guessed.
Use a model to find what is wrong. Not to confirm what you already think.
Set
The standard you are reviewing against, and a standing instruction to default to reject when uncertain.
Brief
The artefact, and the one dimension being reviewed this pass.
Guardrails
Ask it to refute, not to review. “Give me three reasons this fails” returns more than “what do you think”.
One dimension per pass. Correctness, style and performance together returns mush on all three.
Never include your own justification — it comes back as the answer.
Independent passes beat a long conversation. A model that has agreed once keeps agreeing.
Check
Run the same artefact twice with the dimensions in a different order. Findings that survive both are real.
Say the same thing to a different audience. Not word-for-word conversion.
Set
The glossary of terms that must not drift, the register you are writing in, and two or three sentences of finished copy in the target language as a sample.
Brief
The passage, and who is reading it.
Guardrails
Translate for the reader, not for the sentence. An idiom that carries in one language rarely carries in the other.
Never round-trip to check. It rewards literalism and hides exactly the errors you were looking for.
Have a native reader check the headlines. They are the shortest and the easiest to get subtly wrong.
Keep defined terms fixed across both languages, or the glossary was pointless.
Check
Read it aloud in the target language. If you would not say it, do not publish it.
Change working software. Not to produce code you will not read.
Set
The failing test, the surrounding file, and the conventions the codebase already follows.
Brief
What should be true after the change.
Guardrails
Give it the failing test, not the wish. The model writes the fix; the test decides whether it is right.
With no test you are reviewing prose, not code.
Small diffs. A large change you did not read is a large change you cannot own.
Make it match the code around it, not the average of the internet.
Check
Run the test, then read the diff. In that order, and both.
Let a model act, not just answer.
Set
The tools it may call, the boundary of each, and what happens when it reaches one.
Brief
The goal, and what a good outcome looks like.
Guardrails
Design the boundary and the escalation path before the capability. Every tool it can call is something it can do unattended at three in the morning.
Anything irreversible needs a human in front of it. Sending, paying, deleting, publishing.
Log the reasoning alongside the action, or you cannot debug what it did.
A retry loop with no ceiling is an outage waiting for a bad day.
Check
Ask what happens on the worst plausible input. If you do not know, it is not ready to run alone.
Find out whether any of this is working.
Set
A small fixed set of real cases with known good answers, and one scoring method used every time.
Brief
The version being tested.
Guardrails
Never evaluate on the cases you used to build the prompt.
Twenty real cases beat two thousand synthetic ones.
Score the same way every run, or you are measuring the scorer.
Keep the failures. They are the only part of the set that teaches you anything.
Check
If the score improved, can you say which change caused it? If not, you changed too much at once.
Decide whether to use a model at all.
Set
What a wrong answer costs, and how quickly anyone would notice.
Brief
The task somebody is asking you to automate.
Guardrails
If a wrong answer is both expensive and hard to detect, the answer is no.
Cheap and obvious failures are where this technology is genuinely good.
A person who cannot check the output should not be the one running it.
“It usually works” is a description of a hobby, not of a system.
Check
Say out loud who is accountable when it is wrong. If the sentence has no subject, do not ship it.
02 / The same prompt, twice
One scene. Two different sets.
Ask ten times for “a photo of a bracket on a workbench” and you get ten photographs that do not belong together — different light, different colour, different lens. Put the same twelve-line house-style block in front of each one and you get a series. Nothing about the individual prompts improved. The wrapper did all of it.
Documentary still-life photograph. Soft north-facing window light from the left, gentle falloff, real soft-edged shadows. Warm neutral paper-grey seamless background, colour #e8e6df. Shot on a 50mm lens at f/4, ISO 200, natural film grain and slight vignetting. Muted palette: paper white, graphite grey, brushed aluminium, matte black, with one warm amber accent. Matte surfaces, no gloss. Visible dust, fingerprints and honest wear. Horizontal 16:9, generous negative space. No people, no hands, no faces. No legible text or numbers anywhere.
A macro photo of an aluminium bracket on a workbench.
03 / Anatomy of a card
Five parts. Only the middle one changes.
The shot list on this site is one instance of this: house style is the Set, each scene is the Brief, the four rules are the Guardrails, the contact sheet is the Check.
01Task
What this card is for — And, just as usefully, what it is not for.
02Set
The fixed context — House style, schema, glossary, standard. Prepended unchanged, every time.
03Brief
What is different this run — Two to four sentences. The only part that changes.
04Guardrails
The named failure modes — Four is a good number. Ten is a document nobody reads.
05Check
How you find out it is wrong — Before it matters, not after.
Jack's extensions / For teams using this now
+01
The wrapper is the product.
Reusable context beats clever prompting every time. If something worked once and you cannot say which part of the prompt did it, you have an anecdote rather than a method.
+02
Write the failure case first.
Before you deploy anything, write down what a bad output looks like and what happens when it appears. If you cannot do that, you are not ready to automate — you are ready to assist.
From card to practice
Three things that make it stick.
01
One glossary, one voice
The same defined terms across prompts, documents and both languages. Drift in the vocabulary shows up as drift in the output.
02
Twenty real cases
A small fixed evaluation set of genuine work, scored the same way each time, beats any amount of synthetic benchmarking.
03
A human, or a way out
Either somebody checks the output, or there is a designed path for what happens when it is wrong. Choose one before launch, not after.
04 / The question that decides everything
Assisted, or autonomous?
The same system, the same accuracy, two completely different risk profiles. What separates them is not how good the output is — it is what happens to a bad one.
Nobody reads any of them.You are asking: what does a bad one cost?
The same model running unattended ships that five per cent. Now the number that matters is not the accuracy — it is the cost of the failures, multiplied by how long it takes anyone to notice.
Before a model goes into a workflow
Answer five questions honestly.
What does a wrong answer cost, and how long before anyone notices?
Who reads the output, and can they tell when it is wrong?
Which cases are you evaluating on, and did you build the prompt on those same cases?
What can this reach — send, pay, delete, publish — and what stops it?
When it fails at three in the morning, what happens next?