Representing Sister Pillar Relationships as First-Class Schema — A Brief Extension Proposal

The HUMAN_INPUT markers that appear in this article are placeholders left by AI writing skills to indicate “a human should fill in the confirmed value here later” (example format: <!-- HUMAN_INPUT: enter the number -->).

The brief for the bateson-engine pillar has a tech_spoke_slugs field. Mixed into that field is the slug 2026-05-bateson-business-strategy. That is a reference to the business-cluster sister pillar — not a spoke. Yet the schema represents both using the same field.

This conflation began as a temporary workaround. Right after the pivot to a sister pillar strategy, the decision was made to “just put it in the spoke field for now.” In bateson-engine.yaml, 2026-05-bateson-business-strategy is recorded under business_spoke_slugs. But temporary workarounds embed conceptual confusion into the schema. Adding a dedicated sister_pillar_slug field separates the concepts of sister pillar and spoke at the schema level. When the schema expresses concepts accurately as first-class citizens, graph generation, link analysis, and cross-link design in skills all become coherent.

The Current Problem — Conflating Spokes and Sister Pillars

Mixing Sister Pillar Slugs into tech_spoke_slugs

Spokes and sister pillars are distinct concepts.

A spoke is an article that dives deeper into a specific theme of a pillar. Spokes for the 2026-05-bateson-engine pillar would cover subordinate concepts such as “how to implement multi-tenancy” or “deciding when to transition to Phase B.” Spokes belong to a pillar.

A sister pillar is the counterpart pillar covering the same topic from the opposite cluster. The sister of 2026-05-bateson-engine (tech cluster) is 2026-05-bateson-business-strategy (business cluster). The two are peers — neither is subordinate to the other. A sister pillar does not belong to a pillar.

When a sister pillar slug is mixed into tech_spoke_slugs, neither humans, machines, nor skills can determine from the schema alone whether a given entry is a spoke or a sister. Data whose meaning cannot be read from the field name requires context inference every time it is accessed.

Impact on Graph Analysis and Skill Behavior

blog-ops/config/pillar-relations.json holds the graph structure of pillar ↔ sister-pillar / spoke relationships as the SSOT. In the current implementation, sisterPillars and spokes are already expressed as separate fields, so the graph itself is properly separated.

However, when sister slugs are mixed into the brief YAML’s tech_spoke_slugs, any process that generates a graph from the brief (or any skill that reads the brief) must include additional logic to determine “is this slug a spoke or a sister pillar?”

When the blog-graph skill statically analyzes brief YAML files, it needs logic to extract only spokes from tech_spoke_slugs and exclude sister pillars. This offloads schema responsibility onto code. If the schema cleanly separates the concepts, the code can simply reference the fields without any disambiguation logic.

The Cost of Not Distinguishing Concepts in the Schema

The cost falls into three categories.

Comprehension cost: When a new team member reads a brief YAML and finds a pillar slug inside tech_spoke_slugs, the schema provides no explanation for why it is there. They must consult documentation or context to understand the intent.

Implementation cost: Every skill or script that reads tech_spoke_slugs needs logic to detect whether any sister pillar slugs are mixed in. The detection itself requires indirect approaches such as “read the is_pillar field to decide.”

Future cost: As sister pillar pairs grow, the conflation expands. Today it is the bateson pair, but mcluhan will also have a sister relationship between mcluhan-engine and mcluhan-business-strategy. Repeating the same workaround would entrench tech_spoke_slugs as a “mixed field for spokes and sisters.”

The Extension Proposal — Adding the sister_pillar_slug Field

Definition: A Reference to the Counterpart Cluster Pillar on the Same Topic

The proposed extension adds a sister_pillar_slug field to the brief YAML. The definition is as follows.

sister_pillar_slug: "2026-05-bateson-business-strategy"
# The slug of the sister pillar written about the same topic from the opposite cluster.
# For a business+tech two-pillar parallel structure like mcluhan / bateson,
# both pillars reference each other.
# Not used in spoke articles (the spoke-pillar relationship is expressed via the pillarSlug field).
# Values must be symmetric: if A references B, B must reference A.

The field holds a single string value and represents a symmetric relationship. 2026-05-bateson-engine carries sister_pillar_slug: 2026-05-bateson-business-strategy, and 2026-05-bateson-business-strategy carries sister_pillar_slug: 2026-05-bateson-engine.

Separation of Roles from tech_spoke_slugs / business_spoke_slugs

After the extension, the role separation looks like this:

With this separation, tech_spoke_slugs holds only the tech spokes that operate under the pillar. Graph generation scripts can process sister_pillar_slug and tech_spoke_slugs as distinct edge types.

YAML Schema Design for the New Field

Proposed addition to .schema.md:

# sister_pillar_slug (optional; pillar articles only)
sister_pillar_slug: string  
# The slug of the counterpart cluster pillar on the same topic. Used in
# business+tech two-pillar parallel structures like mcluhan / bateson,
# where both pillars reference each other.
# Not used in spoke articles (the spoke-pillar relationship is expressed via pillarSlug).
# Values must be symmetric: if A holds B, B must hold A.

Migration Scope and Cost

Migrating Existing Brief YAML Files

The number of brief YAML files currently mixing sister pillar slugs into tech_spoke_slugs or business_spoke_slugs is 14.

Migration requires two steps per brief YAML:

1. Remove the sister pillar slug from tech_spoke_slugs (or business_spoke_slugs).
2. Add sister_pillar_slug: {slug}.

Apply the same changes to the sister pillar’s brief to preserve symmetry. pillar-relations.json already expresses this relationship correctly under sisterPillars, so no changes are needed there.

Impact on Graph Generation Scripts and the Link Graph

When the blog-graph skill parses brief YAML files to generate the link graph, it will need to add sister_pillar_slug as a new edge type.

Changes required:

• tech_spoke_slugs → spoke edges (direction: pillar → spoke)
• sister_pillar_slug → sister edges (direction: bidirectional)

Spoke edges are unidirectional (pillar to spoke). Sister edges are bidirectional and symmetric. This distinction matters for both graph visualization and link analysis — spoke link counts and sister reference counts should be tracked as separate metrics.

Checks to Add to blog-gate G Rules

After adding sister_pillar_slug to the schema, the following checks are candidates for blog-gate.

Candidate G14: Verify that the slug referenced by sister_pillar_slug actually exists. (A reference to a nonexistent slug is surfaced as a WARN.)

Candidate G15: Symmetry check for sister_pillar_slug. (If A references B but B does not reference A, surface as a WARN.)

WARN rather than fail is appropriate for both G14 and G15. When planning a new sister pillar, the author’s brief may exist before the counterpart’s brief has been created.

Conclusion — The Value of First-Class Schema Representation

Encoding Pillar Design Philosophy into the Schema

The sister pillar strategy breaks the assumption of “1 topic = 1 pillar.” Operationalizing this requires the schema to represent the concept accurately.

First-class schema representation means that reading the schema alone is sufficient to understand “what this value is a reference to.” Seeing the field name sister_pillar_slug makes it self-evident that the value is a reference to a sister pillar. There is no need to search through tech_spoke_slugs for sisters.

The value of encoding design philosophy into the schema is “holding a conceptual map outside the code and documentation.” The goal is a state where a new team member can read a brief YAML and infer the structure of the pillar design.

Schema Extensibility for Future Sister Pillar Growth

The number of sister pillar pairs currently in operation is 7.

As more topics meet the conditions for the sister pillar strategy (having distinct narratives on both the tech and business sides), the pair count will grow. With sister_pillar_slug present in the schema, adding a new pair requires only “adding one line to both briefs.”

Without the field, every new pair introduces the decision cost of “where do we put this?” Defining the field in the schema in advance eliminates that operational overhead.

The sister pillar strategy is already applied beyond bateson and mcluhan — pairs exist for synapse (business org / agent harness), laplace (medallion finance ROI / data pipeline), montage (video ops ROI / video pipeline), ai-agent-design (business integration / harness design), and claude-code-practice (product / design). As of 2026-05, pillar-relations.json registers 7 sister pillar pairs.

The plan is to formally add the sister_pillar_slug field to the brief schema at the time the next new pillar pair is created from a brief. The existing 7 pairs are already expressed as sisterPillars in pillar-relations.json, so retroactive backfill is low priority — doing the schema extension and the backfill together when integrating into the brief generation DAG will minimize rework.

Priority is high. As the pillar count grows under the sister pillar strategy, the absence of WARN detection means “one side written without the other” will go undetected. The natural sequencing is to introduce G14 / G15 in the same PR as the schema extension (sister_pillar_slug field addition).

Note that what G15 enforces is symmetry in tech ↔ business sister pillar pairs. JA/EN article symmetry is handled by a separate gate (the existing sitemap-audit / blog-translate pipeline). That said, if international expansion becomes a priority, adding JA/EN symmetry as a WARN gate has merit — that should be tracked as a separate issue.

→ For prose density design in sister pillars, see Three Layers of Pillar Design (Structure / Vocabulary / Prose Density). For an overview of cross-link design between spokes and pillars, see Bateson’s Management Decisions and Phase Strategy.