Build a Source Register for AI Email Brand Knowledge

An AI email system should not treat every sentence on a website, every prompt instruction, and every manually saved fact as equally trustworthy. Build a source register that tells creators what a fact means, where it came from, when it was verified, who owns it, and when it must stop being used.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 3, 2026.

Migma’s brand configuration guide says it can inspect public pages for product, style, writing, and company details. It tells the user to review logos, colors, type, company details, and saved guidance. Manually added product facts, approved messages, offers, and words remain when website details refresh.

That persistence is useful, but it creates a governance question: if a public page changes while a manually saved offer remains, which source should an email use?

Separate facts from instructions and references#

Use four record types:

Scroll table →

Type	Example	Validation question	Typical expiry
Factual claim	“Plan includes 20 seats”	Is the value current and attributable?	At product or policy change
Time-bound offer	“20% off through Friday”	Are dates, audience, and exclusions complete?	Hard stop at offer end
Writing instruction	“Use sentence case”	Is this still approved brand direction?	Review cadence
Design reference	Approved launch email	Is it direction rather than copy to reproduce?	Until replaced or retired

Do not place all four into a generic “brand memory” field. Facts need evidence; offers need activation windows; instructions need an owner; references need reuse boundaries.

Minimum source register#

Scroll table →

Field	What to record
Record ID	Stable identifier used in briefs and approvals
Exact approved statement	Narrow fact or instruction, not a vague topic
Type and scope	Fact, offer, instruction, or reference; applicable product/market
Source URL or system	Authoritative location, not just the page title
Source owner	Team accountable for correctness
Event/effective date	When the underlying change became true
Verified at / verified by	Latest human source check
Valid from / expires at	Enforcement window when applicable
Confidence	Approved, provisional, disputed, or retired
Conflict rule	Which source wins and who resolves ambiguity
Downstream locations	Migma brand, prompt library, CRM, template, or campaign

Keep event date separate from verification date. Reopening a page today does not mean its product fact changed today.

Use explicit precedence#

A practical default is:

approved structured product, legal, pricing, or offer system;
dated manual fact approved by its accountable owner;
current first-party public page;
inferred website text or historical design reference;
unsupported prompt text.

This is an operational default, not a universal truth. A public status page may outrank an internal launch plan during an incident; a jurisdiction-specific legal instruction may override general brand copy. Encode those exceptions rather than asking a model to guess.

If two active records conflict, block the affected claim. Do not resolve it by recency alone: the newest observation can be a cached page, an accidental edit, or a future announcement published early.

Connect the register to Migma#

Migma documents website-derived findings, Brand Guidelines, AI Instructions, Design references, and Visual Identity as distinct surfaces. Its MCP guide also exposes migma_add_knowledge_base for lasting facts such as tone, products, offers, and policies.

Before adding a lasting fact through the product or an agent:

require a source-register ID in the change ticket;
save only the narrow approved statement;
include applicable market, product, and time window in the text when the destination lacks structured fields;
record the Migma brand and editor or agent that made the change;
schedule removal or re-verification outside the model;
generate a test email that tries both valid and invalid contexts.

The API or MCP call can save a fact. It does not prove that the fact is current, complete, or legally usable.

Refresh workflow#

Detect change. Website refresh, product release, policy edit, or owner request creates a candidate difference.
Classify it. Decide whether it changes a fact, offer, instruction, visual choice, or only wording.
Compare sources. Check the authoritative system and current effective date.
Approve deliberately. Named owner accepts, rejects, or scopes the new record.
Propagate. Update each listed downstream location; do not assume a website refresh replaces manually saved guidance.
Test retrieval. Ask for an email in the affected and unaffected scopes, including an expired-date case.
Close lineage. Link the retired record to its successor and preserve why it changed.

Regression fixtures#

Maintain a small suite for high-risk brand knowledge:

a product name shared by two plans;
a price that differs by currency or billing period;
an expired offer still present in an old email;
an instruction that applies to marketing but not service messages;
a prohibited phrase embedded in a design reference;
two website pages with conflicting company details;
a manually saved fact after a website refresh;
a deleted product requested by a legacy prompt.

Pass only when the system uses the approved scoped fact, declines conflicting or expired material, and exposes the record IDs used for review.

Evidence limits#

Marketing Wiki did not import a website, inspect a Migma brand, add knowledge through MCP, or measure retrieval accuracy. The documentation establishes the available brand surfaces and persistence behavior. It does not document automatic expiry, source citations in every generated email, conflict detection, or audit retention. The register and precedence rules are controls the operating team must implement around the product.