We Split WHAT You Say From HOW You Say It

There's a one-line commit in our writing product's history that I think about more than any feature we've shipped:

"voice analysis extracts style, not content — subjects flow into Knowledge."

It's filed as a bug fix. Bug 1.3, to be exact. And the bug it fixes is the same bug sitting inside almost every "AI that writes in your voice" product on the market right now — usually not filed, usually not even noticed, because it looks like success.

Here's the failure. You feed a voice tool ten writing samples and ask it to learn how you write. Then you ask it to write about something new, and the output keeps bending back toward your old subjects. Train it on your posts about, say, coffee roasting, ask for a piece about hiring, and you get hiring content that somehow wants to talk about roast profiles. The engineering note on our fix describes the mechanism plainly: the single-pass analysis described what the samples were about instead of how the person writes, so — quoting the comment verbatim — "generation parroted sample subjects instead of authorial style."

The tool didn't learn your voice. It learned your topics and called them your voice. And in a demo, that's indistinguishable from working — because in a demo, you ask it to write about the same things you gave it.

Two signals, braided together

The root cause isn't a bad model. It's a category error about what a writing sample is.

Every piece of writing carries two signals braided together. There's WHAT it says: the subjects, the facts, the stories, the positions, the numbers. And there's HOW it says it: rhythm, sentence-length variance, how often you ask questions, whether you use fragments, what you do with an em dash, whether you open cold or wind up, how you argue. The first signal is content. The second is voice. They arrive in the same bytes.

Hand that braid to a language model in one pass — "analyze this person's voice" — and the model does what statistical machines do: it summarizes everything, dominant signal first. And the dominant signal in any writing sample is the subject matter. Topics are loud. Style is quiet. So the "voice profile" comes back as a topic profile with some adjectives sprinkled on top, and every future generation drags the old subjects along like sediment.

This is my larger conviction about AI writing in miniature: generic output is rarely a model problem, it's an encoding problem. The statistical middle is the enemy, and you don't escape it with a better adjective. A voice described as "professional yet approachable" — the kind of thing single-pass analysis produces — describes nobody, because it describes everybody. Adjectives are not a voice. Measurements are. Specifics are. And you can't get either until you separate the two braided signals on purpose.

So we split them. Structurally, not with a politer prompt.

Pass one: catalog the WHAT

The first pass is a content pass, and it is explicitly forbidden from talking about style. Its job is to catalog what the samples are about: topics, and then individual entries — facts, stories, positions, people, stats, quotable lines.

Two things make this pass more than a summary.

First, every extracted entry must carry an exact verbatim quote from your own text as evidence. Not a paraphrase — the actual characters. Second, that requirement is enforced by code, not by asking nicely. After the model returns its catalog, a deterministic filter checks every entry's evidence quote against the source text (tolerant of curly quotes and whitespace, nothing else) and drops any entry whose quote isn't actually there. The comment in the source calls this the fabrication rule, "project-level, non-negotiable": only content verbatim in the samples survives. The filter cannot be sweet-talked, because the filter cannot generate. It can only match.

That matters because of where this catalog goes — which we'll get to. But the immediate effect is that pass one produces something honest: a structured inventory of your actual subject matter, every line of it traceable to your own words.

Second-order benefit: pass one's topic list becomes the contamination map for pass two.

Pass two: measure the HOW

The second pass analyzes how you write — with the first pass's topic list handed to it as an exclusion list. The design requirement, stated in the system's own terms: the extracted profile has to stay valid if you switched to entirely different subjects tomorrow. Nothing from the topic list is allowed into the tone descriptors, the vocabulary lists, the opening and closing moves, or the identity narrative that will eventually drive generation.

And critically, this pass doesn't get to guess at the measurable stuff. Before any model sees your samples, plain deterministic code — no LLM anywhere in it — computes a battery of style metrics: average sentence length and its standard deviation, fragment ratio, question and exclamation ratios, em dashes per hundred words, contractions per hundred words, first-person versus second-person density, paragraph shape, list usage. The engineering comment explains why this exists: "the model used to guess avg sentence length etc. — now it gets ground truth."

Those measured numbers are injected into the analysis as facts the model must not contradict. Then — belt and suspenders — after the model returns its profile, code overwrites the measurable fields with the measured values anyway. The comment on that module states the property this buys: two sample sets in the same authorial style yield the same measurements regardless of topic. Your rhythm is measured, not vibed.

Two more deterministic guards run behind the model. A residue scrubber checks the profile's vocabulary fields against the topic list — with light stemming, so if "roasting" was a topic, "roast" and "roasted" can't sneak into your "approved vocabulary" either — and strips what leaked.

Where each half goes

Here's the part I find genuinely elegant, and it's the part the commit message compresses: subjects flow into Knowledge.

The WHAT catalog isn't discarded as contamination. Your subjects, your stories, your stats — those are real assets. They're just not voice. So every grounded entry from pass one lands in a knowledge base attached to your voice: visible, editable, provenance-tagged so you can always tell what was extracted from your samples versus what you typed in yourself. Re-running the analysis dedupes against what's already there instead of piling up copies.

The HOW profile becomes the voice identity — the thing generation actually runs on.

And at generation time, the two halves re-enter the prompt as separate, ordered sections: the voice identity first, then any modifiers, then the knowledge base, then the task at hand. Assembled in a deterministic order, every time. Your facts show up as facts the writing can draw on. Your voice shows up as the register the writing comes out in. The braid gets rebuilt on every generation — but now it's rebuilt from two clean strands you can inspect and edit independently, instead of one tangle nobody can debug.

That's the practical payoff of the split, and it's bigger than topic-portability. When output sounds wrong, you can now see which half failed. A collapsed system gives you one dial labeled "regenerate and pray."

What the split costs

I won't pretend the seam is free, or clean.

There's a limit worth naming too, from our own engineering notes: extraction is the strong half of this system, and "after a voice is born it is static prose" — that's a verbatim self-criticism from an internal requirements doc, and it points at where the harder work sits: making the machinery around the split steerable and honest, not adding more extraction. One related finding from that research pass I'd give away to anyone building in this space: when selecting example texts to guide generation, matching them by topic measurably hurts style fidelity. The internal decision reads: "Exemplar selection stays style-first, never topic-matched." Even downstream of the split, topic-gravity keeps trying to reassert itself. You have to keep telling it no.

The test you should run on any voice tool

If you're evaluating anything that claims to write in your voice — ours included — here's the test the whole architecture is built to pass, and it takes five minutes.

If the answer is one undifferentiated "voice profile," you already know what happens next, because you know what a single pass over braided signals produces.

Your voice is not your topics.

A note on state: the two-pass split described here runs in our writing product today. The work around it, making that machinery steerable and honest rather than adding more extraction, is in build and not shipped.