← All work

Brand Voice Operator · Self-directed · 2026

Turning a company's own writing into an operable brand voice

A brand voice a new hire, a freelancer, or an AI could ship on day one using only the files. Not a document that describes a voice, a system that enforces one.

Read your writing

raw lines, not a brief

Evidence gate

2 real quotes or it's cut

Sharpness bar

nothing that fits any brand

Operable voice

shippable on day one

A folder, not a prompt. Constraint is the feature.
3
sample voices, very different brands
2 quotes
backing every attribute it claims
1 folder
many runtimes, one contract

01 · Problem

Brand voice is the softest brief in marketing

Warm but not cutesy, premium but not stiff. Everyone nods; nobody can hand it off. The guide describes a vibe and hopes the next writer absorbs it, and that fails the only test that matters: could a new hire, freelancer, or AI tool write on-brand on day one using only the guide?

A document that describes

“Professional and approachable” fits everyone, cites nothing, changes no sentence. A vibe cannot be wrong.

A system that enforces

Specific, evidence-bound, falsifiable. Every claim tied to real lines from your writing, or it isn't made.

02 · Solution

Reject the document: build it as a folder

The operator is a set of markdown files you drop into a Claude project. Claude reads them and becomes the operator: an identity file, a rules file with the staged logic, and a reference folder holding the method. It runs on Interpretable Context Methodology, folder structure doing the work code would otherwise do. No scripts, no install. The files are the program, which is why it runs in a plain browser project.

Two rules hold it up. Evidence over invention:every attribute is backed by two real quoted lines from your writing, or it isn’t claimed. The sharpness bar: anything that would fit any brand in the category gets rewritten or dropped.

03 · The moat

The folder is commodity. The calibration is the moat.

Anyone can fork the repo; it’s a dozen markdown files. What doesn’t come with the fork is what makes it work: the calibrated examples that define “sharp,” the never-list method that makes a rule generalize, and the discipline to refuse output that reads like a machine wrote it.

Could a new hire ship on-brand copy on day one using only this?
That question is the whole spec. A document that describes a voice fails it. A system that enforces one passes.

04 · Proof

One artifact per run, portable across every runtime

Each run produces one artifact: a north star sentence, the tension the voice lives between, three to five evidence-backed attributes, a numbered never-list, channel playbooks, and an AI prompt pack. Plain markdown, so it feeds any model or a new hire’s first week. Three sample voices it produced sit in the voice gallery.

The live voice gallery: a generated voice card and the same voice rewriting a real appointment reminder.
One generated voice in the live gallery, and the voice doing real work. Click to explore all three.

The proof point is portability: the same folder runs in Claude Code for rigor or a browser project for reach, and ingests a voice doc from another tool as happily as it reads raw writing. One set of files, many runtimes, one contract.

05 · What's next

Turn the example library into the product

It’s only as sharp as its examples, and right now those examples are mine. Every real voice I run through it yields one validated, anonymized input-to-output pair. A curated set of those is what a competitor can’t fork, and it compounds: more voices, sharper inference, better output.

The scaffold was always going to be easy. The calibration is the work.

The build is open-sourced, so fork it if the scaffold is all you need. If you want it tuned into something sharp for your brand, send me a message.

Send me a message

raph@raphaelmercado.devlinkedin.com/in/raphmercadogithub.com/raphaelmercado-coder