Source Context for Topical Maps | Test Page Fit Before Publishing
Topical mapping · Map entry control

Use source context to decide which topics belong in the topical map.

Source context is the site’s approved topical identity and operating boundary. It defines the primary entities, audience, offers, allowed and excluded topics, existing page owners, proof limits, and routes that every new page should reinforce.

Build the reusable site profile with the Source Context Template. Then use this page to test one proposed topic before it becomes a URL, content block, merge, hold item, or blocked idea.

  • Five fit checks, zero to five each
  • 18 out of 25 creates an own-page candidate
  • Hard boundaries can override the score
  • Granularity and map approval still follow

MIRENA Topical Source Context Guard

Load or enter the approved site profile, describe one proposed page, score the five checks, confirm any stop condition, and create a decision memo.

0 of 6 source-context requirements usable Human approval remains required
01 Approved site contextUse the reusable project boundary, not a keyword-only brief. Upstream input
02 Proposed page or topicName the user job, owner, distinction, proof, and route. Candidate
03 Five fit checks and stop conditionsScore zero to five and record the evidence. 25 points

Does the proposed page reinforce the site's primary entities and approved relationships?

0

Contradicts or sits outside the approved entity world.

Would the stated audience realistically need this page before, during, or after the approved offer?

0

Serves a different audience or creates low-quality demand.

Does the page map to a real MIRENA output, offer, workflow step, or support route?

0

No connection to an approved offer or workflow.

Can the page add useful information, proof, or a decision model rather than repeat generic coverage?

0

No useful distinction or proof.

Will the page strengthen the site as a hub, spoke, bridge, support page, or useful route?

0

Stop conditions

The guard has no form endpoint, network submission, or browser storage. Exact phrase matches are review signals, not automatic proof of topical fit.

Page ownership

Source context has four different jobs across the workflow.

Keeping those jobs separate prevents this page from duplicating the template, topical map process, or content brief.

01 · Build

Create the approved site profile

Record the brand, audience, offers, entities, allowed and excluded lanes, current URLs, proof, voice, constraints, and requested output.

Open the Source Context Template →
02 · Filter

Test one proposed page

This page applies the approved profile to one topic and returns an own-page candidate, existing-owner route, hold, or block decision.

Use the Page Fit Guard →
03 · Process

Turn candidates into a site plan

The processed map assigns page ownership, query buckets, roles, links, overlap controls, dependencies, and publishing order.

Open the Topical Map Process →
04 · Brief

Tell the writer what to produce

Only approved pages move into briefing, where the page purpose, user job, entities, block order, proof, links, formats, and exclusions are recorded.

Open Content Brief Workflow Prompts →
Five fit checks

The score asks if the idea deepens the site, not if the keyword merely looks related.

Each criterion is scored from zero to five. Record the evidence beside the number so another reviewer can repeat the decision.

01

Entity fit

Does the proposed page reinforce the site's primary entities and approved relationships?

0Contradicts or sits outside the approved entity world. 3Supports a secondary entity or useful attribute. 5Deepens a primary entity with a clear new relationship, attribute, or owned method.
02

Buyer fit

Would the stated audience realistically need this page before, during, or after the approved offer?

0Serves a different audience or creates low-quality demand. 3Supports a real research, comparison, or support need. 5Solves a core buyer job and leads into a clear next route.
03

Workflow fit

Does the page map to a real MIRENA output, offer, workflow step, or support route?

0No connection to an approved offer or workflow. 3Supports a named workflow stage or output. 5Strengthens a core workflow, output, and conversion or support route.
04

Differentiation fit

Can the page add useful information, proof, or a decision model rather than repeat generic coverage?

0No useful distinction or proof. 3Adds a useful synthesis, example, or decision rule. 5Adds first-hand proof, proprietary data, a named method, or a clearly defensible new answer.
05

Link fit

Will the page strengthen the site as a hub, spoke, bridge, support page, or useful route?

0Would be orphaned or has no clear owner. 3Has a clear parent, child, or destination route. 5Has a defined cluster role, inbound sources, outbound destinations, and a clear journey function.
Decision routes

A score is useful only when it changes what happens next.

The 18-point threshold comes from the MIRENA Source Context Guard. The lower bands provide a practical route for related ideas that do not justify another URL.

Candidate for its own URL

18 to 25 points

The topic clears the 18 out of 25 Source Context Guard threshold and has no active stop condition. It still needs granularity, overlap, role, route, proof, and map-approval checks.

  • Confirm the distinct user task and page intent.
  • Assign one page role and one canonical owner.
  • Record the parent, inbound sources, outbound destinations, proof, and publishing dependency.
Use an existing owner, section, FAQ, or merge

13 to 17 points

The idea is related, but the score or overlap signal does not justify another URL yet. Give the need one clear content home.

  • Name the strongest existing page owner.
  • Choose a section, direct-answer block, FAQ, merge, or canonical-page update.
  • Move the best information and proof into that owner.
Hold and revise before map entry

Any unresolved input, proof, or route condition

The idea may belong, but the source context, evidence, page route, or review condition is incomplete. Do not send it into briefing yet.

  • Complete the missing source-context fields.
  • Add the required proof or soften the claim.
  • Define the parent page, internal route, and next user step.
Block, defer, or move outside this site

0 to 12 points or a hard boundary

The proposal does not reinforce the approved source context strongly enough or conflicts with a hard boundary. Search demand alone does not justify map entry.

  • Record the reason the idea is outside the approved site.
  • Remove it from the current publishing queue.
  • Consider a separate site, subfolder, brand, or research record only when the wider strategy supports that move.
Source context versus keyword relevance

Broad relevance can still pull the site sideways.

Search demand is evidence. It is not permission to publish every adjacent topic.

Decision signal Keyword-only view Source-context view Map consequence
Topic relationShares industry termsReinforces approved entities and attributesKeep only when the relationship deepens the owned topic
AudienceCould attract trafficServes the approved buyer or user stateBlock broad demand that creates the wrong audience
Business and workflowHas search volumeMaps to a real offer, output, task, or support routeRequire a useful handoff
DifferenceCan target another phraseAdds proof, a decision model, first-hand detail, or a missing relationshipMerge generic repetition into an owner page
ArchitectureCan become a URLHas a role, parent, inbound sources, outbound targets, and one canonical ownerReject or hold orphan ideas
Workflow position

The guard sits before page ownership and after the source profile.

Do not send a proposed page directly from keyword discovery into a brief.

01

Build source context

Define the site, audience, entities, boundaries, inventory, proof, and routes. Build it.

02

Score page fit

Apply entity, buyer, workflow, difference, and link checks to each proposed idea.

03

Test granularity

Decide if the need requires its own URL or belongs inside an existing owner. Run the rule.

04

Check risk and overlap

Review duplicate intent, cannibalization, proof, scope, and route conflicts. Check risk.

05

Process the map

Assign the canonical owner, page role, cluster, links, dependencies, and publishing order.

06

Approve and brief

Record human approval, then move the accepted page into a writer-ready brief. Review approval.

Practical application

Source context should improve architecture, differentiation, and user movement together.

Information gain without site drift

A novel angle is not automatically a useful page. The idea needs both information gain and source-context fit.

  • Compare the proposal with existing pages and current result coverage.
  • Name the new relationship, evidence, example, or decision model.
  • Place the gain on the strongest owner page when a separate URL is not defensible.
  • Use the Information Gain workflow after ownership is clear.

Internal links as a fit test

A page with no clear parent, sibling, proof route, or next user step is often a weak map candidate.

  • Name the hub or parent before approval.
  • Identify pages that should link into the proposal.
  • Identify the next page that helps the user continue.
  • Use Semantic Internal Linking after the map accepts the page.
Operating boundaries

The guard records a planning judgment. It does not prove performance.

Input and privacy boundary

  • The tool does not submit or store the entered project values.
  • Do not enter passwords, full payment-card details, or restricted client material.
  • Review the Privacy Policy and Acceptable Use Policy before sensitive work.
  • Imported JSON should come from an approved source-context record.

Approval and outcome boundary

  • A high score does not promise rankings, traffic, leads, sales, or rich results.
  • Human review remains required for facts, sources, claims, links, accessibility, code, and legal duties.
  • Final structured data follows approved visible copy and the deployed page.
  • Read the Legal Disclaimer for the full outcome boundary.
Common questions

Source context in topical mapping FAQ

What does source context mean in topical mapping?

Source context is the site's approved topical identity and operating boundary. It records the primary entities, audience, offers, allowed and excluded topics, existing pages, proof limits, and routes that future map decisions should reinforce.

How is this page different from the source context template?

The template page builds the reusable site profile. This page applies that approved profile to one proposed page or topic and decides if the idea should become a URL, join an existing owner, wait for revision, or stay outside the site.

Why is keyword relevance not enough?

A keyword can sit inside the same broad industry and still serve the wrong buyer, the wrong offer, or no useful site route. Source context asks if the page deepens the site's approved entity and workflow model.

What is the 18 out of 25 rule?

MIRENA scores entity fit, buyer fit, workflow fit, differentiation fit, and link fit from zero to five. A score of 18 or more creates a candidate for its own URL. It does not bypass granularity, overlap, proof, role, or approval checks.

Can a high-scoring page still be blocked?

Yes. A real excluded-topic conflict or wrong-audience conflict can block a high score. Duplicate intent can send the idea to an existing owner, while missing proof or a missing route can hold the idea for revision.

What happens when a topic scores below 18?

A related idea may become a content block, FAQ, subsection, merge, or update to an existing owner. A low-fit or off-context idea should be held, blocked, or moved to a different site or brand.

Should I score page ideas before keyword clustering?

Set the source context first, then use it while processing candidate topics. Query clustering can reveal demand and overlap, but the source-context decision still controls whether that demand belongs on the site.

How do existing pages affect the decision?

Existing pages reveal ownership. A proposed title may look new while serving the same intent, page role, headings, and next step as an existing URL. That usually points to a section, merge, or owner-page update.

Does the Page Fit Guard store or submit my data?

No. The standalone tool performs scoring, import, copy, and downloads inside the browser tab. It has no form endpoint, network submission, or browser-storage call.

What comes after an own-page candidate passes?

Run the granularity and topic-risk checks, assign the canonical owner and cluster role, record links and proof, place the page in the processed map, obtain map approval, then move the approved page into a content brief.

Put every page idea through the same source-context gate.

Build the site profile once, test each proposed page, record the reason, and move only approved candidates into the processed map.