Diana asked a sharp question about what controls we have for adjusting the style and voice of a ShurIQ report. When we request simpler language, what actually happens inside the system? And — dialing language up or down by audience — would dentists want an easy read or a technical read?
The honest answer is "depends on which dentist," and that answer is only useful if the system can deliver both without becoming a different system. That's the design problem. It's also where almost every AI-powered intelligence platform on the market fails quietly.
Why most BI systems can't dial style
The default architecture for an AI-generated report is a single prompt — sometimes a layered prompt, but logically one — handed to a frontier model with the source data appended. To shift voice or audience, you change the prompt. Maybe you fine-tune. Maybe you train a LoRA on house style. Then you regenerate, read it, notice the drift, retune the prompt, regenerate, and so on.
Two things tend to happen. First, voice drifts back to the model's mean across regenerations and across topics — the rarer the source content, the worse the drift, because the model falls back on its priors. Second, even when you nail it for one report, you can't reliably reproduce the same voice on the next one without re-running the whole tuning loop. The "style" lives in nobody's hands; it lives somewhere between the prompt, the model weights, and luck.
This is the trial-and-error trap that 99.9% of AI BI products are stuck in. Style is treated as a parameter you nudge. Whatever you tuned doesn't survive into the next report.
Style is a separable concern
The ShurIQ design starts from a different premise: voice, grammar, archetype, and source-grounding are different concerns and should live in different modules. Each one has its own brain, its own rules, its own templates, and its own evaluation harness. You compose them at runtime instead of squeezing all of it into a single prompt.
We've already shipped this pattern in the ContentFactory pipeline that sits next to ShurIQ in the same stack. ContentFactory turns source materials into podcast episodes and LinkedIn posts, and every output is generated from three separable inputs:
- Speaker profile. A named cast — Jonny D + Limore for linkedin_thought_leadership, or The Architect + The Producer + The Scout for expert_panel. Each speaker has a voice, a stance, a domain expertise, and even an audio voice ID. Switch the speaker profile and the whole show shifts personality without anyone touching the source material.
- Episode profile. The shape of the show — linkedin_short is three segments optimized for quotable extracts; deep_dive is six segments for expert-panel analysis. Same speakers, different episode profile, different output structure.
- Transformations. Modular post-processors — linkedin_extractor pulls 3-5 LinkedIn post drafts from a transcript; negative_space finds the structural gaps; content_angles suggests multi-platform reuse. Each transformation has its own grammar and runs independently.
The architecture lets us swap any one of these without touching the others. That's separation of concerns in the literal software-design sense, applied to creative output. The same source transcript routes through linkedin_extractor and produces post drafts; routes through negative_space and produces a gap report; routes through content_angles and produces a multi-platform plan. Three different artifacts off the same evidence base. The transformation is a swappable module, and the choice is explicit.
Bringing the same architecture to ShurIQ
ShurIQ reports already use this pattern at the archetype layer. When the analyst opens a brief, the first dropdown asks: Editorial Brief, Pressure Test, or Cold Read? Each archetype composes a different subset of the 19 atomic sections in the ShurIQ report grammar. Editorial Brief gets the full rubric, the stack rank, the bridge. Cold Read gets a tighter subset — context, topology map, structural gaps, action set. The same nineteen building blocks, three different reports.
What ships next week is the second dropdown: Author Persona. The same separation of concerns, applied to voice and prose style.
Two flavors:
- Named personas — explicit authors, loaded with training data, source examples, and a grammar of their own. Think of it as casting an editor for the report. Some names will be internal voices (the SHUR Creative editorial voice, my own, Limore's). Some will be archetypal (the Layperson's Guide, the Industry Translator, the Skeptical Auditor). Each one has its own tone instructions, its own do-not-touch list of words and constructions, its own length norms, and a corpus of examples that anchors the voice. - Style-types — categorical rather than personal. Layperson. Non-technical conversational. Standard analyst. Technical specialist. Pick one and the report adopts that register without committing to a specific named author.
The two flavors complement each other. Style-types are coarse-grained dials anyone can use. Named personas are a finer dial for clients who want a specific editorial voice — the kind of consistency that signals brand discipline. We can author as many as we want; I'm starting with a few of each and growing the library as we use it.
What sits underneath
The reason Author Personas can be modular without becoming brittle is that there's a third layer below them: the style ontology. Voice rules live one layer down, encoded as graph-structured patterns rather than prose conventions:
- Tier 1 — Universal AI tells. "Leverage," "synergy," "game-changing," "in today's rapidly evolving landscape," "Let that sink in." Buzzword density gates. Banned constructions like "not X, but Y" inversions. These apply always, regardless of audience. - Tier 2 — Brand bible. Per-organization voice rules. SHUR Creative says "stack rank," not "leaderboard." Some clients want "tearsheet," some want "brief," some want "memo." This is the layer where house style lives and where each client we onboard gets a slot for theirs. - Tier 3 — Author voice. What's distinctive to the named persona — sentence rhythm, vocabulary preferences, the specific moves the author makes when introducing a hard idea, the genres they pull from when reaching for a metaphor.
Each tier has a consensus score. Tier 1 violations are auto-rejected. Tier 2 violations get flagged for review. Tier 3 violations are advisory — they preserve voice without enforcing it as law. The persona is a composition of these tiers plus a small set of rules of its own.
This is what gives the dropdown its teeth. When Diana picks "Layperson's Guide," the report engine doesn't just tell the model to be friendlier. It loads a layperson-style persona, which inherits Tier 1 and Tier 2 from the SHUR brand bible, then adds its own Tier 3 rules: short sentences, named examples instead of abstractions, inline glossary rather than at the end, no Latin connectives, an explicit pause before any technical claim. The grammar shifts. The archetype's structural skeleton (sections, ordering, length budgets) stays intact. The source-grounding stays intact. The stack rank, gap analysis, and rubric scoring stay intact.
Diana's question, answered
So: do dentists want an easy read or a technical read?
"Dentists" is too coarse a unit to ask the question about. A dental hygienist scanning a category report wants the layperson read. A periodontist evaluating a competitive entrant wants the technical read. A practice owner deciding whether to switch suppliers wants the executive read — short, decision-grade, jargon-free.
What ShurIQ lets you do, starting next week, is deliver all three off the same source and the same rubric. Same evidence. Same stack rank. Same gaps. Three different author personas. Three different reports. The reasoning is identical; the voice and prose adapt to the reader.
This is what regulatory-grade intelligence has to do to be useful. The instrument is constant across audiences. The presentation adapts. And the presentation has to be controllable from a dropdown rather than from a six-week prompt-engineering cycle that drifts back to the mean two reports later.
What this lets stakeholders do
Pick the persona that fits the recipient and trust that the underlying analysis is stable across cuts. Compare two cuts side-by-side and use the divergence to test whether the analysis actually holds across audiences — if a structural gap shows up in the technical cut but disappears in the layperson cut, that's a tell about which words were doing load-bearing work. Author your own persona for your firm and reuse it across every report we run for you. Walk into a client meeting with three printable cuts and let the room pick which one to discuss.
What's still open
How do personas accrete training data without becoming pastiches of themselves? Who at the agency or on the client side is qualified to author a new persona, and what's the minimum corpus required to define one well? When the same source data renders three radically different reports, which version is the "report of record" — and how do we handle the audit trail when a reader from one cut asks why the other cut emphasized different gaps?
These are real questions. They're the right kind of question — questions about a working instrument, asked while the instrument is in use.
Related
Stakeholder intent is dynamic — the same separation-of-concerns architecture, applied to intent instead of voice.
How to get unstuck — re-sensing the terrain when the map stops matching.
Diversified ≠ productive — diagnosing a stalled discourse.
Discourse has weather — the flywheel's opening frame.