EXTRACTIVE SUMMARY
Building a topical map requires three inputs before step one: a defined source context, a demand source budget, and a decision about who holds filtration authority. The nine steps fall into four stages. The first stage builds the query network by harvesting a raw pool and annotating every query. The second stage establishes the center by rolling entities up to find the dominant type, selecting the central entity, and distilling the source context into a predicate pair. The third stage filters and classifies by mining attributes, passing each through prominence, popularity, and relevance, then assigning structural and competitive class. The fourth stage assembles the map by drawing the contextual border, assigning one contextual vector per URL, and building the link graph. The work splits unevenly: the mechanical half is fast and automatable, and the judgment half is slow and is not. Four failure modes account for most bad maps: volume inversion, unfiltered harvest, vector deferral, and border drift.
What a topical map build requires before step one
A topical map build requires three inputs before the first query is harvested, and a build starting without them will need to restart.
A defined source context. One sentence, without hedging, stating how the business earns money from the central entity. Every filtration verdict downstream depends on it, because relevance is judged against the business rather than against the subject in the abstract. A vague source context produces a map that is vague in every row.
A demand source budget. Harvesting across keyword tools, autocomplete, People Also Ask trees, related searches, Search Console, community mining, and competitor exports has a real cost in tool access and hours. Deciding which sources are in scope before starting prevents the build stalling halfway through the pool.
A named filtration authority. One person decides prominence and relevance verdicts. Filtration by committee produces inconsistent verdicts across rows, and inconsistent verdicts produce a map whose priority order cannot be defended when someone asks why a low-volume attribute outranks a high-volume one.
Stage one: build the query network
Step 1. Harvest the raw pool
Harvest every query the subject generates from every demand source in scope. A commercial build starts from a pool in the thousands rather than the hundreds, because the behavioural signals do not emerge at low volume.
Decision rule: do not deduplicate. The frequency of near-duplicate phrasings records which attribute users care about, and deduplication destroys that signal before it is read.
Step 2. Annotate every query
Annotate each query with its entities, its entity types, the attribute being asked about, its predicate, its question type, its query class, its n-grams, and its position in a path. Record the behavioural relationships alongside: which queries co-occur, which follow which, and which routes run from entry to action.
Decision rule: annotate before filtering, never after. Filtering an unannotated pool removes queries on the basis of their wording, and wording is the least reliable property a query has.
→ What is a query network: the three signals a keyword list cannot give you
Stage two: establish the center
Step 3. Roll entities up by type
Count every entity across the annotated pool, then aggregate those counts by entity type. The winning type reveals the shape of the domain.
Decision rule: find the dominant type before the dominant entity. Selecting the most frequent entity directly skips the step that tells you what kind of thing the subject is about, and the type governs how the map is structured.
Step 4. Select the central entity
Within the winning type, select the entity carrying the highest aggregate volume, the widest attribute spread, and the tightest fit to the source context.
Decision rule: volume does not decide it. An entity that leads on volume but cannot be monetized through the source context is rejected, because a map centered on an unmonetizable entity produces traffic that does not convert.
Step 5. Distill the predicate pair
Extract the functional words describing what users want to do with the central entity, attach the prepositions those functional words appear with, then compress the set into two predicates: one informational, one transactional. The transactional predicate expressed in its simplest form is the central search intent.
Decision rule: compress to exactly two. A build that keeps five functional words has not distilled, and the contextual border in stage four has nothing clean to separate.
Stage three: filter and classify
Step 6. Mine and filter attributes
Extract every candidate attribute of the central entity from the query network, then pass each through three tools in a fixed order.
Prominence, the removal test. Remove the attribute and ask whether the central entity loses its meaning. If the definition breaks, the attribute is prominent. This test holds veto power over the other two.
Popularity. Aggregate search demand for the attribute across the query network. Popularity ranks priority and never grants entry on its own.
Relevance. Semantic distance from the central entity, judged in the context of the source context. An attribute can be adjacent to the subject and irrelevant to the business, and relevance is the test that catches it.
Decision rule: an attribute enters on relevance, then orders by prominence first and popularity second. Prominence outranks popularity in every conflict, without exception. Record rejected attributes rather than deleting them, so the filtration is auditable afterward.
Step 7. Classify on both axes
Assign every surviving attribute a structural class and a competitive class.
Structural class runs root, seed, node. If removal breaks the central entity’s definition, it is root. If it spawns its own cluster, it is seed. If it is terminal, it is node.
Competitive class runs standard, rare, unique. Standard is well covered by competitors. Rare exists in the knowledge domain and is almost absent from competitor coverage. Unique originates from your own source and cannot exist elsewhere.
Decision rule: the axes are independent and a row carries one value from each. Rare and unique rows are the quality node candidates, and they are published early rather than late, because they are what distinguishes an authority from a volume chaser.
Stage four: assemble the map
Step 8. Draw the contextual border
Draw one line through the classified attributes. Rows serving the transactional predicate fall into the core section. Rows serving the informational predicate fall into the outer section.
Decision rule: core goes deeper and outer goes wider. The core section carries the central search intent, the highest fact density, and the money. The outer section captures the entry queries of every path and accumulates historical data. A row that does not carry the central search intent and is not an entry query belongs in neither and is a rejection.
Step 9. Assign vectors, URLs, and the link graph
Assign exactly one contextual vector per URL. Assign the slug, with URL depth mirroring attribute depth. Assign internal link targets, with every seed hub linking to all of its nodes and every node linking back to its seed. Assign a bridge target to every outer row, running outer toward core.
Decision rule: assign the vector in the map, never in the article. A vector left empty in the map is a decision deferred to the writer at the moment of writing, and that is where drift and cannibalization originate.
Where the time goes
A topical map build splits unevenly across its nine steps, and the split is the reason build timelines are routinely underestimated.
| Stage | Nature of the work | Automatable |
| 1. Query network | Mechanical: harvesting, expansion, annotation, n-gram analysis | Largely yes |
| 2. Establish the center | Mixed: counting is mechanical, selection is judgment | Partly |
| 3. Filter and classify | Judgment: prominence, relevance, and both classifications | No |
| 4. Assemble the map | Mixed: structure is rule-following, border and vector are judgment | Partly |
Stage one scales with tooling and gets faster every year. Stage three does not, because the prominence test asks whether removing an attribute destroys the central entity’s meaning within a specific business context, and that question cannot be answered from the query data alone.
The practical consequence is that a build delivered faster than its filtration can be reasoned about has skipped filtration. The visible symptom is a map with no rejected rows, and rejected rows are the cheapest thing to check.
The four ways a topical map build fails
Four failure modes account for most unusable maps, and each traces to a specific skipped decision rule.
Volume inversion. The map is ordered by search demand rather than by prominence, which buries the attributes that define the subject beneath the attributes that happen to be searched most. Volume inversion is the default output of any automated build, because volume is the only field a tool can rank on confidently. The symptom is a publication order whose first ten articles are all commercially generic.
Unfiltered harvest. The map contains everything relevant and rejects nothing. An unfiltered harvest looks impressive, produces a publication backlog measured in years, and defers every hard decision to whoever writes the articles. The symptom is the absence of rejected rows.
Vector deferral. The contextual vector field is empty or carries two values. Every URL then gets its angle decided during writing, which produces pages that drift across vectors and compete with each other. The symptom appears months later as two of your own pages trading positions for the same query.
Border drift. The contextual border was never drawn, so rows sit in the core or outer section by resemblance rather than by predicate. Authority then leaks outward instead of pooling where the money is, and internal links run in both directions with no forwarding logic. The symptom is an internal link graph where core pages link outward as often as outer pages link inward.
All four are detectable in the delivered map before a single article is commissioned, which is the argument for checking a map rather than trusting it.
BRIDGE
Every step above is publishable, and publishing them changes less than it appears to. Stage one is a procedure and transfers cleanly to anyone who reads it. Stage three is judgment, and a decision rule written down is not the same as a decision rule applied consistently across four hundred rows by someone who knows the subject and the business well enough to defend every verdict.
That is the half Holistic Radar is actually selling. A topical map production engagement delivers the full fifteen-field schema with the rejected rows included, the filtration verdicts stated per row, one contextual vector assigned per URL, and the tuple total declared, so that building topical authority to rank begins with an auditable document rather than with a backlog.
→ Topical map production: the full schema, with filtration you can audit
SUPPLEMENTARY CONTENT
How to check a topical map you were delivered
Check four fields in this order. Are rejected rows present, which proves filtration occurred. Does every row carry exactly one contextual vector, which proves the angle decision was made upstream. Is a tuple total stated, which proves coverage is measurable. Is the publication order sorted by prominence rather than volume, which proves the priority rule was applied.
A map failing any of the four can be repaired. A map failing all four is a keyword export with the schema’s column headings applied to it.
Whether a topical map can be built with AI
The mechanical half is well suited to automation and the judgment half is not. Query expansion, entity extraction, question-type tagging, and n-gram analysis are faster and more consistent when automated.
The prominence test resists automation because it requires knowing how the business earns money from the entity, and a generated map defaults to ranking by volume, which inverts the central priority rule. The result satisfies the early steps and fails step six, which is the step that makes the document a map.
How the map changes after it is built
The query pool changes continuously as new phrasings appear. The classifications rarely change, because prominence is a property of the subject rather than of the season.
Re-harvest annually or when the subject acquires new entities. Re-filter only when a re-harvest surfaces attributes the original build did not consider.
What to publish first from a finished map
Publish core section root attributes first, quality nodes included, because early coverage of prominent attributes is what triggers initial evaluation. Then complete each seed cluster fully before opening the next, since half-covered clusters read as incomplete coverage.
→ The Holistic Authority Score: a computable measure of topical coverage