MWMS KPI Dashboard And Insight Summary Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.2
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, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-21
Source / Origin: MWMS KPI Dashboard And Insight Summary Framework v1.1 + AI Automations by Jack — actionable AI dashboards, funnel visibility, constraint identification, conversational data access, governed record updates, calendar and email actions, client-facing KPI systems and outcome-focused dashboard block
Related Pages: MWMS AI Dashboard Capability Framework, MWMS AI Agent Outcome Measurement Framework, MWMS AI Observability Metadata Standard, MWMS Business Brain Copilot Architecture Framework, MWMS AI Agent Orchestration Framework, MWMS AI Multi Agent Role Design Framework, MWMS AI Employee Capability Stack Framework, MWMS Independent Model Review And Rescue Routing Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol, MWMS AI Usage And Cost Visibility Standard
Source Evidence: The existing v1.1 framework defines decision-first KPI governance, KPI quality, metric hierarchy, role-based views, alerts, drill-downs, cost visibility, evidence, confidence, outcome tracking and AI-generated insight summaries. The newly absorbed AI Automations by Jack dashboard block adds a stronger operational distinction between visibility, diagnosis, action and outcome dashboards; funnel-stage and constraint analysis; conversational data inspection; governed write permissions; downstream action verification; client isolation; and decision-ready recommendations tied to economic value rather than decorative presentation.

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

decision_deadline

expected_outcome

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

decision_deadline

expected_outcome

owner clarity

workflow visibility

outcome tracking

system learning

A dashboard fails when it becomes:

decorative

overloaded

vague

stale

noisy

unactionable

decision_deadline

expected_outcome

ownerless

disconnected from decisions

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

MWMS Decision Dashboard Operating Model

Dashboard Value Levels

MWMS dashboards should be classified by the value they provide.

Level 1: Visibility Dashboard

A Visibility Dashboard shows what is happening.

Examples:

current values

counts

status

trend

risk level

queue size

cost

capacity

recent activity

Purpose:

To make current state visible.

Rule:

A Visibility Dashboard must not imply diagnosis, recommendation or action authority unless those functions are explicitly present.

Level 2: Diagnostic Dashboard

A Diagnostic Dashboard explains:

what changed

where the constraint sits

why the change matters

which evidence supports the diagnosis

what needs further investigation

which assumptions remain uncertain

Purpose:

To help a human understand the likely cause or operating constraint.

Rule:

A diagnostic statement must show its evidence, confidence and limitations.

Level 3: Action Dashboard

An Action Dashboard allows a user or authorised agent to initiate approved actions such as:

assign owner

change status

request review

create task

draft communication

open supporting evidence

schedule approved follow-up

update an authorised record

trigger an approved workflow

Purpose:

To convert visibility and diagnosis into governed action.

Rule:

An Action Dashboard must separate viewing, recommendation, approval, writing and external execution permissions.

Level 4: Outcome Dashboard

An Outcome Dashboard shows whether the approved action improved:

conversion

revenue

cost

delivery

response time

risk

quality

capacity

customer outcome

system reliability

Purpose:

To close the loop between action and measurable result.

Rule:

A dashboard is not decision-complete until the result of the action can be reviewed.

Dashboard Value Progression

The preferred progression is:

Visibility

→ Diagnosis

→ Recommended Action

→ Approval

→ Execution

→ Verified Outcome

→ Learning

Rule

MWMS must not skip directly from a displayed number to an external action without the required evidence, permission and confirmation.

Funnel And Constraint Dashboard Model

A funnel dashboard may represent a sequence such as:

Traffic

→ Leads

→ Qualified Leads

→ Appointments

→ Attended Appointments

→ Presentations

→ Proposals

→ Sales

→ Revenue

→ Retention

Each stage should define:

Stage Name:

Current Volume:

Prior Stage Volume:

Conversion From Prior Stage:

Target:

Warning Threshold:

Critical Threshold:

Variance:

Trend:

Data Source:

Update Time:

Freshness:

Confidence:

Primary Constraint:

Supporting Evidence:

Recommended Investigation:

Approved Action:

Owner:

Expected Outcome:

Review Date:

Rule

A funnel stage must use an agreed definition.

Do not compare stages built from inconsistent event definitions, time windows or populations.

Constraint Identification Standard

The lowest conversion rate is not automatically the highest-value opportunity.

Constraint identification should consider:

economic value

revenue impact

customer impact

downstream effect

controllability

data quality

sample size

capacity

risk

effort required

time to improvement

dependency exposure

confidence

reversibility

The system should distinguish:

Observed Constraint

A directly visible blockage or weak stage.

Suspected Cause

A reason inferred from the available evidence.

Priority Opportunity

A constraint worth addressing based on expected value and feasibility.

Rule

A dashboard may identify a likely constraint.

It must not present an inferred cause as proven fact without sufficient evidence.

Economic Value Prioritisation

A constraint should be prioritised using more than percentage movement.

Possible factors include:

value per recovered lead

value per appointment

value per sale

margin

lifetime value

cost to fix

time to fix

probability of success

risk of inaction

capacity effect

revenue timing

Rule

A small improvement at a high-value stage may matter more than a large improvement at a low-value stage.

Metric Source Of Truth Standard

Every material dashboard metric should define:

Metric Name:

Metric Definition:

Calculation Rule:

Source System:

Source Table Or Record:

Source Owner:

Update Method:

Update Frequency:

Last Successful Update:

Freshness Status:

Data Quality Status:

Client Boundary:

Project Boundary:

Confidence:

Known Limitations:

Rule

A visually attractive dashboard must not become a competing source of truth.

It is a view over governed records, definitions and calculations.

Metric Freshness Standard

Recommended freshness states:

Live

Current

Delayed

Stale

Unknown

Unavailable

The dashboard should display:

expected refresh frequency

last successful refresh

current delay

stale threshold

failure state

Rule

A stale metric must not be displayed as current without a visible warning.

Read Recommend Approve Write Execute Separation

Dashboard permissions should be separated into:

Read

View approved data.

Interpret

Calculate trends, comparisons or diagnostic summaries.

Recommend

Propose a change or action.

Approve

Authorise the proposed change or action.

Write

Modify an approved internal record.

Execute

Trigger an external effect.

Verify

Confirm that the downstream action actually succeeded.

Rule

Read access does not imply write access.

Write access does not imply external execution authority.

Recommendation does not imply approval.

Action Confirmation Standard

Before a high-impact action is executed, show:

Proposed Action:

Affected Record:

Current Value:

Proposed Value:

Reason:

Supporting Evidence:

Destination:

External Effect:

Owner:

Approval Required:

Approver:

Rollback Path:

Confirmation State:

High-impact actions may include:

sending email

changing budget

changing financial records

creating or cancelling appointments

publishing content

changing client status

starting outreach

deleting records

triggering payment

changing permissions

Rule

The user must be able to see what will change before approval.

Downstream Tool Success Verification

The system must distinguish:

Request Created

Tool Called

Tool Accepted Request

Record Created Or Updated

External Effect Completed

User Notified

Result Verified

Example:

The dashboard must not state:

Appointment Booked

unless the calendar system has returned a successful event record.

If the downstream tool fails, the dashboard should show:

failure state

error summary

affected action

retry status

human owner

safe next step

Rule

A successful AI response is not proof that the external action succeeded.

Dashboard Action Audit Record

Every material dashboard action should record:

Action ID:

Dashboard:

User Or Agent:

Role:

Permission Level:

Action Type:

Affected Record:

Old Value:

New Value:

Destination:

Requested At:

Approved At:

Executed At:

Verified At:

Tool Used:

Tool Result:

External Record ID:

Failure State:

Rollback State:

Outcome Link:

Rule

Action dashboards must support reconstruction of who changed what, why and with what result.

Client And Tenant Isolation Standard

Reusable client dashboards must isolate:

client identity

users

roles

credentials

data sources

records

knowledge sources

actions

reports

audit logs

billing records

notifications

permissions

The system must not rely only on:

a visible access code

a shared public link

a client name passed from the browser

an editable frontend field

an unprotected webhook

Rule

Client identity and access must be validated before data is retrieved or an action is executed.

Rules-Based And AI-Generated Insight Labels

Every insight should be labelled as one of:

Direct Metric

Calculated Metric

Rules-Based Alert

Rules-Based Recommendation

AI-Generated Summary

AI-Generated Diagnosis

AI-Generated Recommendation

Human Decision

The dashboard should show:

method

source evidence

confidence

assumptions

missing data

review status

Rule

AI-generated recommendations must not appear as objective system facts.

Recommendation Evidence Standard

Every material recommendation should define:

Recommendation:

Evidence:

Metric Window:

Comparison:

Assumptions:

Confidence:

Missing Data:

Expected Benefit:

Estimated Effort:

Risk:

Alternative Action:

Human Review Required:

Rule

The system should be able to explain why it recommended an action.

Universal Benchmark Prohibition

Course examples may include suggested conversion targets or operating ratios.

These must not become universal MWMS benchmarks unless validated for:

market

channel

offer

traffic source

customer type

price point

sales process

sample size

time period

Rule

A benchmark is contextual evidence, not permanent truth.

Every serious MWMS dashboard should operate across seven layers:

1. Source Layer

Defines where the data comes from.

2. Validation Layer

Confirms whether the data is complete, current, correctly classified, and safe to use.

3. KPI Layer

Selects the few indicators that matter.

4. Insight Layer

Explains what the KPI means.

5. Decision Layer

Shows the decision, approval, escalation, or next action required.

6. Ownership Layer

Shows who owns the next step.

7. Outcome Layer

Shows what happened after the decision.

Operating Model Rule

A dashboard is incomplete when it stops at measurement.

The full path is:

Source
→ Validation
→ KPI
→ Insight
→ Decision
→ Owner
→ Outcome

Dashboard Decision Classes

Every important dashboard item should support at least one decision class.

Recommended decision classes:

Act Now

Review

Approve

Reject

Escalate

Assign

Investigate

Test

Continue

Pause

Stop

Park

Monitor

Close

Decision Class Rule

A dashboard item that supports no decision should usually be removed from the top-level dashboard.

Dashboard Time Horizons

MWMS dashboards may operate across four time horizons.

Immediate

Used for urgent risks, blockers, failures, overspend, broken workflows, missing decision_deadline

expected_outcome

owners, or required approvals.

Operational

Used for daily and weekly work flow, task health, production status, action queues, client delivery, and active experiments.

Strategic

Used for monthly performance, resource allocation, Brain capability, product direction, portfolio performance, and business constraints.

Historical

Used for trends, learning, comparative review, and long-term outcomes.

Time Horizon Rule

Immediate and operational items should dominate action dashboards.

Strategic and historical items should support review, not crowd urgent work.

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 decision_deadline

expected_outcome

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

decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

owners are missing. HeadOffice should assign decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

owner.

Possible decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

owner

lacks action

is stale

cannot be validated

Refinement Rule:

Dashboards should evolve through Kaizen, not accumulate clutter.

KPI Quality Standard

Every KPI should pass six tests.

Decision Test

Does the KPI support a real decision?

Source Test

Is the source known and trustworthy?

Definition Test

Is the metric defined consistently?

Timeliness Test

Is the data current enough for the decision?

Ownership Test

Is someone responsible for responding?

Outcome Test

Can MWMS later determine whether the response helped?

KPI Quality Rule

A KPI that fails two or more tests should not appear as an active top-level KPI.

KPI Definition Record

Every material KPI should define:

KPI Name:

Business Question:

Decision Supported:

Formula Or Logic:

Unit:

Source:

Owning Brain:

Data Owner:

Time Range:

Update Frequency:

Target:

Warning Threshold:

Critical Threshold:

Comparison Basis:

Leading Or Lagging:

Confidence:

Known Limitations:

Required Review:

Retirement Trigger:

KPI Definition Rule

Two dashboards must not use the same KPI name with different logic without explicit distinction.

Metric Hierarchy

MWMS should separate:

North Star Metrics

Top-level indicators tied to business or system success.

Decision KPIs

Indicators used for current decisions.

Diagnostic Metrics

Supporting measures used to explain why a KPI moved.

Activity Metrics

Counts of work performed.

Health Metrics

Measures of system reliability, quality, cost, risk, and operational stability.

Outcome Metrics

Measures of actual business, user, client, or system improvement.

Metric Hierarchy Rule

Activity metrics must not be presented as outcomes.

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.

11. Cost And Efficiency KPIs

Used to track whether AI, tool, model, workflow, support, and delivery costs remain justified.

Examples:

Cost Per Work Unit

Cost Per Useful Outcome

Model Cost By Agent

Tool Cost By Workflow

Human Review Time

Support Cost

Retry Cost

Cost Variance

Purpose:

To make AI and system economics visible.

12. Quality And Reliability KPIs

Used to track whether outputs and systems are trustworthy.

Examples:

Validation Pass Rate

Independent Review Pass Rate

Correction Rate

Citation Accuracy

Source Grounding Rate

Workflow Success Rate

Recovery Rate

Stale Data Rate

Purpose:

To prevent activity and speed from hiding weak quality.

13. Capacity And Load KPIs

Used to track whether Brains, AI Employees, M, or systems are overloaded.

Examples:

Open Work Units

Work Units Per Owner

Queue Age

Average Handoff Time

Review Backlog

M Capacity Exposure

Agent Concurrency

Human Approval Backlog

Purpose:

To identify bottlenecks before work fails.

14. Knowledge And Memory KPIs

Used to track knowledge quality and continuity.

Examples:

Knowledge Commitments Completed

Unresolved Knowledge Conflicts

Stale Canon References

Retrieval Success Rate

Missing Source Rate

Duplicate Knowledge Records

Session Closure Completion Rate

Purpose:

To ensure dashboards and AI Employees are operating from current, durable knowledge.

15. Client Value KPIs

Used to track whether future AIBS systems create visible business value.

Examples:

Money Captured

Money Saved

Time Saved

Leads Recovered

Appointments Booked

Revenue Influenced

Risk Reduced

Tasks Automated

Client Decisions Supported

Purpose:

To show business outcomes rather than technical activity.

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 decision_deadline

expected_outcome

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

4. Recommended Action

State what should happen next.

Example:

“Assign decision_deadline

expected_outcome

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

5. Owner

State who owns the next action.

Example:

“Owner: HeadOffice.”

6. Confidence

State how reliable the insight is.

Recommended values:

High

Medium

Low

Unknown

7. Evidence

State the source, comparison, or supporting record.

8. Decision Deadline

State when action is required where time matters.

9. Expected Outcome

State what should improve if the recommendation is followed.

Quick Insight Summary Format

What Happened:
Why It Matters:
Risk Or Opportunity:
Recommended Action:
Owner:
Confidence:
Evidence:
Decision Deadline:
Expected Outcome:

Dashboard Item Record Template

Additional v1.2 Fields

Dashboard Value Level:

Recommended values:

Visibility

Diagnostic

Action

Outcome

Metric Definition:

Calculation Rule:

Source System:

Source Record:

Source Owner:

Last Successful Update:

Freshness Status:

Data Quality Status:

Insight Method:

Recommended values:

Direct Metric

Calculated Metric

Rules-Based Alert

Rules-Based Recommendation

AI-Generated Summary

AI-Generated Diagnosis

AI-Generated Recommendation

Human Decision

Assumptions:

Missing Data:

Current Value Before Action:

Proposed Value After Action:

External Effect:

Approval State:

Approver:

Execution State:

Verification State:

External Record ID:

Rollback Path:

Client Boundary:

Project Boundary:

Action Audit Reference:

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:

Decision Supported

Field:
Decision Supported:

Decision Class

Field:
Decision Class:

Recommended values:

Act Now

Review

Approve

Reject

Escalate

Assign

Investigate

Test

Continue

Pause

Stop

Park

Monitor

Close

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:

Target

Field:
Target:

Warning Threshold

Field:
Warning Threshold:

Critical Threshold

Field:
Critical Threshold:

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

Confidence

Field:
Confidence:

Recommended values:

High

Medium

Low

Unknown

Evidence Reference

Field:
Evidence Reference:

Insight Summary

Field:
Insight Summary:

Recommended Action

Field:
Recommended Action:

Decision Deadline

Field:
Decision Deadline:

Expected Outcome

Field:
Expected Outcome:

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:

Drill-Down Destination

Field:
Drill-Down Destination:

Outcome Tracking Method

Field:
Outcome Tracking Method:

Retirement Trigger

Field:
Retirement Trigger:

Failure Conditions

Field:
Failure Conditions:

Last Reviewed

Field:
Last Reviewed:

Quick Use Version

Dashboard Item Name:
Dashboard Item Type:
Dashboard Purpose:
Decision Supported:
Decision Class:
Owning Brain:
Data Source:
KPI Or Metric:
Time Range:
Source Quality:
Current Value:
Target:
Warning Threshold:
Critical Threshold:
Comparison Value:
Trend:
Status:
Priority:
Risk Level:
Confidence:
Evidence Reference:
Insight Summary:
Recommended Action:
Decision Deadline:
Expected Outcome:
Owner:
Review Frequency:
Human Review Required:
Dashboard Destination:
Drill-Down Destination:
Outcome Tracking Method:
Retirement Trigger:
Failure Conditions:
Last Reviewed:

Role-Based Dashboard Views

Different users should not automatically receive the same dashboard.

Possible views include:

HeadOffice View

Shows enterprise priorities, major risks, approvals, bottlenecks, outcomes, capacity, cost, and cross-Brain health.

Brain Owner View

Shows local performance, queues, dependencies, decisions, failures, and outcomes.

Operator View

Shows assigned work, blockers, due actions, status, and required evidence.

M Developer View

Shows only confirmed build tasks, save points, blockers, test evidence, and protected areas.

Client View

Shows reviewed business outcomes, progress, risks, decisions, and next actions in client-safe language.

Reviewer View

Shows evidence, validation state, disagreement, risk, and approval requirements.

Role View Rule

Each user should see the minimum information needed to decide or act.

Internal technical detail should not leak into client-facing views.

AI-Generated Insight Summary Rules

AI may draft dashboard insights.

AI-generated insights must:

use current validated data

cite or preserve the source record

distinguish fact from inference

show confidence

avoid inventing causation

avoid presenting correlation as proof

avoid creating urgency without thresholds

respect current status

respect client and permission boundaries

identify missing data

state when human review is required

AI Insight Rule

AI may explain the dashboard.

It must not silently redefine the KPI, alter the source data, or approve its own high-risk recommendation.

Dashboard Drill-Down Standard

Top-level cards should link or route to the evidence behind them.

A drill-down may show:

source records

time-series trend

status breakdown

decision_deadline

expected_outcome

owner breakdown

Brain breakdown

risk breakdown

failure reasons

review notes

decision history

outcome history

Drill-Down Rule

The top-level dashboard should stay simple.

Complexity belongs in controlled drill-down views.

Dashboard Alert Standard

An alert should fire only when a defined threshold, failure condition, deadline, or authority rule is met.

Every alert should define:

alert name

trigger

severity

decision_deadline

expected_outcome

owner

notification route

required response

deadline

dismissal rule

escalation rule

closure condition

Alert Rule

Repeated alerts with no action create alert fatigue and should be refined or retired.

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, decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

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, decision_deadline

expected_outcome

ownerless, or stale.

Owning Brain:
HeadOffice Brain

Data Source:
Routed Actions records.

KPI Or Metric:
Open, blocked, decision_deadline

expected_outcome

ownerless, overdue, and completed actions.

Time Range:
This Week

Source Quality:
Usable if decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

ownerless items exist.

Risk Level:
Medium to High

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

Recommended Action:
Assign decision_deadline

expected_outcome

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 decision_deadline

expected_outcome

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:
AIBS 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

Dashboard Decision And Outcome Loop

Every material dashboard recommendation should be traceable through:

Signal

KPI

Insight

Decision

Owner

Action

Outcome

Learning

Dashboard Outcome Record

Decision ID:

Dashboard Item:

Decision Class:

Decision:

Owner:

Action Taken:

Date:

Expected Outcome:

Actual Outcome:

Result:

Useful / Partial / Weak / Harmful / Unknown

Learning:

KPI Or Threshold Change Required:

Next Review:

Outcome Loop Rule

MWMS should not keep generating recommendations without measuring whether prior dashboard-driven actions helped.

Dashboard Cost And Usage Review

A dashboard should be reviewed for:

build cost

maintenance cost

data cost

AI summary cost

human review cost

support burden

usage frequency

decision value

client value

Cost And Usage Rule

A dashboard that is expensive, rarely used, and produces no material decisions should be simplified, merged, parked, or retired.

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 decision class defined?

Is the KPI definition consistent?

Is the KPI leading, lagging, diagnostic, activity, health, or outcome?

Is the time range defined?

Is the current value available?

Is target defined where needed?

Are warning and critical thresholds defined where needed?

Is comparison value available where needed?

Is the trend clear?

Is status clear?

Is priority assigned?

Is risk level assigned?

Is confidence stated?

Is supporting evidence visible?

Is the insight summary meaningful?

Is recommended action specific?

Is a decision deadline defined where needed?

Is expected outcome defined?

Is decision_deadline

expected_outcome

owner assigned where needed?

Is review frequency appropriate?

Is human review required where needed?

Is destination clear?

Is drill-down available where needed?

Is outcome tracking defined?

Is retirement trigger defined?

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.

Action Dashboard Readiness Addendum

Before an Action Dashboard is approved, confirm:

dashboard value level is declared

metric definitions are approved

calculation rules are documented

source system is known

source owner is known

freshness state is visible

data quality state is visible

client boundary is enforced

role-based permissions are tested

read permission is separated from write permission

recommendation is separated from approval

write permission is separated from execution permission

high-impact confirmation is visible

old and new values are displayed

destination is confirmed

external effect is disclosed

tool failure handling exists

downstream success is verified

external record ID is retained where available

action audit record is created

rollback path exists where required

AI-generated insights are labelled

assumptions are visible

missing data is visible

universal benchmarks are not treated as facts

outcome tracking is connected

Additional Action Dashboard Failure Modes

Failure Mode: Decorative Dashboard

The dashboard looks impressive but supports no clear decision or action.

Correction:

Define the decision, owner, next action and outcome loop.

Failure Mode: Lowest Percentage Is Treated As The Main Constraint

The system chooses the smallest conversion rate without considering economic value, controllability or data quality.

Correction:

Apply the Constraint Identification Standard.

Failure Mode: Dashboard Becomes A Competing Source Of Truth

Values are edited or calculated in the interface without governed definitions or source records.

Correction:

Keep the dashboard as a controlled view over approved source systems.

Failure Mode: Stale Data Appears Current

The dashboard does not show refresh status or last successful update.

Correction:

Display freshness state, update time and stale warnings.

Failure Mode: Read Access Grants Write Authority

An agent that can inspect records can also change them.

Correction:

Separate read, recommend, approve, write, execute and verify permissions.

Failure Mode: Proposed Change Is Hidden

A user approves an action without seeing the old value, new value or external effect.

Correction:

Display the full Action Confirmation Standard.

Failure Mode: AI Claims External Success

The interface says an email was sent, appointment was booked or record was updated based only on model output.

Correction:

Verify the downstream tool result and store the external record ID where available.

Failure Mode: Record Modification Is Mistaken For Approval

Any updated timestamp triggers an external action.

Correction:

Use a dedicated approval state and approval event.

Failure Mode: Client Data Crosses Boundaries

A reusable dashboard retrieves or changes another client’s data.

Correction:

Enforce tenant isolation and test client-boundary failure cases.

Failure Mode: Public Link Acts As Authentication

A shared URL or visible code is treated as sufficient protection.

Correction:

Use proper identity, session and permission controls.

Failure Mode: AI Recommendation Appears As Fact

An inferred diagnosis is displayed without label, assumptions or confidence.

Correction:

Label the insight method and show evidence and uncertainty.

Failure Mode: Universal Benchmark Applied Blindly

A sample conversion target is treated as correct for every business.

Correction:

Validate benchmarks against the specific market, process and data.

Failure Mode: Action Has No Outcome Link

The dashboard triggers activity but does not measure whether it helped.

Correction:

Connect every material action to an expected outcome and review date.

Failure Mode: Rollback Is Impossible

A harmful record change or action cannot be reversed or contained.

Correction:

Define rollback, recovery and human escalation before execution.

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.

Dashboard shows activity as value.

KPI definition changes between reports.

Thresholds are undefined.

AI-generated insight invents causation.

Confidence is hidden.

Alert fires repeatedly without decision_deadline

expected_outcome

owner or closure.

Client dashboard exposes internal detail.

Dashboard has no drill-down evidence.

Dashboard-driven actions are never measured.

Dashboard cost exceeds decision value.

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 decision_deadline

expected_outcome

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

which thresholds are meaningful

which alerts create action

which AI-generated insights require correction

which role views reduce confusion

which drill-downs are actually used

which dashboard decisions produce outcomes

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

decision_supported

decision_class

owning_brain

data_source

kpi_or_metric

time_range

source_quality

current_value

target

warning_threshold

critical_threshold

comparison_value

trend

status

priority

risk_level

confidence

evidence_reference

insight_summary

recommended_action

decision_deadline

expected_outcome

owner

review_frequency

human_review_required

dashboard_destination

drill_down_destination

outcome_tracking_method

retirement_trigger

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 decision_deadline

expected_outcome

owner and next action where needed

ensuring risk is visible

ensuring dashboards support decisions

ensuring KPI definitions remain consistent

ensuring thresholds are justified

ensuring AI-generated insights are grounded

ensuring role-based views protect access and clarity

ensuring alerts have owners and closure conditions

ensuring dashboard decisions are linked to outcomes

ensuring dashboard cost remains justified

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

AIBS 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 decision_deadline

expected_outcome

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

Using activity metrics as outcomes

Allowing AI to invent causation

Changing KPI formulas without notice

Using thresholds with no evidence

Creating alerts without closure conditions

Showing every user the same dashboard

Hiding confidence or missing evidence

Failing to measure dashboard-driven outcomes

Maintaining dashboards whose cost exceeds their value

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?

What decision class does it support?

What threshold changed?

How confident is the insight?

What evidence supports it?

Who must act and by when?

What outcome should follow?

Did the previous action work?

Is this dashboard still worth maintaining?

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

Change Log

Version: v1.2
Date: 2026-06-21
Author: HeadOffice

Change:

Updated the MWMS KPI Dashboard And Insight Summary Framework using the AI Automations by Jack actionable dashboard block covering live KPI displays, funnel-stage conversion visibility, conversational data inspection, governed record updates, email and calendar actions, client-facing AI dashboards and outcome-focused decision support.

Preserved the existing v1.1 decision-dashboard, KPI-quality, metric-hierarchy, evidence, confidence, alerts, drill-down, role-based view, cost, outcome and AI-generated insight architecture.

Added:

Dashboard Value Levels

Dashboard Value Progression

Funnel And Constraint Dashboard Model

Constraint Identification Standard

Economic Value Prioritisation

Metric Source Of Truth Standard

Metric Freshness Standard

Read Recommend Approve Write Execute Separation

Action Confirmation Standard

Downstream Tool Success Verification

Dashboard Action Audit Record

Client And Tenant Isolation Standard

Rules-Based And AI-Generated Insight Labels

Recommendation Evidence Standard

Universal Benchmark Prohibition

Additional v1.2 Dashboard Item Record fields

Action Dashboard Readiness Addendum

additional Action Dashboard failure modes

Purpose of update:

To evolve the framework from decision-ready reporting into a governed visibility, diagnosis, action and outcome dashboard system that can safely display evidence, identify constraints, propose actions, request approval, execute authorised changes, verify downstream success and measure the resulting business outcome.

Version: v1.1
Date: 2026-06-20
Author: HeadOffice

Change

Updated the MWMS KPI Dashboard And Insight Summary Framework using the AI Automations by Jack block covering CEO systems, AI dashboards, Claude Agent Teams, NotebookLM, persistent knowledge, outcome visibility, cost visibility, multi-agent orchestration and business operating dashboards.

Added:

MWMS Decision Dashboard Operating Model

Dashboard Decision Classes

Dashboard Time Horizons

KPI Quality Standard

KPI Definition Record

Metric Hierarchy

Cost And Efficiency KPIs

Quality And Reliability KPIs

Capacity And Load KPIs

Knowledge And Memory KPIs

Client Value KPIs

Role-Based Dashboard Views

AI-Generated Insight Summary Rules

Dashboard Drill-Down Standard

Dashboard Alert Standard

Dashboard Decision And Outcome Loop

Dashboard Outcome Record

Dashboard Cost And Usage Review

Expanded:

Insight Summary Structure

Dashboard Item Record Template

Quick Use Version

KPI Dashboard Readiness Checklist

Common KPI Dashboard Failure Modes

Manual Use Rule

Future Plugin Or UI Relevance

Governance Role

Drift Protection

Architectural Intent

Change Impact Declaration

This v1.2 update strengthens the existing framework without changing its owner, parent page, authority level, or decision-first dashboard purpose.

Pages Created

None

Pages Updated

MWMS KPI Dashboard And Insight Summary Framework

Pages Deprecated

None

Standalone Pages Not Created

MWMS Dashboard Value Level Standard

MWMS Funnel And Constraint Dashboard Model

MWMS Constraint Identification Standard

MWMS Metric Source Of Truth Standard

MWMS Metric Freshness Standard

MWMS Dashboard Permission Separation Standard

MWMS Dashboard Action Confirmation Standard

MWMS Dashboard Tool Success Verification Standard

MWMS Dashboard Action Audit Record

MWMS Client Dashboard Isolation Standard

MWMS AI Dashboard Recommendation Evidence Standard

These concepts were absorbed into the unified MWMS KPI Dashboard And Insight Summary Framework rather than created as separate pages.

Registries Requiring Update

None confirmed by the supplied source.

Canon Version Update Required

No

Change Log Entry Required

Yes

Employee Impact Check

Employees impacted:

HeadOffice Dashboard Analyst

KPI Review Agent

Insight Summary Agent

Operational Decision Agent

Outcome Logger Agent

Failure Handler Agent

AIBS Client Dashboard Architect

Finance Review Agent

Data Quality Agent

Permission Gatekeeper Agent

Required behaviour updates:

AI Employees must identify whether a dashboard is visibility, diagnostic, action or outcome level.

AI Employees must not identify the lowest conversion percentage as the primary constraint without considering economic value, controllability, sample size, data quality, effort and downstream impact.

AI Employees must preserve metric definitions, calculation rules, sources, freshness and confidence.

AI Employees must separate read, interpret, recommend, approve, write, execute and verify authority.

AI Employees must display proposed changes, old values, new values, destination and external effect before high-impact approval.

AI Employees must verify downstream tool success before reporting that an external action completed.

AI Employees must preserve client and project boundaries.

AI Employees must label rules-based, AI-generated and human-decided insights correctly.

AI Employees must show assumptions, missing data, evidence and uncertainty behind recommendations.

AI Employees must not treat course examples or generic conversion targets as universal MWMS benchmarks.

AI Employees must connect material actions to expected outcomes and later review.

Strategic Absorption Result

MWMS gains a stronger dashboard operating system that moves from governed visibility through diagnosis, recommendation, approval, action, verification and outcome learning while protecting source truth, permissions, client isolation, data freshness and human decision authority.

END OF FULL FILE OUTPUT