MWMS MCR

HeadOffice Newsletter Intelligence Output Validation Protocol

Document Type: Protocol
Status: Active
Authority: HeadOffice
Applies To: HeadOffice, Newsletter Intelligence System, Supabase Intelligence Records
Parent: HeadOffice
Version: v1.0
Last Reviewed: 2026-05-01

Purpose

The HeadOffice Newsletter Intelligence Output Validation Protocol defines how structured newsletter intelligence outputs are evaluated after ingestion into Supabase.

This protocol ensures:

  • extracted intelligence is usable
  • signal quality is maintained
  • Brain routing accuracy is verified
  • action types are correctly assigned
  • priority is meaningful
  • system outputs remain reliable
  • prompt adjustments are controlled
  • system drift is prevented

Without validation:

  • poor insights enter the system
  • Brain routing becomes unreliable
  • noise is mistaken for signal
  • prompt tuning becomes random
  • system trust declines
  • Daily Signal Log becomes inaccurate

This protocol ensures MWMS intelligence is validated before use.

Scope

This protocol applies to:

  • Supabase newsletter_intelligence_items records
  • Make scenario output validation
  • structured intelligence produced via extraction protocol
  • daily batch testing of newsletter ingestion
  • signal quality assessment before routing and logging

This protocol governs:

  • output quality checks
  • Brain routing validation
  • action type validation
  • signal strength validation
  • prompt refinement triggers

This protocol does not govern:

  • extraction logic itself
  • Brain-level analysis
  • execution decisions
  • routing execution
  • Daily Signal Log entry creation

Core Principle

Structured output must be validated before it is trusted.

No intelligence may be used for:

  • routing
  • decision-making
  • signal logging

until it passes validation.

Validation is mandatory for system reliability.

Validation Trigger

Validation occurs after:

Make Scenario Run
↓
Supabase Records Created
↓
Validation Process Begins

Validation must be performed:

  • after batch test runs
  • after prompt updates
  • before signal logging
  • before routing review

Validation Dimensions

Each record must be evaluated across five dimensions:

  1. Insight Quality
  2. Extraction Layer Accuracy
  3. Brain Assignment Accuracy
  4. Action Type Accuracy
  5. Signal Strength

All five must be validated.

Validation Criteria

  1. Insight Quality

A valid insight must:

  • represent one clear signal
  • be specific (not generic)
  • describe a meaningful change, pattern, or opportunity
  • be relevant to MWMS system or business
  • avoid summary-style wording

Valid Example:

“AI tools are shifting toward embedded workflow automation rather than standalone use.”

Invalid Example:

“This newsletter discusses AI tools and trends.”

Failure Conditions:

  • vague language
  • summarised content
  • multiple signals in one entry
  • no MWMS relevance

Action:

→ mark as invalid output

  1. Extraction Layer Accuracy

The extraction_layer must:

  • match the actual nature of the insight
  • reflect the primary classification (not secondary tags)

Correct Mapping Examples:

Tool update → tool_and_technology_intelligence
Market shift → strategic_trend_signal
Policy update → compliance_and_policy_intelligence

Failure Conditions:

  • wrong layer selected
  • signal_type used instead of extraction_layer
  • inconsistent classification across similar insights

Action:

→ mark as classification error

  1. Brain Assignment Accuracy

Primary Brain must:

  • match the domain of impact
  • follow Brain authority boundaries

Examples:

AI infrastructure → AIBS Brain
Monetisation → Affiliate Brain
Platform update → Ads Brain or Compliance Brain
Strategy shift → Strategy Brain

Failure Conditions:

  • incorrect Brain assignment
  • missing primary Brain (when required)
  • too many supporting Brains without reason

Action:

→ mark as routing error

  1. Action Type Accuracy

Action type must reflect real system need:

Park → early or unclear signal
Review → requires Brain evaluation
Build Later → future capability
Reject → no value

Failure Conditions:

  • everything marked as review
  • high-value signal marked as park
  • noise marked as review
  • no differentiation between signals

Action:

→ mark as decision classification error

  1. Signal Strength Validation

Each insight must be judged:

Weak Signal:

  • low clarity
  • low relevance
  • single-source noise

Medium Signal:

  • relevant but not reinforced
  • useful but not urgent

Strong Signal:

  • clear impact
  • high relevance
  • pattern forming or repeated

Failure Conditions:

  • weak signals treated as strong
  • no differentiation in signal strength
  • all insights treated equally

Action:

→ mark as signal quality issue

Validation Outcome Categories

Each record must be classified:

Valid

  • passes all validation dimensions
  • usable for system

Partial

  • minor issues
  • usable with caution

Invalid

  • fails key validation checks
  • must not be used

Batch Validation Rule

After testing:

HeadOffice must assess:

  • % of valid records
  • % of partial records
  • % of invalid records

Decision Thresholds:

High Quality Batch:

  • ≥ 70% valid
  • ≤ 10% invalid

Acceptable Batch:

  • ≥ 50% valid
  • ≤ 20% invalid

Poor Batch:

  • < 50% valid
  • > 20% invalid

Poor batch requires prompt refinement.

Prompt Refinement Rules

Prompt may be updated ONLY if:

  • repeated validation failures occur
  • patterns of error are visible
  • classification errors are consistent
  • insights are consistently vague

Prompt must NOT be updated:

  • based on one bad record
  • based on subjective preference
  • without identifying failure pattern

Refinement must target:

  • insight clarity
  • extraction layer accuracy
  • Brain assignment accuracy
  • action type differentiation

System Feedback Loop

Make Run
↓
Supabase Records
↓
Validation Protocol
↓
Identify Errors
↓
Adjust Prompt (if needed)
↓
Re-run Test
↓
Re-validate
↓
Stable Output Achieved

Daily Signal Log Dependency

Daily Signal Log must ONLY use:

→ validated strong signals

Unvalidated outputs must not influence:

  • signal logging
  • strategic awareness
  • decision-making

Governance Role

HeadOffice is responsible for:

  • validating outputs
  • protecting system quality
  • controlling prompt adjustments
  • preventing weak intelligence from entering system
  • maintaining trust in structured data

HeadOffice ensures:

only validated intelligence flows forward.

Drift Protection

The system must prevent:

  • trusting unvalidated outputs
  • adjusting prompts randomly
  • accepting vague insights
  • incorrect Brain routing entering system
  • weak signals becoming strategic signals
  • inconsistent classification
  • poor data entering Daily Signal Log

Validation discipline protects system intelligence quality.

Architectural Intent

This protocol ensures MWMS intelligence pipeline becomes:

self-correcting
stable
reliable
scalable

It creates a feedback loop between:

extraction
storage
validation
refinement

This transforms the system from:

data collection

into:

intelligence generation

Change Log

Version: v1.0
Date: 2026-05-01
Author: HeadOffice

Change:
Initial creation of HeadOffice Newsletter Intelligence Output Validation Protocol to define structured validation rules for Supabase intelligence outputs, ensuring system reliability and enabling controlled prompt refinement.

Change Impact Declaration

Pages Created:

HeadOffice Newsletter Intelligence Output Validation Protocol

Pages Updated:

None

Pages Deprecated:

None

Registries Requiring Update:

HeadOffice Page Registry

Canon Version Update Required:

No

Change Log Entry Required:

No