Most advice about trusting AI is advice about picking a better model. That is the wrong lever, because you already know how to make an unfamiliar worker safe to delegate to, and you have never once done it by interrogating their intelligence. You write down what the job is, what it is not, and how the work gets checked.

In this session, we follow one small hiring decision all the way through. One day, whilst clearing my head on the elliptical machine, a thought occurred to me: I could ask the assistant that runs my knowledge base to recruit a personal trainer for me, meaning a role inside the system rather than a person. The interview it ran turned out to be more instructive than anything I had read about agent safety. It asked what the job was, then it asked the question that matters most: what must this role never do. It researched the profession before writing a line of the job description, and it finished with objectives concrete enough to tell later whether the hire was right.

Then the interesting part arrived. A trainer is not a clinician, which sounds like a platitude until the sleep data shows up, clinical readings included. Being allowed to read something is not the same as being allowed to interpret it, so the trainer reports how long I slept, names the direction it is moving, and says nothing whatsoever about what the clinical readings mean. Widening what a system may read never widens what it may claim, and confusing those two is behind a striking share of the AI failures people describe as hallucination.

From worked examples like the one above, I built out the six principles I run everything on, an acrostic called GOVERN: Gates, Origins, Verification, Evidence, Rules, and Nothing assumed. We will be looking at why a long list of permission prompts produces a system that feels governed and is not, why the honesty label has to travel attached to the claim, why anything countable belongs in a script rather than in a model's judgement, and why every ritual has to survive the previous one being skipped.

No particular stack is required to follow it, and nothing here needs a platform team or a budget: the whole system is folders, text files and version control, running on one laptop. You will leave able to write the job description for the next thing you delegate, whether that is an assistant, an agent in production, or a colleague on their first week.

This is a talk about governance told through a story, so it plays to a mixed room: engineers get the prompts, the scripts and the unattended runs, while leaders, product people and anyone using an assistant daily get the delegation frame without needing to read code. No live coding, and every artefact on screen is real and already published.

The material is not assembled for the CFP. GOVERN is published in full at pardel.dev/govern (coming soon, WIP), including the setup script and every prompt, and the system it describes has been running daily for three months: eleven deterministic scripts, three rituals, five gated actions, and a changelog of roughly 170 entries recording what was attempted, what failed and what was verified. The trainer in the story is a real role in it, with a research brief and a written mandate that draws a boundary across five health sources.

Structure (30 min; expands to 45 with the extended governance section and a longer Q&A):
1. The unanswerable question. "Can I trust it?" versus the question you answer every time you hire someone (3 min)
2. The interview. Role, name, the lane, research before writing, checkable first-week objectives, and why the lane question comes third rather than last (6 min)
3. Read is not claim. The trainer meets the sleep data, and a boundary that generalises to every agent you will ever deploy (5 min)
4. GOVERN, one letter at a time, each earned from the story rather than announced (8 min)
5. The short gate list. Why five gates govern better than fifty, and permission fatigue as a governance failure rather than a safety feature (4 min)
6. Deterministic first. Facts from scripts, judgement from the model, and what it costs to get that backwards (3 min)
7. What to write down on Monday, and close (1 min)

The 45-minute version adds the adversarial verification pass (a separate session pointed at each new artefact and asked to refute it rather than confirm it) and the rule that a system which works only while you are consistent is measuring your consistency rather than supporting it.

I have spoken at dotSwift, DroidCon, DevTalks and numerous other developer events and webinars; recordings are on my speaking page. All related materials are my own.