The
HUMAN_INPUTmarkers that appear in this article are placeholders left by the AI writing skill indicating “a human should fill in the confirmed value here later” (format example:<!-- HUMAN_INPUT: enter a value -->).
When designing pillar and spoke structures, the question of “who are we writing for?” splits into two distinct axes: an outer axis that determines distribution targets and KPIs, and an inner axis that determines the narrative voice and terminology thresholds. When these two axes are conflated before writing begins, pillar prose collapses to a vague median — content that fails to resonate with either audience, averaging out into text that lands with no one.
This article explains the design for separating the outer axis as cluster and the inner axis as persona in SSOT (Single Source of Truth), and running them through the pipeline. The intended audience is content pipeline designers who have implemented this separation using blog-ops/config/audience-tracks.json and G11 in scripts/blog-gate.ts.
→ For an overview of the owned media pipeline centered on the mcluhan engine (context compression engine), see mcluhan Engine Design Principles.
Cluster Is the Outer Axis — Determining Distribution, KPI, and SEO
Responsibility Definitions for business cluster and tech cluster
The responsibility of cluster is to determine where and to whom a piece will be delivered. blog-ops/config/audience-tracks.json defines two axes: business cluster and tech cluster.
The business cluster carries primary_kpi: "lead-gen / inquiry CV" and defines primary_audience as executives, business owners, and PMs. The tech cluster carries primary_kpi: "brand penetration / engineer recruiting / dev org credibility" and defines primary_audience as engineers and architects doing AI-driven development.
These two differ fundamentally in KPI. The business cluster targets inquiry conversions, so it presents an executive summary and three key takeaways from the lead paragraph, structured so a decision-maker can assess value in 30 seconds. The tech cluster targets brand penetration and engineer recruiting, so it ensures technical depth through a structure of problem → pattern → design core → pitfalls.
What cluster Determines
cluster determines the following three things:
Primary keyword design: business cluster articles set primary keywords to phrases that executives search for (e.g., “AI workflow improvement case study”, “content operations automation”). tech cluster articles choose phrases that engineers search for (e.g., “content cluster persona design”, “pillar spoke pipeline”).
Distribution time slot: src/config/publish-policy.ts defines five time slots (09:00 / 11:00 / 14:00 / 16:00 / 18:00 JST) (2026-05-21 5d8e531). A commit exists that moves business cluster articles to the 18:00 slot (305044d: six business cluster articles moved from 09:00 → 18:00).
Cross-link targets: business cluster articles carry cross-links to business spokes within the same cluster and to sister pillars (on the tech cluster side). This ensures a path for business readers who develop interest in tech to flow into the tech pillar.
Persona Is the Inner Axis — Determining Narrative, H2 Weight, and Terminology Thresholds
What persona Determines
The responsibility of persona is to determine the “voice” of the body copy. Even within the same cluster (e.g., tech cluster), setting senior-engineer vs. architect in audience.primary changes the texture of the writing.
The tech cluster in audience-tracks.json defines six personas: junior-engineer, senior-engineer, tech-lead, architect, solo-developer, data-engineer. The business cluster defines: executive, business-owner, cto, marketing-head, pm-product, sales-head.
With six personas in each cluster, a total of 12 personas are managed in audience-tracks.json.
persona determines the following:
H2 order and weight: For the senior-engineer persona, implementation details go in the first half, with business impact compressed to the end. For the architect persona, the trade-offs behind design decisions come first.
Example resolution: For the junior-engineer persona, explanations unfold carefully from pattern name definitions through to code snippets. For the tech-lead persona, discussions proceed with team-scale applicability and operational cost assumed as context.
Terminology thresholds: The senior-engineer persona can use commands like grep -rn "chr(65" without explanation. The marketing-head persona instead needs supplementary business vocabulary such as “character code calculation.”
Narrowing to One persona Lets You Route Secondary Personas via Cross-Links
Setting two or more personas causes the writing to average out. A pillar targeting both audience.primary: "senior-engineer" and audience.primary: "architect" simultaneously ends up trying to cover both implementation details and trade-offs, producing text that is incomplete for either.
The solution is to fix audience.primary to a single persona and design articles for personas listed in audience.secondary as sister pillars or spokes. Placing an anchor link at the end of the pillar body — “For the design decision perspective, see [a separate article for architects]” — naturally routes readers with secondary personas.
→ For a concrete implementation of this design, see Narrowing audience.primary Clarifies Sister Pillar / Spoke Design.
Implementing the Two-Axis Separation in SSOT
clusters × personas Design in audience-tracks.json
blog-ops/config/audience-tracks.json uses cluster as the top-level key, with each cluster holding a list of personas beneath it.
{
"clusters": {
"business": {
"personas": ["executive", "business-owner", "cto", "marketing-head", ...],
"narrative_style": "結論先出し、数字・経営判断を前半に...",
"default_writer_skill": "blog-case-write"
},
"tech": {
"personas": ["junior-engineer", "senior-engineer", "tech-lead", "architect", ...],
"narrative_style": "課題 → パターン → 設計の核 → 落とし穴 → まとめ",
"default_writer_skill": "blog-tech-write"
}
}
}cluster carries narrative_style and default_writer_skill. This is the “outer design.” Individual personas are specified as audience.primary in the brief at blog-ops/articles/{slug}.yaml. This is the “inner design.”
Roles Carried by audience.primary / cluster Fields in the brief YAML
In the brief YAML, the two axes are separated into distinct fields:
cluster: tech # 外向き: どの cluster で配信するか
audience:
primary: "senior-engineer" # 内向き: 誰に向けて書くか
secondary:
- "architect"
narrative_weight:
primary: 75 # primary persona の narrative 重心割合
secondary: 25cluster: tech determines the choice of distribution target, KPI, and writer_skill. audience.primary: "senior-engineer" determines the body’s tone, vocabulary, and H2 weight. Because the two axes are not mixed into the same field, each step in the pipeline can reference only the axis relevant to its own responsibility.
The effect of this design became apparent during the bateson pillar revision. Before introducing SSOT, target_audience.role in the brief was written in freeform as “both executives and CTO,” so the body mixed engineering constraints (tenantId, adapter pattern) with executive decisions (outsourcing vs. productization), resulting in prose that landed with neither business nor tech readers. After splitting SSOT into clusters × personas, the same topic was divided into two pillars: business cluster (audience.primary: business-owner, code snippets removed, executive terminology in the foreground) and tech cluster (audience.primary: senior-engineer, design patterns front and center). Each prose could then be written with a consistent vocabulary. The two-axis separation structurally determines vocabulary choices at the writing stage itself.
Integration into the Pipeline and Gate
blog-gate G11: Design That Fails on Missing audience.primary
Separating the two axes cannot be guaranteed by SSOT alone. Preventing the human error of “forgot to fill it in” requires a mechanical gate.
scripts/blog-gate.ts defines 13 required checks G1 through G13. G11 fails the pipeline when audience.primary is missing from a brief with is_pillar: true. The old freeform target_audience.role field was not machine-verifiable, but by cross-referencing against valid values in the taxonomy defined in audience-tracks.json (e.g., senior-engineer is valid; general engineer is invalid), the gate can now detect not just missing values but invalid ones too.
With G11 in place, the pillar is structured so that it “cannot proceed without a persona.” If persona is not determined, the brief audit also fails, and the writing phase cannot begin.
narrative arc Only Fires When Both Axes Are Set
When both the cluster and persona axes are in place, each step in the pipeline can operate with a consistent decision basis.
blog-tech-writereads cluster=tech and audience.primary=architect and generates a narrative with design decisions and their rationale front and centerblog-reviewverifies, beyond G11, the consistency of narrative_weight (whether at least 75% of the narrative center of gravity is allocated to the primary persona)blog-gatefails on missing or invalid values in either axis, preventing the pipeline from passing through unchecked
When writing proceeds without a decided persona, prose becomes median text written to “work for both senior-engineers and architects.” Neither persona feels it was written for them. The two-axis separation is the structural solution that prevents this mediocrity at the design stage.
→ For details on the gate design that mechanically detects missing personas, see Design That Fails the Pipeline When persona Is Missing.
Summary — Why Separate cluster and persona
What happens when cluster and persona are conflated? Trying to determine body tone through cluster (outer) produces a crude split: business cluster = business vocabulary, tech cluster = code-heavy. Trying to set distribution KPI through persona (inner) produces incoherent mappings: senior-engineer = engineer recruiting, architect = brand penetration.
By separating the two axes and encoding them in SSOT:
- cluster handles the outer design (distribution target, KPI, keyword strategy)
- persona handles the inner design (narrative arc, H2 weight, terminology thresholds)
- pipeline references both axes to generate and verify body copy that resonates with a specific reader
This separation is the foundational design prerequisite for pillars to evolve from articles that “anyone can read” into articles that “resonate strongly with a specific reader.”
Four existing pillars have had audience.primary retrofitted. From the changed files section of blog-ops/retros/2026-05-18-persona-taxonomy-drives-narrative.md: reset-timeline (executive), mcluhan (senior-engineer), bateson tech (senior-engineer), bateson business (business-owner).
Once the cluster × persona design is complete, the next question is how to design the role division between sister pillars and spokes. When audience.primary is narrowed to one, it becomes visible where the remaining personas fit within the cluster as a whole. That design is covered in Narrowing audience.primary Clarifies Sister Pillar / Spoke Design.