The Mapping Phase: Prompts, Topics, Entities, and Competitors

This sub-chapter's central artifact already has a name in this framework: the prompt universe, established in Chapter 11.8 as the defined, bounded set of prompts and intent clusters a measurement practice runs against. The mapping phase produces that same artifact, for a different purpose. Where Chapter 11.8 uses the prompt universe to sample and measure, this phase uses it to decide what to restructure, what to create, and where a domain's real gaps actually are. Same underlying map, two different jobs, and stating that connection clearly is where this sub-chapter has to start.

The Same Prompt Universe, a Different Purpose

Chapter 11.8 defined the prompt universe as the specific, bounded set of prompts and intent clusters a measurement practice checks against consistently over time, drawn from the intent clusters established in Chapter 7.3. This sub-chapter is not introducing a second, competing version of that same artifact. It’s the phase where that artifact actually gets built, maintained, and applied to a different job: deciding what content work happens next, rather than sampling what’s already live.

This distinction matters because building the prompt universe twice, once as a measurement input and once as a mapping input, independently, risks producing two different, quietly inconsistent versions of what should be the same underlying picture of a domain’s real information landscape. One prompt universe, built once during this mapping phase, serves both purposes: it’s what Chapter 11.8 measures against, and it’s what this phase uses to guide restructuring and creation decisions.

Mapping Topics and Entities Against Established Coverage

Mapping topics and entities means checking a domain’s actual coverage against the intent clusters established in Chapter 7.3 and the prompt coverage practice from Chapter 7.4. This sub-chapter doesn’t re-derive either of those concepts; it applies them as the operational input to a specific mapping exercise conducted as part of this chapter’s cycle.

The practical output is a clear picture: which intent clusters does this domain’s existing content genuinely resolve, which does it only partially address, and which has no coverage at all. This picture, built using the mechanisms Chapter 7 already established, is what makes the rest of this mapping phase concrete rather than abstract.

Competitor Mapping as New Operational Ground

Unlike topic and entity mapping, competitor mapping is genuinely new ground this framework hasn’t covered in depth elsewhere. It means checking not just what a domain’s own content covers, but what competing sources are winning inclusion and citation for the same intent clusters, connecting to the citation tracking practice established in Chapter 11.4 and the cross-model comparison work in Chapter 11.5.

This mapping identifies where a domain is competing against genuinely strong, well-established sources versus where the field is comparatively open, information that directly shapes prioritization later in this cycle. A gap where no competitor has strong coverage represents a different opportunity than a gap where several well-established sources already dominate, and competitor mapping is what surfaces that distinction before resources get committed to either kind of gap.

Identifying Missing Answer Assets

The combination of topic and entity mapping with competitor mapping produces this phase’s most consequential output: a clear list of missing answer assets, the specific intent clusters a domain has no content addressing, or addresses only partially, weighed against how contested that ground already is.

This gap analysis is what Chapter 13.3 and Chapter 13.4 both depend on directly. A gap that turns out to be addressable by improving existing content routes toward restructuring; a genuine gap with nothing currently addressing it routes toward the creation phase. Neither of those next phases can make that distinction well without the specific, documented gap analysis this mapping phase is responsible for producing.

Maintaining the Map as a Living Artifact

A map built once at the start of an operating cycle and never revisited becomes stale in exactly the way any other unmaintained signal in this framework does. New intent clusters emerge as a market or a topic space evolves. Competitors publish new content that shifts the competitive mapping. A domain’s own content coverage changes as creation and restructuring work actually happens.

Treating the map as a living artifact means revisiting it on a recurring basis, not necessarily rebuilding it from scratch each time, but checking it against current reality and updating it as conditions change. This connects directly to the recurring audit cadence established in Chapter 13.1: a map built alongside a full audit and then left untouched until the next full audit is a reasonable minimum, though a map that only updates on that same cadence may lag behind faster-moving competitive or topical shifts.

From Mapping to the Restructure-or-Create Decision

This mapping phase’s entire output, the gap analysis, the competitive picture, the current state of topic and entity coverage, exists to feed directly into the decision covered next: whether a given gap gets addressed by restructuring existing content or by creating something new.

That decision is Chapter 13.3’s subject specifically, and it depends entirely on having a clear, current gap analysis to work from. A mapping phase that produces a vague or incomplete picture leaves the restructure-or-create decision without the specific information it needs to be made well, which is why this phase’s job, however unglamorous compared to the actual content work that follows, is foundational to everything the rest of this chapter’s cycle depends on.

Building the Map Once, Using It Twice

Michael Rubinstein has seen teams build a prompt universe for measurement purposes and a separate content gap analysis for planning purposes, independently, without noticing they were describing the same underlying territory twice and producing two pictures that quietly drifted apart from each other over time.

ScribePress builds and maintains one prompt universe per client, used consistently for both measurement sampling and content mapping decisions, specifically to avoid the drift that comes from maintaining what should be a single, shared artifact as two separate, independently updated versions.

Learn more about the work behind this framework at michael-rubinstein.com.

Put the framework to work