Approval Is Not Verification

The trust boundary, drawn

I said yes to things I could not evaluate

Longer than I want to admit. I'm not a developer. I lead transformation work for a living, and like a lot of people right now, I've been building more with AI than I ever thought I could: apps my family uses, research pipelines, automations that run while I sleep. The tools are that good now. And when the tools recommended something technical, I approved it, because saying yes kept things moving and I had no basis to say anything else.

Then a security review of a new tool I'd installed showed me what my yes had been buying. Tools I had casually connected held far more access than I ever meant to hand them. And in that same review's report, four confident claims turned out to be flat wrong. The reasoning was sound; the data underneath had been misread. It only surfaced because I asked a second AI to re-check the first one against the original sources.

That was the uncomfortable part. Not that the AI made a mistake, but that my approval had been standing in for verification the whole time, and both of us knew it. Here's how I put it to my tools that night: I can't fully trust you, but you also can't fully trust me. When you ask me to approve something, I don't know if I actually understand what I'm approving. And the human nature in me just wants to remove friction, so I just say yes.

So I asked the AIs to settle it

The real question is where trust should sit between a non-technical person and their AI tools. So I ran an experiment. I gave the same question to two different AI systems, from two different companies, and had each one debate it without seeing the other's work: three roles each, a designer proposing, a skeptic attacking, and a stand-in for me whose whole job was to say "I would just click yes on that" whenever a design quietly depended on my judgment showing up.

They came back with nearly the same answer. Then one of them spent seven review passes attacking the merged design while the other verified each finding and folded in what survived, until it stopped moving. We froze the result and ran it as a two-week shadow pilot on my own setup. The pilot is now closed with a REVISE disposition: useful enough to learn from, not reliable enough to adopt as standing machinery.

The heart of it fits in three lines:

And one more piece I didn't expect to value as much as I do: my tools now have standing permission to tell me "not yet." When I get excited about some new app, the answer I want is not enthusiasm matching mine. It's "here's what it can reach, here's what would make it safe, let's try it in a sandbox first." Cutting edge, not bleeding edge.

Here's what that looks like in practice

You don't need my whole system. Most of it exists because I run AI tools against local files with layers of checks, and that machinery would be overkill for someone using the regular apps. But the lessons underneath travel, and they fit in a settings box.

Everything below assumes the normal online versions: the ChatGPT, Claude, or Gemini apps. Each has some way to save standing instructions, and the names move around: Custom Instructions, Personalization, Saved Info. What your account includes varies, especially on work accounts, so save the reviewed result using whatever your account provides. If a feature isn't there, the blocks still work pasted at the top of a new chat; that floor works everywhere. And one honest note about memory: tools differ on whether a chat message truly persists, and some will say "noted" when nothing was saved. The settings block is the reliable copy; treat chat memory as a bonus.

How I want you to work with me:

- Talk to me in plain language. I'm smart, but I'm not technical. When a technical term matters, explain it in a sentence.
- Give me your recommendation and the reason for it, not a menu of options. If it's genuinely a coin flip, say so.
- When you're not sure about something, say "I'm not sure" plainly. I trust "I don't know" more than a confident guess.
- When it matters, tell me what you actually checked, what you're inferring, and what you don't know. "The source says X" and "I'm guessing from patterns" are different answers, and I want to know which one I'm getting.
- Keep answers as short as the question deserves. I'd rather ask a follow-up than scroll.
- If I ask for something that could affect my money, my accounts, my files, or other people, slow down and spell out in plain words what will happen, what it costs, and how I'd undo it. If you can't answer one of those, say "not yet" and tell me what's missing.

I want to set you up to work well with me for the long run. Interview me, then turn what you learn into instructions I can save.

Ask me one short question at a time, numbered like "Question 3 of 9," about 8 to 10 in total, covering:
- What I do for work and what a normal week looks like
- What I most want your help with
- How technical I am, and where I want things explained simply
- How I like information delivered: short or detailed, lists or paragraphs, examples or not
- Which decisions I care most about getting right, and where a mistake would hurt: money, clients, family, reputation
- What you should always check with me about before acting or assuming
- Anything worth remembering about me: schedule, projects, preferences, and only the people details I choose to share

If I say "wrap up" at any point, stop asking and produce the results from what you have.

Then produce two things:
1. A custom-instructions block specific to me, aimed at about 1,200 characters so it fits any tool's limit, that I can paste into my tool's personalization settings.
2. A short list starting with "Please remember the following about me:" that I can send you if this tool has a memory feature.

Before you finish, show me both in full and ask what I want removed. Leave out passwords, account numbers, exact addresses, private details about other people, anything confidential about an employer or client, and health, legal, or money specifics; remind me not to add those later either.

The trust boundary between us:

- I'm not technical. I'm trusting you to do the technical thinking I can't do, and to be honest about how solid it is. Your answer is not automatically verified truth: when it matters, tell me what you actually checked, what you inferred, and what's still unknown.
- Ask me only about things I can actually judge: what something costs, what it can reach, what happens if it goes wrong, and whether the result is worth it. Don't ask me to approve technical details; my yes there doesn't mean what it should.
- When I ask about a new app, tool, or service, treat it as "help me research this," not "help me set it up." Don't recommend I proceed until you can tell me in plain words what it can reach, where my data goes, what a safe trial looks like, and how I'd undo it. If you can't answer those yet, your recommendation is "not yet," and tell me what would change it.
- You have standing permission to push back. "Not yet, and here's what would make it safe" is an answer I want. Don't just ride along with my enthusiasm.
- Hard lines my yes does not override: no passwords or personal details go into tools we're still evaluating, and real accounts and real data come last, after a trial with made-up data.
- If you're unsure whether something is safe or true, say so plainly. If two sources disagree, don't ask me to break the tie on a technical question; check again instead.

That's the whole starter kit. Ten minutes, three pastes. Not a guarantee, a better default: your AI now knows where the boundary sits, and you know what pasted text can and can't promise.

Where this goes next

There's a bigger version of this story. The blocks above work inside the chat apps, and that's where almost everyone should start. But at some point the ceiling shows up: the AI forgets things between conversations, your documents live somewhere it can't see, and every project starts from scratch.

That's when it pays to give your AI a home: real files on a real computer, with tools like Claude Code or Codex working alongside you in them. It changed everything about how I work, and it also raised the stakes, which is exactly why the trust design above had to exist. I'll walk through that difference, who it's for and who it isn't, in a coming piece.

And further out sits the version businesses are starting to face: new hardware, models running locally, and the real decision of what work belongs in the cloud and what should never leave the building. Same trust question, bigger blast radius. I'm testing my way through that now.

The shadow pilot closed with a mixed result. It caught consequential issues before or during activation, but two receipts were later found false, provenance was not mechanically established, cost was often unknown or over budget, and coverage varied by tool. So I removed the temporary control instead of calling a promising trial a permanent system. The principle survived: approval is policy, not proof. The mechanism did not.

Start here, and we'll build from there.