On this page
Drafts used to fail on voice while every fact checked out. We fixed that upstream. What's left is whether to tell people when we stop reading.
A couple of months ago, four drafts written for me by our systems had every fact right and were still wrong. The names were correct, the dates were correct, and everything in them came from something real.
Each problem sat in something a fact check doesn't look at.
We haven't seen anything like it since. This week covers what those four had in common, what we changed, and the question that's left now that the problem has mostly gone away.
Last week was reads, the rung where an answer is an action for whoever relies on it. This week is drafts, where the system writes and a person decides whether it goes out.
What went wrong
All four traced to the writer, or the checker, not knowing how the author works. In one case I was drafting a hard email to someone we work with. We keep a profile of how I talk, built from recorded calls, and it's good for what it was built for, which is scripts. The draft that came back had lines like "Here's the part I haven't said well" and "Where it went sideways is that." I might say either out loud. I'd never write them. My written paragraphs run one to three sentences, I use contractions constantly, and I have one habit, an ellipsis in the middle of a sentence where most people would use a dash. We pulled twelve emails from my sent folder and the next draft sounded right.
The system had my voice from a different surface.
In another I asked for a follow-up after a call. The draft had a paragraph telling the person why the approach they'd described made sense, all of it accurate and straight from the call. I cut it. My emails move something forward and stop, and restating someone's thinking back to them is filler at best and condescension at worst. The same draft said a document would be sent "shortly" when nobody had committed to a time, and a soft word like that becomes a promise the other person measures you against.
The third was the audit. Later I looked at an internal update about a release. We run an audit for patterns that read as machine-made, and it passed this one with a few cosmetic notes, because the message was dense with real names, a repository, a timestamp and an attachment. I said I was pretty sure AI wrote it. A release term that's correct for the work and too formal for a quick note in chat gave it away, along with a sentence that treated an ordinary step as a milestone and a finish too tidy for the channel. The audit had treated specifics as evidence of authorship. It had also never seen a line the supposed author wrote.
Specifics prove the facts came from somewhere real, and a model handed a ticket produces perfect ones.
The fourth was a reply to someone who had sent written feedback, with several points and a direct question. The draft confirmed the meeting time and promised answers later, and skipped every point they'd raised. Every fact in it was right, and it read as if I hadn't read their email.
What we changed
We stopped trying to catch these in review and started preventing them before the draft exists. Before anything gets written in my name, the system pulls real samples of what I've written in that kind of message and that channel: sent mail for email, published pieces for this newsletter, and a different register for each. The standing rules I've given it load before it starts: no commentary on what the other person told me, no time words nobody agreed to, replies that name each point the other person raised.
Review changed too. The register check comes before the fact check, and when there's no sample to compare against, the answer we accept is that the register can't be verified.
That's a worse answer than a pass and a better one than a guess.
What we see now
Nothing like those four has come up since. Part of that is the models. The current ones are better at the plainer misses without being told. The larger part is that the writer starts with the right context, which is a cheaper place to fix a problem than review.
The corrections we still make are context gaps, and each takes one rule. More recently it was a signature block the mail system already adds on its own, and a draft created before the terms were settled. Neither was about voice.
Chuck's promotion rule says a task moves up a rung when its failure mode at the current rung is known and rare. For voice and register on drafts, we're there. I still read everything that goes out in my name, and that hasn't changed.
What's changed is that the read now mostly confirms, which raises a question I didn't have then: whether I need to read all of it.
The question we haven't answered
Professional offices ran into this long before AI did. A letter goes out over an attorney's name and the attorney may never have read it. The convention is a mark that tells the recipient so. "p.p." before a name, short for per procurationem (opens in a new tab), means signed on behalf of, by someone with the authority to do it. A letter that went out before review used to carry "dictated but not read." Either note tells the reader two things: someone other than the named person produced this, and the named person delegated that.
We don't have an equivalent. If some of what goes out in my name stopped getting my read, my instinct is that the recipient should know. I don't know what the line should say, whether it belongs on every message or only some, or whether the people receiving it would take it as a courtesy or as a disclaimer.
Chuck's rule asks for a bounded, reversible step and a written paragraph of what the system may do alone. We haven't written the paragraph.
A disclosure line looks like part of that paragraph, because it keeps the delegation visible to the person on the other end.
If a company used AI to write to you in a person's name without that person reading it, would you want to be told, and where would you expect to see it? Leave a comment. I'll read every one.
Next week is acts, from Chuck, where the system doesn't wait for anyone to hit send. The question gets harder there.