MIRENA Source Context Template | Build, Score and Export
MIRENA input control · First workflow gate

Build a MIRENA source context that controls the work before the work starts.

A source context is a structured project input that tells MIRENA what the site is, who it serves, what it sells, which entities and topics matter, which pages already exist, and which output should be produced.

Use it before processed topical maps, entity maps, content briefs, rewrites, information gain audits, internal link maps, SERP feature briefs, or semantic optimization. Pair it with the MIRENA input record and keep the approved context attached to every later workflow stage.

  • 14 scored context fields
  • 8 output-specific contracts
  • Topic and entity conflict checks
  • Browser-only JSON and text export

MIRENA Source Context Builder

Complete the four input groups. The selected output changes the score, required fields, blockers, expected deliverables, and next route.

0 of 14 context fields usable Human approval remains required
01 Site and offerDefine the project and the commercial object. 0/2
02 Audience, market, and goalSet the user, localization, outcome, and next path. 0/3

Name specific roles, needs, buying context, or operating level.

03 Entities and topic boundariesDefine what leads, what supports, and where the work must stop. 0/3
04 Inventory, proof, voice, and outputAttach the current site and define the exact job. 0/6

This tool has no form endpoint, network submission, or browser storage. Do not enter passwords, full payment-card data, or restricted client material.

Input control

A keyword names a topic. Source context defines the operating boundary.

Good source context replaces guessing with explicit project decisions. It gives each later MIRENA output a site, user, offer, entity set, page inventory, proof base, and destination route.

Input state What MIRENA receives Likely result Better control
Keyword onlyA phrase with no site or buyer contextGeneric topic coverage and weak page ownershipAdd the site, offer, audience, entities, exclusions, and output job
Sitemap onlyURLs without the business goal or page-status decisionsShallow map and link choicesAdd page roles, protect and repair notes, conversion routes, and priorities
Draft onlyExisting words without approved page purposeCleaner copy that can keep the wrong structureAdd page role, user job, proof, links, exclusions, and rewrite goal
Controlled source contextScope, entities, inventory, proof, constraints, review, and requested outputWork that can be checked against the same project contractKeep the approved context attached through production and review
The 14 context fields

Every field answers a decision that MIRENA should not have to guess.

The dots turn orange when a field becomes usable and teal when the input has stronger depth.

01

Site summary

Identify the brand, domain, business type, and site purpose.

Name, domain, business type, and a specific 40+ character summary.
02

Offer or product summary

Explain what is sold, what it does, why it differs, and how access is priced.

Name the offer and describe the job, user benefit, difference, and model.
03

Audience

Name the people, their skill level, and any secondary audience.

Use specific roles, needs, and skill level rather than a broad label.
04

Region and language

Control market, spelling, localization, and regulatory context.

Name at least one region and one language.
05

Business goal

State the main outcome and the route a qualified user should follow.

Give one main outcome and one destination or action.
06

Primary entities

Name the concepts, products, brands, and people that should lead the project.

List at least three ranked or clearly prioritized entities.
07

Supporting entities

Add the related entities and concepts that provide useful depth.

List useful support and competitor entities without diluting the main topic.
08

Topical boundaries

Define allowed, excluded, and caution topic lanes.

Include both allowed and excluded topic lanes; add caution topics where needed.
09

Existing pages and inventory

Give MIRENA the current URLs, roles, and keep, repair, merge, or block notes.

List the important URLs and a status or role for each where possible.
10

Internal link targets

Name destination URLs, pages needing support, and anchor direction.

List target URLs and explain the route or anchor direction.
11

Proof and resources

List evidence, screenshots, first-hand notes, research, and source material.

Name the evidence source and what it can support.
12

Brand voice and style

Set voice, reading level, preferred terms, blocked terms, and claim limits.

State the voice and at least one wording or claim boundary.
13

Workflow goal

State the primary job, review rule, constraints, priority, and format context.

Name one primary workflow job and the review or constraint that controls it.
14

Requested output

Choose the first MIRENA output and its next workflow route.

Choose one primary output before adding a secondary goal.
Output-specific contracts

The same source context should change shape for the job it controls.

A map needs inventory and boundaries. A brief needs audience, proof, links, and page purpose. An information gain audit needs a defined comparison space and evidence. The builder changes its priorities accordingly.

01

Processed topical map

Page ownership, cluster roles, overlap decisions, publishing order, and cluster routes.

  • approved page inventory
  • keep, merge, split, hold, or block decisions
  • page and cluster roles
  • publishing waves
  • cluster route plan
Continue to processed topical mapping →
02

Entity map

Entity hierarchy, attributes, relationships, salience priorities, exclusions, and page ownership.

  • primary and support entity stack
  • entity attributes
  • relationship notes
  • salience priorities
  • page ownership cues
Continue to entity mapping →
03

Content brief

Page purpose, audience, intent, entities, block order, proof, internal links, and writer instructions.

  • page purpose
  • intent and audience notes
  • entity targets
  • block instructions
  • proof and link requirements
Continue to content briefing →
04

Rewrite brief

Current-page diagnosis, keep and repair decisions, missing entities, link fixes, proof gaps, and conversion route.

  • page diagnosis
  • keep, revise, remove, or merge notes
  • structure repairs
  • entity and proof gaps
  • link and CTA fixes
Continue to rewrite planning →
05

Information gain audit

Repeated coverage, missing relationships, useful differentiation, proof gaps, and page placement.

  • repeated coverage
  • missing entity and attribute relationships
  • useful differentiation
  • proof opportunities
  • placement and next-route notes
Continue to information gain analysis →
06

Internal link map

Source and target pages, route purpose, entity relationship, user path, anchor direction, and priority.

  • source and target URL pairs
  • route purpose
  • entity relationship
  • anchor direction
  • placement and priority
Continue to internal link mapping →
07

SERP feature brief

Query intent, direct-answer form, lists, tables, FAQs, proof, and page-fit controls.

  • answer targets
  • paragraph, list, table, or FAQ formats
  • proof needs
  • placement notes
  • page-fit and review risks
Continue to SERP format planning →
08

Semantic optimization report

Entity clarity, contextual relationships, topic fit, internal routes, information gain, and visible-copy repairs.

  • entity and relationship findings
  • topic-fit repairs
  • content-block changes
  • link updates
  • information gain and review notes
Continue to semantic optimization →
Source Context Guard

Score a proposed page or task before it enters production.

Use five checks from 0 to 5. A high score means the work fits the entity model, the buyer, the MIRENA job, the differentiation need, and the site route. The score never replaces human review.

18-25Move to briefing, subject to review.
13-17Revise the scope or merge it with a stronger owner.
0-12Hold or block the work.
0
0
0
0
0
0/25 Hold or block
Workflow position

Source context starts the route. It does not finish the work.

Keep the approved context as the control record while the project moves through evidence, planning, production, links, review, and final page checks.

01

Source context

Site, offer, audience, entities, boundaries, inventory, proof, goal, and output.

02

Evidence intake

Files, URLs, search data, screenshots, current pages, competitor material, and first-hand records.

03

Planning

Page ownership, entity hierarchy, intent, information gaps, routes, and priorities.

04

Brief or repair plan

Block jobs, proof, links, formats, writing controls, exclusions, and approval notes.

05

Production

Draft or rewrite the approved page, then complete internal links and implementation work.

06

Human review

Check facts, claims, sources, code, accessibility, legal duties, visible copy, and final structured data.

Trust and operating boundaries

The builder should reduce uncertainty without collecting the project.

Input and privacy boundary

The builder works inside the browser tab. It does not submit, save, or place the project fields into analytics events.

  • Do not enter passwords or full payment-card data.
  • Do not paste restricted client material without permission.
  • Use approved evidence and privacy-safe examples.
  • Read the Privacy Policy and Acceptable Use Policy before sensitive work.

Output and approval boundary

A strong score means the input is better controlled. It does not prove factual accuracy, legal compliance, search performance, or implementation quality.

  • Human review remains required for every output.
  • Blocked or conflicting topics stay outside production.
  • No ranking, traffic, lead, sale, or rich-result outcome is promised.
  • Final structured data follows approved visible copy and the deployed page.
Common questions

Source context FAQ

What is a source context template?

A source context template is a structured project input that defines the site, offer, audience, market, entities, topic boundaries, current pages, link routes, proof, voice, workflow goal, and requested MIRENA output.

Why should source context come before a topical map?

A topical map needs approved scope, entity priorities, existing URLs, exclusions, conversion routes, and a target output. Without those controls, the map can recommend the wrong pages or expand beyond the site.

Can one source context support several MIRENA outputs?

Yes. The same approved context can support a processed topical map, entity map, content brief, rewrite brief, information gain audit, internal link map, SERP feature brief, or semantic optimization report. The selected output changes which fields carry the most weight.

How does the source context score work?

The builder scores fourteen context fields against the selected output. It gives extra weight to the inputs that matter most for that job, then lists missing requirements, useful additions, and direct conflicts.

What is the difference between a warning and a blocker?

A warning marks an input that would improve the output. A blocker marks a required field, unresolved topic conflict, or missing output-specific condition that should stop handoff.

Should existing URLs be included?

Yes. Add important hubs, commercial pages, documentation, proof, support, comparison pages, and pages to protect, repair, merge, hold, or block. This reduces duplicate recommendations and weak link routes.

Why are excluded topics required?

Excluded topics give MIRENA a stop condition. They prevent broad query expansion, unrelated entities, and page ideas that do not support the offer, audience, or approved workflow.

Does the builder send or save the information I enter?

No. This standalone builder creates the score, prompt, and files inside the browser tab. It has no form endpoint, network submission, or browser storage call.

What happens after the source context is approved?

Move it into the selected MIRENA job. Keep the approved context attached to every later map, brief, rewrite, link, and review pass so the project does not drift.

When should structured data be created?

Final structured data should be created only after the written page receives human approval and the deployed visible content, URLs, entities, and page type have been checked.

Give MIRENA a controlled project, not a loose topic.

Build the context, resolve the blockers, record the human approval, and carry the approved input into the selected workflow.