Services
Three engagements, in the order most teams take them. Each stands alone — the audit isn't a sales call with an invoice attached, and plenty of teams stop there.
I take ten to fifteen recent pieces and read them against the work you're proudest of — usually something written before the volume went up. Close reading first, then measurement: sentence-length distribution, paragraph uniformity, function-word frequencies, the structural habits that separate your best work from your average work.
What comes back is a written assessment in plain language. Where the voice is holding, where it slips, which specific tells are doing the damage, and what would have to change to fix it. Not a score. Not a detector reading. An account of what's happening in the prose and why readers respond to it the way they do.
Half a day with the people actually producing the work. It runs on your material, not case studies — we pull apart pieces your team wrote last month, which is uncomfortable for about ten minutes and then becomes the most useful part.
Three things get covered: the named structural tells and how to spot them at reading speed; how to prompt for voice rather than topic, which is a different skill from the prompting most teams have taught themselves; and an editorial check short enough that people will actually run it under deadline.
The full four stages. I analyse your corpus, write the specification, implement it as production prompts for your platforms, and hand over a QA framework with a measured baseline so drift becomes visible rather than something you notice a quarter late.
The specification is the durable part, and it's deliberately platform-independent — a document describing how your voice behaves, not a prompt tied to one product's current feature set. Prompt libraries are downstream implementations of it. When the tools change, and they will, you rewrite the implementation in an afternoon instead of starting again.
After the build
A system left alone drifts — new writers, new products, new tools, and a specification slowly stops describing what you publish. A retainer keeps it current: periodic drift measurement against the baseline, specification updates as the brand moves, and a standing line for the awkward pieces.
Available once a system is in place. Scoped monthly, priced to the volume you're publishing.
The point of the specification is that you can run it without me. The retainer is for keeping it true, not for keeping me in the room.
Questions I get asked
The prompts will need rewriting. The specification won't. That's the reason it's written as a platform-independent document describing how your voice behaves — sentence architecture, how you handle a caveat, what you never do — rather than as instructions for one product's current interface.
When a model updates, the implementation layer gets rebuilt against a spec that still holds. This is the single most common objection and it's a fair one; the answer is structural, not reassurance.
No, and I'd decline that work. Detectors are unreliable in both directions, and building toward one is building toward a moving target that has nothing to do with whether your writing is any good.
The target here is a human reader deciding whether to keep reading. That's a harder standard and the only one that pays.
Most guidelines describe a personality — friendly, expert, approachable — which is useful for a designer choosing a typeface and useless for a model generating a paragraph. Neither a language model nor a new hire can act on an adjective.
A specification describes behaviour precisely enough to be executed and checked. Your existing guidelines usually survive as the input; they're just not the thing that does the work.
On request, for clients with data-sensitivity constraints — legal, health, government, financial services. Locally-hosted models are workable and the technical barrier is low.
Being straight about the trade-off: open-weight models currently hold a specified voice less reliably than the frontier ones over long documents. If your data can leave the building, you'll get better output. If it can't, this is a solved problem with a quality cost worth naming up front.
No. I build the system your team writes with. Content production is a different business with different economics, and anyone who builds your system and also sells you the writing has a quiet incentive for the system never to work quite well enough.
Next step
Tell me what you're publishing and at what volume. If I can help I'll say how; if I can't I'll say that instead.
Book a call