The
HUMAN_INPUTmarker used in this article is a placeholder left by AI writing skills to indicate “a human should fill in a confirmed value here later” (example format:<!-- HUMAN_INPUT: enter value -->).
A pillar was designed as a business cluster. The H2 headings were framed in business terms, narrative_weight.primary was set to 75, and the lead opened with “executive judgment.” Yet the body paragraphs kept defaulting to engineering terms as their subjects. Structure and vocabulary can fake audience separation—but prose density reveals the truth.
The bateson pillar is the concrete example. With bateson, the Booking Engine topic is most naturally discussed in engineering terms, making business-framing prose hard to sustain. adapter / tenantId / DI (dependency injection) surfaced as paragraph subjects, and the tech-oriented prose diverged from the business cluster’s design intent (see the root-cause section of blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md). The eventual fix was “change the cluster—reclassify as a tech version and write a fresh business version”—but a three-layer diagnosis applied earlier would have enabled that fork sooner.
Three Layers: Definitions and Diagnostics
Layer 1: Structure (H2 order, narrative_weight, design intent in the brief schema)
Structure is the skeleton of a pillar. The order of H2s, their titles, the narrative_weight field setting, and the cluster setting in the brief schema—these all express design intent.
A business cluster pillar’s structure follows a sequence like “executive judgment → investment decision → implementation policy → summary.” A tech cluster pillar follows something like “design question → architecture choice → implementation pattern → application criteria.”
Diagnosing a pillar that intends a business audience by structure is straightforward. Check whether the H2s are framed in business terms—“Why build it in-house?”, “Contract work vs. product”, “Phase strategy”. If structure points toward business, Layer 1 passes.
Structure is the most manipulable layer—you can change it by rewriting H2s alone. But structure alone does not determine pillar quality.
Layer 2: Vocabulary (whether H2 titles and lead text use business or tech terms)
Vocabulary is the choice of words appearing on the surface of structure. Check whether the terms used in H2 titles and the lead paragraph belong to business vocabulary or tech vocabulary.
Business vocabulary examples: “contract assets,” “commercialization,” “Phase strategy,” “order funnel,” “medium-term ROI,” “executive judgment” Tech vocabulary examples: “adapter pattern,” “tenantId,” “DI,” “multi-tenant,” “repository,” “API abstraction”
Vocabulary diagnosis is largely determined by scanning H2 titles and the first three paragraphs of the lead. Even in a pillar intended as a business cluster, if tech vocabulary is scattered through the opening paragraphs under each H2, separation at the vocabulary level is incomplete.
Vocabulary is harder to change than structure, but surface manipulation is still possible. Rewriting an H2 title from “Adapter Pattern Design” to “Freedom to Switch External Vendors” changes the vocabulary. But if the paragraph body doesn’t change, Layer 3 will break.
Layer 3: Prose Density (whether paragraph subjects within each H2 use audience-appropriate terms)
Prose density is the hardest layer to change and the most honest indicator of reality.
The diagnostic method is simple but unforgiving. Go through each paragraph within each H2 and check what the subject or topic phrase is.
- “The Adapter pattern abstracts external dependencies” → subject is “Adapter pattern” = tech vocabulary
- “The freedom to switch external vendors creates room to accommodate the customer requirements of commercial deployments” → subject is “freedom to switch external vendors” = business vocabulary
In an article intended as a business cluster pillar, if paragraph subjects land on tech vocabulary in sequence, that passage has broken down at the prose density level.
A prose density diagnostic checklist can be built from five items. Each item asks “what is the subject of this paragraph?”
The Relationship Between Layers: Upper Layers Can Disguise Lower Ones, But Breakdown Appears in Prose Density
Structure (Layer 1) can disguise vocabulary (Layer 2). Ordering H2s for a business audience can make the piece look like a “business cluster” even if the vocabulary remains tech-oriented.
Vocabulary (Layer 2) can disguise prose density (Layer 3). Translating H2 titles into business terms while keeping paragraph subjects in engineering vocabulary leaves the actual prose as tech prose.
But prose density cannot be faked. What a paragraph’s subject is becomes clear when you read the body. Even if Layers 1 and 2 point toward business, a business reader will disengage if Layer 3 continues in tech prose. Prose density is the most honest indicator across all three layers.
Patterns of Prose Density Breakdown — What Disguise Actually Looks Like
When H2 Titles Are Reframed as Business Terms but Paragraph Subjects Remain Engineering Terms
Compare the same concept written two ways: business framing versus tech prose.
Tech prose (engineering term as subject): “The Adapter pattern is an abstraction layer that makes external calendar implementations swappable. By unifying the Google Calendar adapter and the Outlook adapter under the ICalendarAdapter interface, switching implementations requires only swapping the DI container.”
Business prose (business vocabulary as subject): “The freedom to switch external vendors creates room to accommodate the requirements of customers in commercial deployments. One tenant runs on Google Workspace; another is locked to Microsoft 365—an implementation that cannot handle this diversity forecloses commercialization options from the outset.”
Both passages address the same concept—calendar abstraction—but the subjects are entirely different. Tech prose centers on “what the pattern does.” Business prose centers on “what this design guarantees at a business level.”
The Actual Breakdown Pattern in the bateson Pillar
The bateson-engine pillar was initially written as a business cluster. The H2s were set to “Why build the booking tool in-house?”, “Contract work vs. product”, and “Phase strategy”. At the vocabulary level, the intent was business framing.
But as recorded in the retro, the actual paragraphs defaulted to “adapter / tenantId / DI” as subjects. The impulse to explain design details kept surfacing in the prose. Engineering terms are concrete and rich—easier to write than business prose, and detail flows naturally from them—that is the mechanism of breakdown.
After user feedback, the strategy shifted to “keep it as a tech-leaning pillar and write a fresh business version”—a sister pillar approach. The business version, rewritten as bateson-business-strategy.md, achieved 12,996 characters without a single code snippet.
Self-Diagnostic Checklist for Prose Density
Self-diagnosis of prose density is done paragraph by paragraph. If the answers to the following questions remain “yes,” prose density is being maintained.
- Is the subject or topic phrase of this paragraph business vocabulary?
- Does it avoid explaining engineering implementation details? (Is it “what this enables” rather than “how it works”?)
- Does the paragraph contain no code snippets, variable names, type names, or pattern names?
- Is there enough concreteness for a business reader to envision a “next decision”?
- If you wrote the tech prose counterpart, would it be clearly distinct from the current paragraph?
If all five answers are “yes,” that paragraph’s prose density is sustained as a business cluster. If even one answer is “no,” the paragraph is likely failing to function as business prose.
Options for Fixing Breakdown — Reclassification vs. Rewrite
Cost of Changing the Cluster (aligning the schema to what the prose actually is)
Changing the cluster to tech limits the cost to schema edits. Updating the cluster field in the brief YAML, moving the physical path (under src/content/magazine/tech/), and updating pillar-relations.json—these amount to roughly five files. In the actual bateson cluster reclassification, the five files changed were bateson-engine.yaml / bateson-engine.md / bateson-business-strategy.yaml (new) / bateson-business-strategy.md (new) / _state.json (commits: 57e22ed / d854ddf / 0baaf6d; see the “files changed” section of blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md).
The body stays unchanged. If the prose is already written for a tech audience, aligning the cluster to tech restores consistency between design intent and reality.
Cost of Rewriting the Body (aligning prose to the schema’s intent)
Rewriting the body as business prose costs more than reclassification. For a pillar in the 5,000–15,000 character range, mechanically replacing every paragraph’s subject with business vocabulary is difficult to automate.
Beyond that, sustaining prose density after the rewrite requires embedding constraints into the writing process (discussed later). Even if a rewrite achieves business prose temporarily, a structural risk remains: tech prose can slip in during the next writing session.
When the Sister Pillar Strategy (running two clusters in parallel) makes sense
There are conditions under which “writing two articles” is more rational than either “changing the cluster” or “rewriting the body.”
Condition 1: The topic itself has a distinct narrative on both the tech and business sides. With bateson, the engineering implementation (adapter / DI / tenantId) and the executive decisions (Phase strategy / commercialization / order funnel) have separate narrative arcs. Neither can be cut.
Condition 2: The tech spoke and business spoke have distinct keyword sets pointing toward different clusters. Standing up a sister pillar expands cluster SEO (the design that drops pillar primary keywords to spoke secondary) in two directions.
The cost of the sister pillar strategy is writing two articles. But if zero reclassification plus zero rewrite can cover two clusters, the total cost becomes lower than rewriting one article. In the bateson case, the tech version was reclassified and left as-is, while the business version was written from scratch.
Summary — Embedding the Three-Layer Diagnosis in the Design Phase
Checklist for Verifying Three-Layer Alignment at Brief Generation
At the stage of generating a pillar brief, verify the following three questions.
- Structure: Does the H2 order face the intended cluster’s audience? (For business: executive judgment → investment decision)
- Vocabulary: Do the terms planned for H2 titles and the lead belong to business or tech vocabulary?
- Prose density outlook: Is it realistic to sustain business prose paragraphs for this topic? (Can you write 5,000 characters without a code snippet?)
If the answer to question 3 is likely “no,” consider the sister pillar strategy at the brief generation stage. Deciding in the design phase is more cost-efficient than deciding after writing the body.
Proposal to Add a Prose Density Check to the Review Gate
There is a proposal to add a lightweight prose density check to the blog-review skill.
The detection criterion is simple: “In a business cluster pillar, do engineering terms (variable names, type names, code snippets) appear as paragraph subjects?” Mechanical detection is difficult, but adding the criterion “for business cluster pillars, confirm that paragraph subjects use business vocabulary” to the blog-review SKILL.md makes it an explicit review standard.
The three-layer diagnosis was first incorporated into pillar writing with the bateson pillar’s cluster reclassification—currently, the framework derived from it is being recorded as a retro (blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md). There are no other recorded cases of equivalent prose density breakdown in other pillars yet, but that is because the other pillars were designed to lean toward business or tech from the outset and had not broken down badly enough to require diagnosis. For future pillar design, incorporating question 3—“Can body density be maintained without code snippets?”—at the brief generation stage is under consideration.
→ For specific constraint design to maintain prose density, see Two Constraints for Maintaining Pillar Prose Density. For schema extensions to represent sister pillars as first-class entities, see Representing Sister Pillars as First-Class Citizens in the Schema.