Build — Week [X]
Before we wrote the Delivery Charter, every project team at Pattern made its own call about how AI fit into the work. One team had it drafting test cases and nothing else. Another had it touching architecture decisions. A third barely used it beyond autocomplete, because nobody had told them otherwise. None of these choices were wrong exactly. They just meant that if a client asked "was this reviewed by a person," the honest answer depended entirely on which team you asked.
That's the problem a charter solves. Not "should we use AI" — we'd already answered that — but "where does AI's involvement need a human signature, and where doesn't it." Without an answer written down somewhere, the answer defaults to whoever is under the most deadline pressure that week, which is not a policy, it's a coin toss.
We wrote the charter to give that coin toss a rulebook.
What it actually is
The Delivery Charter is a working document, not a mission statement. It doesn't say "we use AI responsibly." It specifies, deliverable by deliverable, three things: what AI is allowed to produce unsupervised, what requires human review before it ships, and what triggers an escalation to someone more senior than the person doing the work.
Concretely, that looks like tiers. Some outputs — a first-pass changelog entry, a draft of boilerplate config, a summary of a long client thread — go out with AI doing most of the work and a light human check. Other outputs — anything touching production architecture, anything client-facing that makes a commitment, anything involving data handling or security — require a named human to review and sign off before it moves forward, and the charter says who that person needs to be for that category of work. And a smaller set of situations — where the AI's suggestion contradicts something a client has explicitly asked for, or where the output looks confident but the underlying reasoning doesn't hold up under a second look — get escalated rather than resolved at the point of contact.
The document also asks each project to record, briefly, where AI was involved and where a human made the final call. Not a full audit trail for every keystroke — that would be its own kind of theatre — but enough that if a client or a future teammate asks "how was this built," there's an actual answer rather than a shrug.
What changed once it existed
The most immediate change was that disagreements about AI use stopped happening project by project and started happening once, at the level of the document. Before the charter, a debate about whether AI-generated code needed senior review would resurface on every new build, because there was no prior answer to point to. After the charter, the answer already existed. People could disagree with the answer — and did — but the disagreement had a fixed target instead of restarting from zero each time.
It also changed how we onboard people onto a project mid-stream. Previously, understanding "how this team uses AI" meant asking around and piecing together an informal culture. Now there's a document that states it, which matters more than it sounds like it should when someone is stepping into unfamiliar work under time pressure.
And it gave us a defensible answer to the question clients ask more often now than they used to: who actually checked this. We can point to the tier the deliverable sits in and say what review it went through, rather than reconstructing an answer after the fact.
Where it created friction
None of this was frictionless, and pretending otherwise would defeat the point of publishing it.
The first friction was speed. The tiering system means some work that used to move in one step now moves in two — draft, then review — even when the draft was obviously fine. For low-stakes deliverables, that review step sometimes feels like ceremony rather than protection. We've adjusted the tiers more than once because the first version was too conservative in places where the risk didn't justify the slowdown.
The second friction was disagreement about where the lines sit. Reasonable people looked at the same category of work and drew the review boundary in different places — one person's "this needs senior sign-off" was another's "this is boilerplate, ship it." The charter doesn't resolve that disagreement by being written down. It just gives the disagreement a place to happen before the work ships, instead of after something goes wrong.
The third friction is that the document ages. The tools we had in mind when we wrote the first version aren't the tools doing the work now, and a rule calibrated to what AI got wrong six months ago isn't necessarily calibrated to what it gets wrong today. We treat the charter as something that gets revised, not something that gets ratified once and left alone — which means someone has to actually revisit it, and that's easy to let slip when delivery work is busy.
The fourth, and probably the least comfortable, is that writing down "AI can do this unsupervised" is also writing down "we are formally accepting the risk of what happens when it's wrong." That's a different thing from using AI informally and trusting your own judgement in the moment. A charter makes the judgement explicit, and explicit judgement is easier to hold someone accountable for — including us.
Why we made it public
We didn't publish the charter because we think every studio should copy it line for line. Delivery contexts differ enough that the specific tiers we've landed on won't map cleanly onto a different team's risk profile.
We published it because a document like this is easy to claim and hard to fake. Any studio can say "we review AI output carefully." Fewer will show you the actual boundary between what gets reviewed and what doesn't, and fewer still will admit which parts of that boundary they've already had to move.
If you're an SME leader working with a studio or vendor that uses AI in delivery — and increasingly, all of them do, whether they say so or not — the useful question isn't whether they use it. It's whether they can show you where the human checkpoints sit, and whether those checkpoints have ever changed because reality proved the first version wrong. If the answer is no changes, ever, that's worth being sceptical of. Judgement that never needs revising usually isn't being exercised.
If you want to see how we've structured this, or want help thinking through what a similar boundary should look like for your own delivery work, get in touch.
