Separate review, connected tools, and the approval boundary

Draft and review in separate conversations. A conversation that produced a brief is a poor judge of it — the reasoning that made the choices is still in view, so the choices look justified. A fresh chat given only the source inputs and a rubric is genuinely checking.

Then treat the reviewer as what it is: another fallible model. Take its findings one at a time and decide accept or reject against the source yourself. A reviewer that flags a missing owner is right or wrong about a fact you can check in ten seconds — and reviewers invent problems as readily as drafters invent facts.

Connected tools change the stakes, because now something can reach real data. Before granting anything, read what an integration says it reads and what it can change, and write the two lists down. Do this without granting new access — inspecting a description costs nothing and is the only moment you're deciding freely. If your account has no integrations, design a mock one on paper; the reasoning is the transferable part.

Here is the sentence to carry out of this level. Writing "read only" in your prompt is not a read-only permission. Instructions describe desired behaviour; they do not enforce access control. If an integration is authorised to write, then the thing standing between it and a write is a sentence — and you already know from Level 3 that a sentence can be argued with by text arriving from outside. The scope you granted is the boundary; the prompt is a preference.

So draw the approval boundary explicitly. Two columns: what the workflow may prepare on its own, and what requires you. Preparation — drafting, extracting, summarising, proposing — is the whole left column. Sending, publishing, deleting and anything a stranger will see belongs on the right, always.

Loading your workspace…