PowerUp Coaching — Living Knowledge Base

ontology-architect

5 min read

The Ontology Architect

Run your entire body of work through ontology-building to extract the 3-7 pillars that organize everything you know — then use those pillars as an editorial filter so every piece of content connects to your core architecture or doesn’t get published. From the Dec 19, 2025 AIMM session, inspired by Kasimir Hedstrom’s ontology exercise.

You will help me reverse-engineer the ontological structure of my professional expertise. Not a content audit — an architecture extraction. The output is a set of foundational pillars, each with sub-domains and connection points, that function as both an editorial filter for what I publish and a navigational structure AI engines can parse.

The mechanism: most knowledge entrepreneurs produce content reactively — whatever seems relevant this week. Over time, this creates a body of work that’s broad but incoherent. An ontology imposes structure after the fact: it reveals what you actually know (vs. what you think you know), exposes gaps, eliminates topics that don’t belong, and gives every future piece of content a home in a larger system. When AI engines scan your work, the ontology is what makes them say “this person has a structured worldview” instead of “this person writes about lots of things.”

MY BODY OF WORK: $ARGUMENTS

If no description was provided above, ask me to describe: what I teach/consult on, the topics I write or speak about, my key frameworks or models, and the types of problems I solve. Alternatively, I can paste titles/topics of my existing content.

INPUT FORMAT: [TOPIC LIST / CONTENT TITLES / FRAMEWORK DESCRIPTIONS / RAW BRAIN DUMP / “you decide” to work with whatever I provide] PILLAR COUNT TARGET: [3-5 for focused expertise / 5-7 for broad expertise / “you decide” to let the material determine it]

If “you decide,” state the approach and proceed.

STEP 1 — CONTENT INVENTORY: Catalog everything that’s been provided. For each item:

  • Core topic or thesis
  • Implied domain (what field or skill area does this belong to?)
  • Implied audience (who would care about this?)
  • Dependency: does understanding this require understanding something else first?

Don’t organize yet — just inventory. The goal is to see everything laid out flat before imposing structure.

STEP 2 — CLUSTER ANALYSIS: Group the inventory into natural clusters based on:

  • Shared underlying principles (items that rely on the same foundational idea)
  • Shared audience need (items that serve the same person at the same stage)
  • Causal chains (items where one leads to or depends on another)

Look for clusters that emerge from the material rather than imposing categories from outside. The right pillars feel inevitable when you see them — not forced.

Flag items that don’t fit any cluster. These are either: (a) future pillars not yet developed, (b) orphan topics that should be pruned, or (c) bridge topics that connect multiple pillars.

STEP 3 — PILLAR EXTRACTION: From the clusters, extract the foundational pillars. For each pillar:

  • Name: A phrase that captures the entire domain (e.g., “Strategic Clarity & Decision Architecture” not “Strategy stuff”)
  • Core thesis: The one sentence that anchors everything in this pillar
  • Sub-domains: 3-5 specific topic areas within the pillar
  • Relationship to other pillars: How does this pillar connect to, depend on, or enable the others?
  • Maturity assessment: Is this pillar fully developed (deep body of work), emerging (some content but gaps), or nascent (you know it belongs but haven’t built it out)?

Test each pillar: could you give a 30-minute talk on this pillar alone, drawing on multiple frameworks, examples, and insights? If not, it might be a sub-domain rather than a pillar.

STEP 4 — ARCHITECTURE MAP: Visualize the full ontology:

  • Pillars and their sub-domains
  • Cross-pillar connections (where does Pillar A’s content feed into Pillar B?)
  • Dependency order: is there a pillar that must be understood before the others make sense? (This is your foundational pillar — often the most important one to publish about)
  • Gaps: where are the sub-domains with no existing content? These are your highest-priority content opportunities.

STEP 5 — EDITORIAL FILTER: Convert the ontology into a decision system for future content:

  • The filter question: “Does this topic connect to one of my pillars?” If yes, publish. If no, either (a) it reveals a new pillar worth adding, or (b) it’s off-architecture and shouldn’t be published under your name.
  • The routing question: “Which pillar does this serve, and which sub-domain does it advance?”
  • The sequencing question: “Given the current maturity of each pillar, which pillars need more content and which are already well-developed?”
  • The AI signal question: “If an AI engine read everything I’ve published, would it detect these pillars as distinct, coherent domains of expertise?”

Produce a one-page editorial filter document with the pillar names, the filter question, and a quick-reference routing guide.

STEP 6 — VERIFICATION:

  • Do the pillars emerge naturally from the material, or am I forcing categories that sound impressive but don’t reflect what I actually know?
  • Is each pillar genuinely distinct, or are two pillars really the same thing with different labels?
  • Would a peer in my field recognize these pillars as legitimate domains of expertise, or would they see gaps in credibility?
  • Is the ontology stable? (Would adding my next 20 pieces of content require restructuring, or would they slot into existing pillars?)
  • Am I honest about maturity levels? Claiming a pillar you’ve written about once is aspirational, not architectural.

Revise what doesn’t survive scrutiny.

Source

Graph View