System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Routed Actions, HeadOffice Dashboard, Finance Brain, Experimentation Brain, Ads Brain, Affiliate Brain, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS KPI Dashboard And Insight Summary Framework.

This framework explains how MWMS selects, structures, validates, displays, and interprets key performance indicators, dashboard cards, insight summaries, status panels, risk indicators, and decision-ready dashboard views.

MWMS dashboards must not become cluttered reporting screens.

A dashboard must help HeadOffice and the Brains quickly understand:

what matters now
what is improving
what is failing
what needs action
what needs testing
what needs monitoring
what is blocked
what is risky
what requires human review
who owns the next action

The purpose of a KPI dashboard is not to show everything.

The purpose is to show the few things that matter most.

The purpose of an insight summary is not to repeat the number.

The purpose is to explain what the number means and what MWMS should do next.

Scope

This framework applies to all MWMS KPI dashboards, dashboard cards, insight summaries, status views, operational scorecards, and future client dashboards.

This includes dashboards and summaries for:

HeadOffice Dashboard
Newsletter Intelligence
Routed Actions
Brain Room activity
AI Employee outcomes
AI Employee failures
Permission Gatekeeper records
Operational Decision records
Structured Analysis records
Forecasting and Scenario Planning records
Course Absorption progress
Opportunity System
Affiliate offer pipeline
Research Brain findings
Finance Brain exposure
Experimentation Brain test results
Ads Brain performance
Content Brain production
M developer progress
system stability
recurring reports
future AIBS client dashboards
future AIBS client weekly reports

This framework applies before any KPI, dashboard card, insight panel, summary block, or client-facing visual is treated as operationally useful or dashboard-ready.

This framework does not authorize technical development, plugin/UI work, Supabase schema work, dashboard build work, client delivery, or automation by itself.

It defines the governance standard for KPI and insight-summary design.

Core Definition

A KPI is a key performance indicator that helps MWMS understand progress, risk, performance, quality, activity, or outcome.

An Insight Summary is a short explanation that turns a KPI, trend, status, or dashboard item into decision-ready meaning.

A KPI answers:

What is the measurable state?

An insight summary answers:

What does this mean, why does it matter, and what should happen next?

MWMS dashboards should combine both.

A dashboard that shows numbers without meaning is weak.

A dashboard that shows meaning without source data is risky.

A strong MWMS dashboard needs:

clean source data
selected KPIs
readable visual layout
concise insight summaries
owners
next actions
risk status
review status
decision relevance

Core Principle

The core principle of this framework is:

Dashboards must help HeadOffice decide faster and better.

A dashboard is successful only when it improves:

attention
prioritization
decision quality
risk control
owner clarity
workflow visibility
outcome tracking
system learning

A dashboard fails when it becomes:

decorative
overloaded
vague
stale
noisy
unactionable
ownerless
disconnected from decisions

MWMS should prefer a small number of high-quality KPIs over a large number of weak metrics.

KPI Dashboard Design Principles

1. The Five Second Rule

A dashboard should communicate the main operational picture within five seconds.

A user should quickly understand:

what needs attention
what is safe
what is blocked
what is urgent
what changed
what action is required

Five Second Rule:

If the dashboard cannot reveal the main situation quickly, it is too noisy.

This does not mean every detail must be visible in five seconds.

It means the top-level decision picture must be clear.

2. Few Metrics Beat Many Metrics

MWMS should not track everything just because data exists.

The best dashboards usually show a small set of meaningful KPIs.

Strong dashboards may use:

5 to 10 top-level KPIs
supporting drill-down cards
filtered queue views
insight summaries
risk alerts

Few Metrics Rule:

Every KPI must earn its place.

If a metric does not support a decision, action, risk review, or outcome review, it should be removed, parked, or moved to a lower-level report.

3. Leading And Lagging Indicators Must Be Balanced

MWMS needs both leading and lagging indicators.

Leading Indicators

Leading indicators show what may happen next.

Examples:

number of blocked actions
number of missing owners
rising validation failures
repeated newsletter signals
increasing finance exposure
offer research backlog
M tasks waiting for evidence
schema failures before automation

Lagging Indicators

Lagging indicators show what already happened.

Examples:

completed outcomes
revenue generated
tests completed
pages created
failures closed
campaigns completed
reports delivered
tasks completed

Leading And Lagging Rule:

Leading indicators help MWMS act early. Lagging indicators help MWMS judge results.

Dashboards should not rely only on historical results.

4. Every KPI Needs Context

A KPI without context can mislead.

Context may include:

source
time range
comparison period
owner
status
risk level
confidence level
trend
target
threshold
source quality
human review status

Example:

“12 open actions” is weak.

“12 open actions, 3 high priority, 2 blocked, 1 ownerless” is useful.

Context Rule:

A KPI should not stand alone if it affects decisions.

5. Every Important Dashboard Item Needs Meaning

A dashboard item should explain why it matters.

Good insight summary:

“Three high-priority routed actions are blocked because owners are missing. HeadOffice should assign owners before creating new actions.”

Weak insight summary:

“Routed actions increased.”

Meaning Rule:

Insight summaries must explain operational meaning, not repeat the metric.

6. Dashboards Must Separate Draft From Active

MWMS dashboards must not mix draft, unvalidated, parked, rejected, and active items as if they are equal.

Statuses should be clearly separated:

Draft
Ready For Review
Active
Routed
Parked
Rejected
Completed
Escalated
Blocked

Status Rule:

Draft data should not appear as active operational truth.

This is critical for Newsletter Intelligence, Routed Actions, M developer tasks, client reports, and future automation.

7. Dashboards Must Show Ownership

Any dashboard item requiring action should have an owner.

Possible owners:

Martyn
HeadOffice
M
Research Brain
Finance Brain
Experimentation Brain
Ads Brain
Affiliate Brain
Content Brain
Validation Agent
Failure Handler Agent
Outcome Logger Agent
Future Client Review Owner

Owner Rule:

An actionable dashboard item without an owner is not ready.

8. Dashboards Must Show Next Action

A dashboard should not only say what is happening.

It should show what should happen next.

Examples:

review
assign owner
route to Research
route to Finance
park
reject
validate
escalate
prepare M handoff
monitor
close
update report
request evidence

Next Action Rule:

A dashboard item without a next action becomes passive reporting.

9. Dashboards Must Show Risk

Risk must be visible where it affects decisions.

Risk levels:

Low
Medium
High
Critical

Risk may relate to:

finance
compliance
MCR integrity
developer work
automation
data quality
client trust
paid traffic
public content
system stability

Risk Rule:

High-risk items must be visually and operationally harder to ignore.

10. Dashboards Must Be Retired Or Refined

Dashboards should improve over time.

A KPI, card, panel, or summary should be revised or removed if it:

is not used
creates confusion
duplicates another metric
has weak data
produces no decisions
creates noise
lacks owner
lacks action
is stale
cannot be validated

Refinement Rule:

Dashboards should evolve through Kaizen, not accumulate clutter.

KPI Categories

MWMS recognizes the following KPI categories.

1. Action KPIs

Used to track operational work requiring attention.

Examples:

Open Routed Actions
High Priority Actions
Blocked Actions
Ownerless Actions
Overdue Actions
Actions Completed This Week

Purpose:

To help HeadOffice manage operational flow.

2. Signal KPIs

Used to track intelligence signals.

Examples:

ACT NOW Signals
TEST Signals
MONITOR Signals
Parked Signals
Rejected Noise
Repeated Signal Themes

Purpose:

To separate useful intelligence from noise.

3. Risk KPIs

Used to track risk exposure.

Examples:

Critical Risks
High-Risk Developer Items
Finance Exposure Alerts
Compliance Flags
Client Review Risks
Automation Readiness Risks

Purpose:

To make risk visible before it becomes damage.

4. Outcome KPIs

Used to track useful results.

Examples:

Useful Outcomes Created
Decisions Supported
Risks Reduced
Pages Improved
Failures Corrected
Reports Used
M Tasks Clarified

Purpose:

To measure value, not output volume.

5. Failure KPIs

Used to track failures and recurring weaknesses.

Examples:

Validation Failures
Schema Failures
Tool Failures
Handoff Failures
Context Failures
Permission Blocks
Repeated Correction Types

Purpose:

To support Kaizen and system hardening.

6. Workflow KPIs

Used to track workflow health.

Examples:

Items Waiting For Review
Items Waiting For Validation
Items Waiting For Research
Items Waiting For Finance
Items Waiting For M
Items Parked
Items Rejected

Purpose:

To identify bottlenecks and stalled work.

7. Finance KPIs

Used to track money and exposure.

Examples:

Active Test Budget
Spend To Date
Break-Even Gap
Cash Exposure
Tool Cost
Contractor Cost
Campaign Risk
Approved Budget Remaining

Purpose:

To prevent uncontrolled financial risk.

8. Experimentation KPIs

Used to track tests and learning.

Examples:

Active Tests
Completed Tests
Winning Tests
Failed Tests
Tests Awaiting Decision
Tests Without Success Criteria
Learning Captured

Purpose:

To ensure testing produces learning, not random activity.

9. Developer KPIs

Used to track M and development workflow health.

Examples:

M Tasks Open
M Tasks Blocked
Tasks Waiting For Evidence
Tasks Completed
Safe Save Points
Failed Tests
Items Not To Touch

Purpose:

To support M without creating unclear or risky work.

10. Client KPIs

Used for future AIBS client systems.

Examples:

Client Reports Drafted
Client Reports Reviewed
Client Risks
Client Decisions Needed
Client Workflow Health
Client Actions Completed
Client Data Quality Issues

Purpose:

To support safe, clear, reviewed client reporting.

Insight Summary Structure

Every important dashboard insight should follow this structure.

1. What Happened

State the observable fact.

Example:

“Five routed actions are currently blocked.”

2. Why It Matters

Explain the business or operational meaning.

Example:

“Blocked actions reduce HeadOffice visibility and delay Brain-to-Brain workflow progress.”

3. Risk Or Opportunity

Explain the risk or opportunity.

Example:

“If owners are not assigned, these actions may become stale and create dashboard noise.”

4. Recommended Action

State what should happen next.

Example:

“Assign owners or park low-priority items before creating more actions.”

5. Owner

State who owns the next action.

Example:

“Owner: HeadOffice.”

Quick Insight Summary Format

What Happened:
Why It Matters:
Risk Or Opportunity:
Recommended Action:
Owner:

Dashboard Item Record Template

Use this template when defining a KPI card, insight card, or dashboard item.

Dashboard Item Name

Field:
Dashboard Item Name:

Dashboard Item Type

Field:
Dashboard Item Type:

Recommended values:

KPI Card
Insight Card
Risk Alert
Queue Panel
Trend Panel
Scorecard
Report Panel
Client Dashboard Item

Dashboard Purpose

Field:
Dashboard Purpose:

Owning Brain

Field:
Owning Brain:

Data Source

Field:
Data Source:

KPI Or Metric

Field:
KPI Or Metric:

Time Range

Field:
Time Range:

Recommended values:

Today
This Week
Last 7 Days
This Month
Last 30 Days
Current Sprint
Current Campaign
Current Report Period
Custom

Source Quality

Field:
Source Quality:

Recommended values:

Strong
Usable
Partial
Weak
Stale
Unknown

Current Value

Field:
Current Value:

Comparison Value

Field:
Comparison Value:

Trend

Field:
Trend:

Recommended values:

Improving
Stable
Declining
Spiking
Unknown
Not Applicable

Status

Field:
Status:

Recommended values:

Draft
Ready For Review
Active
Parked
Rejected
Completed
Escalated
Retired

Priority

Field:
Priority:

Recommended values:

Low
Medium
High
Critical

Risk Level

Field:
Risk Level:

Recommended values:

Low
Medium
High
Critical

Insight Summary

Field:
Insight Summary:

Recommended Action

Field:
Recommended Action:

Owner

Field:
Owner:

Review Frequency

Field:
Review Frequency:

Recommended values:

Manual
Daily
Weekly
Monthly
Per Campaign
Per Sprint
Per Client Cycle
On Change

Human Review Required

Field:
Human Review Required: Yes / No

Dashboard Destination

Field:
Dashboard Destination:

Failure Conditions

Field:
Failure Conditions:

Last Reviewed

Field:
Last Reviewed:

Quick Use Version

Dashboard Item Name:
Dashboard Item Type:
Dashboard Purpose:
Owning Brain:
Data Source:
KPI Or Metric:
Time Range:
Source Quality:
Current Value:
Comparison Value:
Trend:
Status:
Priority:
Risk Level:
Insight Summary:
Recommended Action:
Owner:
Review Frequency:
Human Review Required:
Dashboard Destination:
Failure Conditions:
Last Reviewed:

Core MWMS Dashboard Examples

Example 1: HeadOffice ACT NOW KPI

Dashboard Item Name:
HeadOffice ACT NOW Count

Dashboard Item Type:
KPI Card / Risk Alert

Dashboard Purpose:
Show how many items currently require immediate HeadOffice attention.

Owning Brain:
HeadOffice Brain

Data Source:
Routed Actions, Newsletter Queue Review, Risk Alerts, Operational Decision records.

KPI Or Metric:
Number of active ACT NOW items.

Time Range:
This Week

Source Quality:
Usable if records have status, priority, owner, and next action.

Current Value:
Number of active ACT NOW items.

Comparison Value:
Previous week ACT NOW count.

Trend:
Improving / Stable / Spiking / Unknown

Status:
Active

Priority:
High / Critical

Risk Level:
Medium to Critical depending on items.

Insight Summary:
Shows whether HeadOffice has immediate actions requiring attention.

Recommended Action:
Review ACT NOW items before creating new work.

Owner:
HeadOffice

Review Frequency:
Daily

Human Review Required:
Yes

Dashboard Destination:
HeadOffice Dashboard

Failure Conditions:
Missing owners, stale ACT NOW items, vague recommended actions.

Last Reviewed:
YYYY-MM-DD

Example 2: Newsletter Signal Quality KPI

Dashboard Item Name:
Newsletter Signal Quality Summary

Dashboard Item Type:
KPI Card / Insight Card

Dashboard Purpose:
Show whether Newsletter Intelligence is producing useful signals or noise.

Owning Brain:
HeadOffice Brain

Data Source:
newsletter_intelligence records and Newsletter Queue Review.

KPI Or Metric:
Count of ACT NOW, TEST, MONITOR, PARK, and REJECT items.

Time Range:
Last 7 Days

Source Quality:
Usable if email body capture is complete and fields are valid.

Current Value:
Signal counts by action type.

Comparison Value:
Previous 7 days.

Trend:
Improving / Stable / Declining / Unknown

Status:
Active after validation.

Priority:
Medium

Risk Level:
Medium

Insight Summary:
Shows whether external intelligence is producing action-worthy material or mostly rejected noise.

Recommended Action:
Tighten extraction rules if too many weak signals reach review.

Owner:
HeadOffice

Review Frequency:
Weekly

Human Review Required:
Yes before downstream action.

Dashboard Destination:
HeadOffice Dashboard / Newsletter Intelligence Digest

Failure Conditions:
Generic extracted insights, missing action type, incomplete body source, inflated urgency.

Last Reviewed:
YYYY-MM-DD

Example 3: Routed Actions Health KPI

Dashboard Item Name:
Routed Actions Health Panel

Dashboard Item Type:
Queue Panel / KPI Card

Dashboard Purpose:
Show whether routed actions are moving, blocked, ownerless, or stale.

Owning Brain:
HeadOffice Brain

Data Source:
Routed Actions records.

KPI Or Metric:
Open, blocked, ownerless, overdue, and completed actions.

Time Range:
This Week

Source Quality:
Usable if owner, status, due date, priority, and next action fields are complete.

Current Value:
Counts by status.

Comparison Value:
Previous week.

Trend:
Improving / Stable / Declining / Unknown

Status:
Active

Priority:
High if blocked or ownerless items exist.

Risk Level:
Medium to High

Insight Summary:
Shows whether action routing is healthy or creating operational drag.

Recommended Action:
Assign owners, close completed items, park stale items, escalate blockers.

Owner:
HeadOffice

Review Frequency:
Daily / Weekly

Human Review Required:
Yes for escalations.

Dashboard Destination:
HeadOffice Dashboard / Routed Actions Panel

Failure Conditions:
Missing owner, missing next action, stale records, too many parked items shown as active.

Last Reviewed:
YYYY-MM-DD

Example 4: AI Employee Outcome KPI

Dashboard Item Name:
AI Employee Outcome Value Scorecard

Dashboard Item Type:
Scorecard / Report Panel

Dashboard Purpose:
Show whether AI Employees are producing useful outcomes rather than output volume.

Owning Brain:
HeadOffice Brain

Data Source:
AI Agent Outcome Logs, Failure Logs, validation results.

KPI Or Metric:
Useful outcomes, weak outcomes, repeated failures, risks reduced, decisions supported.

Time Range:
This Month

Source Quality:
Partial until outcome logging is consistent.

Current Value:
Outcome counts and value categories.

Comparison Value:
Previous month or previous review cycle.

Trend:
Improving / Stable / Declining / Unknown

Status:
Draft / Active after manual proof.

Priority:
Medium

Risk Level:
Medium

Insight Summary:
Shows whether the AI workforce is improving MWMS or creating activity without outcomes.

Recommended Action:
Improve weak skills, merge overlapping roles, revise validation, or park low-value workflows.

Owner:
HeadOffice

Review Frequency:
Monthly

Human Review Required:
Yes

Dashboard Destination:
AI Employee Outcome Review / HeadOffice Dashboard

Failure Conditions:
Output volume counted as outcome, inflated value, missing examples, no Kaizen action.

Last Reviewed:
YYYY-MM-DD

Example 5: Finance Exposure KPI

Dashboard Item Name:
Finance Exposure Risk Card

Dashboard Item Type:
KPI Card / Risk Alert

Dashboard Purpose:
Show whether current tests, campaigns, or tools create financial exposure.

Owning Brain:
Finance Brain

Data Source:
Finance notes, ad spend records, campaign budgets, offer payout data.

KPI Or Metric:
Active exposure, approved test budget, spend to date, break-even risk.

Time Range:
Current Campaign / This Week

Source Quality:
Partial unless tracking, payout, and spend data are verified.

Current Value:
Current exposure amount or risk status.

Comparison Value:
Approved budget or prior period.

Trend:
Improving / Stable / Declining / Unknown

Status:
Active only after validation.

Priority:
High

Risk Level:
High

Insight Summary:
Shows whether current testing remains within safe financial boundaries.

Recommended Action:
Pause, continue, review assumptions, or escalate to HeadOffice.

Owner:
Finance Brain / HeadOffice

Review Frequency:
Daily during active spend.

Human Review Required:
Yes before spend increase.

Dashboard Destination:
Finance Brain / HeadOffice Dashboard

Failure Conditions:
Missing payout, missing spend data, tracking mismatch, outdated finance assumptions.

Last Reviewed:
YYYY-MM-DD

Example 6: M Developer Blocker KPI

Dashboard Item Name:
M Developer Blocker Card

Dashboard Item Type:
Risk Alert / Queue Panel

Dashboard Purpose:
Show whether M has blocked tasks or unclear handoffs.

Owning Brain:
HeadOffice Brain

Data Source:
Brain Room, Dev Console, M task notes, user-confirmed save points.

KPI Or Metric:
Number of blocked M tasks, tasks waiting for evidence, and tasks with unclear instructions.

Time Range:
Current Sprint

Source Quality:
Usable if current save point and task evidence are known.

Current Value:
Count of blocked or evidence-waiting tasks.

Comparison Value:
Previous review period.

Trend:
Improving / Stable / Declining / Unknown

Status:
Active

Priority:
High if active build is blocked.

Risk Level:
High

Insight Summary:
Shows whether M can continue safely or needs clarification.

Recommended Action:
Provide file path, current evidence, test steps, or park unclear task.

Owner:
Martyn / HeadOffice

Review Frequency:
Daily during active development.

Human Review Required:
Yes

Dashboard Destination:
HeadOffice Dashboard / Dev Console / Brain Room

Failure Conditions:
Old save point used, file path missing, M would need to guess, unrelated system risk.

Last Reviewed:
YYYY-MM-DD

Example 7: Future AIBS Client KPI

Dashboard Item Name:
Client Workflow Health KPI

Dashboard Item Type:
Client Dashboard Item / KPI Card / Insight Card

Dashboard Purpose:
Show client workflow status in simple business language.

Owning Brain:
AI Business Systems Brain

Data Source:
Approved client workflow records and reviewed client data.

KPI Or Metric:
Workflow health, open issues, decisions needed, completed actions, risk status.

Time Range:
Current Report Period

Source Quality:
Must be Strong or Usable and client-approved.

Current Value:
Client workflow status.

Comparison Value:
Previous client report period.

Trend:
Improving / Stable / Declining / Unknown

Status:
Draft until human approved.

Priority:
Medium to High depending on client issue.

Risk Level:
High because client-facing.

Insight Summary:
Explains what changed, why it matters, and what the client should do next.

Recommended Action:
Review with client, request data, approve action, or monitor.

Owner:
Client Review Owner / HeadOffice

Review Frequency:
Per Client Cycle

Human Review Required:
Always before delivery.

Dashboard Destination:
Client Review Queue / client dashboard after approval.

Failure Conditions:
Unapproved data, privacy risk, unsupported claim, unclear recommendation, missing client review.

Last Reviewed:
YYYY-MM-DD

KPI Dashboard Readiness Checklist

Before a KPI, dashboard item, or insight summary becomes active, check:

Is the dashboard purpose clear?
Is the owning Brain clear?
Is the data source known?
Is the source quality acceptable?
Is the KPI decision-relevant?
Is the time range defined?
Is the current value available?
Is comparison value available where needed?
Is the trend clear?
Is status clear?
Is priority assigned?
Is risk level assigned?
Is the insight summary meaningful?
Is recommended action specific?
Is owner assigned where needed?
Is review frequency appropriate?
Is human review required where needed?
Is destination clear?
Are failure conditions listed?
Is draft data separated from active data?
Are parked and rejected items handled correctly?
Is stale data marked?
Does this pass the five second rule?
Does this help HeadOffice decide?
Should this KPI be active, revised, parked, or retired?

If several answers are unclear, the dashboard item is not ready.

Common KPI Dashboard Failure Modes

KPI dashboard design has failed if:

Dashboard tracks everything.
Dashboard has no clear decision purpose.
KPI is a vanity metric.
Source data is weak or unknown.
Data is stale but not marked.
Draft items appear as active.
Parked or rejected items inflate active counts.
KPI has no insight summary.
Insight summary repeats the number but adds no meaning.
Recommended action is missing.
Owner is missing.
Risk is hidden.
High-priority items are not visually distinct.
Too many KPIs are shown at once.
Dashboard is harder to understand than the source data.
Client dashboard includes unapproved data.
Dashboard is not reviewed or refined.
Dashboard creates noise instead of decisions.

Manual Use Rule

KPI dashboards and insight summaries should be manually proven before becoming automated dashboards or client-facing systems.

Manual use helps MWMS learn:

which KPIs matter
which KPIs create noise
which insight summaries help HeadOffice act
which data sources are reliable
which statuses are confusing
which dashboard cards need owners
which metrics should be leading indicators
which metrics should be lagging indicators
which dashboard sections should be retired
which client KPIs are safe and useful

Manual dashboard discipline comes before automation, plugin/UI build, or client delivery.

Future Plugin Or UI Relevance

This framework may later support:

HeadOffice KPI dashboard
HeadOffice Command Center
Newsletter Intelligence dashboard
Routed Actions dashboard
AI Employee outcome dashboard
Failure dashboard
Finance exposure dashboard
Experimentation dashboard
Ads performance dashboard
Opportunity pipeline dashboard
M developer progress dashboard
AIBS client dashboard
KPI schema registry
dashboard insight summary generator

Possible future fields:

dashboard_item_id
dashboard_item_name
dashboard_item_type
dashboard_purpose
owning_brain
data_source
kpi_or_metric
time_range
source_quality
current_value
comparison_value
trend
status
priority
risk_level
insight_summary
recommended_action
owner
review_frequency
human_review_required
dashboard_destination
failure_conditions
last_reviewed
created_at
updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS KPI Dashboard And Insight Summary Framework.

HeadOffice is responsible for:

approving KPI dashboard principles
preventing dashboard clutter
deciding which KPIs deserve top-level visibility
ensuring source data is trusted
ensuring insight summaries explain meaning
ensuring dashboard items include owner and next action where needed
ensuring risk is visible
ensuring dashboards support decisions
ensuring stale or weak dashboard items are refined or retired
protecting M’s active build areas
protecting MCR source of truth
protecting future AIBS client dashboard quality

Individual Brains may propose local KPIs, but HeadOffice governs cross-Brain, HeadOffice-level, dashboard-level, finance-related, developer-related, automation-related, and client-facing KPIs.

Relationship To Other MWMS Standards

This framework supports and must align with:

MWMS Analytics And Visualization Workflow Framework
MWMS AI Schema And Decision Ready Output Framework
MWMS Structured Analysis And Insight Workflow Framework
MWMS Operational Decision Intelligence Framework
MWMS Forecasting And Scenario Planning Framework
MWMS Recurring Intelligence And Reporting Pipeline Framework
MWMS AI Agent Operations Core
MWMS AI Context Routing Framework
MWMS AI Permission Gatekeeper Framework
MWMS AI Output Validation Standard
MWMS AI Output Validation Checklist
MWMS Agentic Reporting Standard
MWMS Agentic Reporting Template
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Outcome Log Record
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Failure Log Record
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
AI Business Systems Brain Blueprint

This framework adds the KPI and insight-summary layer to the MWMS dashboard and decision-intelligence system.

Drift Protection

This framework protects MWMS from:

Tracking everything instead of what matters
Building dashboards that do not support decisions
Treating vanity metrics as operational intelligence
Displaying dirty or stale data
Mixing draft and active records
Showing numbers without meaning
Showing risks without owners
Creating dashboard items with no next action
Hiding high-risk items inside normal status
Creating dashboard clutter
Treating visual polish as usefulness
Delivering client dashboards without review
Automating dashboards before manual proof
Letting dashboards become a second source of truth
Forgetting to retire weak KPIs

Any KPI or dashboard item that does not improve decision quality should be revised, parked, or retired.

Architectural Intent

The architectural intent of the MWMS KPI Dashboard And Insight Summary Framework is to make MWMS dashboards decision-first.

MWMS will create many records, reports, actions, signals, outcomes, failures, and tasks.

Dashboards must not merely display that activity.

They must help HeadOffice and the Brains know what matters.

The long-term goal is that every KPI and insight summary can answer:

Why does this KPI exist?
What decision does it support?
What source does it use?
Is the source trustworthy?
What does the number mean?
Is it improving or worsening?
What risk exists?
What action is recommended?
Who owns the next step?
Should this be reviewed, acted on, parked, or retired?

When MWMS controls dashboards this way, dashboards become operational intelligence tools, not decorative reporting pages.

Change Log

v1.0 — Initial Draft

Created the MWMS KPI Dashboard And Insight Summary Framework to define how MWMS selects, structures, validates, displays, and interprets KPIs, dashboard cards, insight summaries, status panels, risk indicators, queue panels, scorecards, and future client dashboard views.

This framework establishes dashboard design principles, KPI categories, insight summary structure, dashboard item templates, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that dashboards must help HeadOffice decide faster and better.