MWMS MCR

MWMS Operational Decision Intelligence Framework

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, Opportunity System, Newsletter Intelligence, Routed Actions, 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 Operational Decision Intelligence Framework.

This framework explains how MWMS makes repeatable operational decisions across the ecosystem.

MWMS will face many recurring decisions every day and every week.

Examples:

  • absorb this course lesson or ignore it
  • create a new MCR page or update an existing page
  • route a newsletter signal or reject it
  • classify an item as ACT NOW, TEST, MONITOR, PARK, or REJECT
  • move an offer to Research Brain or Finance Brain
  • approve a small test or hold for more evidence
  • send a developer task to M or stop because evidence is missing
  • allow a tool action or block it
  • automate a workflow or keep it manual
  • escalate a failure or contain it locally
  • continue, pause, stop, or revise a workflow

These decisions must not be random.

The purpose of operational decision intelligence is to help MWMS make decisions that are:

  • structured
  • repeatable
  • evidence-aware
  • risk-aware
  • owner-aware
  • context-aware
  • outcome-focused
  • safe to route
  • easy to review
  • easy to improve

This framework turns daily operational choices into a controlled HeadOffice decision layer.

Scope

This framework applies to recurring operational decisions across MWMS.

This includes decisions inside:

  • HeadOffice Brain
  • Brain Room
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Newsletter Intelligence
  • Course Absorption
  • Opportunity System
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Ads Brain
  • Content Brain
  • Operations Brain
  • AI Business Systems Brain
  • Dev Console
  • M developer handoff workflow
  • MCR page management
  • future AIBS client systems

This framework applies to operational decisions involving:

  • routing
  • prioritization
  • validation
  • escalation
  • parking
  • rejection
  • workflow continuation
  • workflow stoppage
  • tool permission
  • automation readiness
  • developer handoff
  • reporting
  • offer evaluation
  • testing
  • finance exposure
  • client review

This framework does not authorize paid traffic action, financial commitment, live system change, client delivery, automation, or developer implementation by itself.

It defines how operational decisions should be made before action is taken.

Core Definition

Operational Decision Intelligence is the structured process of turning evidence, context, risk, options, and business meaning into a clear operational decision.

An operational decision answers:

  • What is being decided?
  • Why is the decision needed?
  • What evidence supports it?
  • What context matters?
  • What options are available?
  • What risk exists?
  • What decision should be made?
  • Who owns the next action?
  • What happens if the decision is wrong?
  • What should be logged or reviewed?

Operational decisions are not strategic vision statements.

They are the practical decisions that keep MWMS moving safely.

Core Principle

The core principle of this framework is:

Operational decisions must be structured enough to repeat and conservative enough to protect the system.

MWMS should not treat every decision as a fresh debate.

Recurring decisions should use known decision patterns, thresholds, routing rules, validation gates, and review requirements.

This creates:

  • less confusion
  • fewer duplicate pages
  • safer developer handoffs
  • better routing
  • better HeadOffice visibility
  • stronger Finance control
  • cleaner experimentation
  • better AI Employee accountability
  • safer future client systems

Operational Decision Workflow

The MWMS Operational Decision Workflow has ten stages:

  1. Define The Decision
  2. Identify Decision Type
  3. Gather Evidence
  4. Check Context
  5. Assess Risk
  6. Identify Options
  7. Apply Decision Rule
  8. Assign Owner And Next Action
  9. Validate Or Escalate
  10. Log Outcome And Review

1. Define The Decision

Every operational decision must clearly state what is being decided.

Examples:

  • Should this course lesson be absorbed?
  • Should this page be created or updated?
  • Should this newsletter signal become an action?
  • Should this offer move to Research Brain?
  • Should this campaign be scaled?
  • Should this tool action be allowed?
  • Should this task go to M?
  • Should this workflow be automated?
  • Should this failure be escalated?
  • Should this report become recurring?

Decision Definition Rule:

If the decision is unclear, the output will drift.

The first step is always to define the decision.

2. Identify Decision Type

MWMS should classify the decision type.

Decision types include:

  • Absorb / Ignore Decision
  • Create / Update / Replace Decision
  • Route / Park / Reject Decision
  • ACT NOW / TEST / MONITOR Decision
  • Approve / Block / Downgrade Decision
  • Continue / Pause / Stop Decision
  • Manual / Automate Decision
  • Escalate / Contain Decision
  • Send To M / Hold Decision
  • Research / Finance / Experimentation Handoff Decision
  • Schedule / Keep Manual / Retire Decision
  • Client Draft / Client Review / Client Delivery Decision

Decision Type Rule:

Decision type determines which rule, Brain, validation level, and approval gate applies.

3. Gather Evidence

Operational decisions must be based on evidence.

Evidence may include:

  • source material
  • user instruction
  • uploaded course file
  • newsletter body
  • offer page
  • research notes
  • finance assumptions
  • experiment result
  • campaign data
  • screenshot
  • current file content
  • WordPress page list
  • Supabase row
  • AI output
  • validation report
  • failure log
  • outcome log
  • current save point
  • human confirmation

Evidence Rule:

No meaningful operational decision should be made from vibe alone.

If evidence is missing, the decision should be downgraded, parked, clarified, or escalated.

4. Check Context

The decision must use the correct context.

Context may include:

  • owning Brain
  • supporting Brains
  • current workflow stage
  • current save point
  • source of truth
  • relevant standards
  • current page registry
  • M’s active build boundary
  • tool permission boundary
  • risk level
  • human review rule
  • output destination
  • previous decision status
  • future client safety boundary

Context Rule:

Current evidence beats old memory.

Operational decisions must not rely on stale, polluted, or missing context.

5. Assess Risk

Operational decisions must assign risk level.

Risk levels:

  • Low
  • Medium
  • High
  • Critical

Risk factors include:

  • MCR source of truth impact
  • developer impact
  • live system impact
  • money or ad spend impact
  • finance exposure
  • compliance risk
  • public content risk
  • client trust risk
  • tool write access
  • automation risk
  • uncertain source quality
  • missing evidence

Risk Rule:

Risk level determines how much validation and human review is required.

High-risk decisions must not move forward casually.

6. Identify Options

A decision should include clear options.

Examples:

For course absorption:

  • Create new page
  • Update existing page
  • Park
  • Ignore
  • Reject

For newsletter signals:

  • ACT NOW
  • TEST
  • MONITOR
  • PARK
  • REJECT

For developer work:

  • Send to M
  • Request more evidence
  • Draft only
  • Park
  • Escalate

For tool actions:

  • Allow
  • Allow read-only
  • Allow draft-only
  • Require validation
  • Require human review
  • Block

For workflow readiness:

  • Manual only
  • Assisted use
  • Controlled automation candidate
  • Park
  • Retire

Options Rule:

If options are not visible, the decision becomes hidden judgment.

MWMS should make options explicit.

7. Apply Decision Rule

Each decision type should use a known decision rule.

Examples:

Course Absorption Rule

Create or update only if the material adds clear MWMS system value.

Otherwise park, ignore, or reject.

MCR Page Rule

If page exists, update or replace it.

Do not create duplicate pages.

Newsletter Signal Rule

Only route signals that are specific, business-relevant, and action-worthy.

Generic news is monitored, parked, or rejected.

Offer Evaluation Rule

No offer moves toward spend without Research and Finance review.

Developer Handoff Rule

If M would need to guess, stop.

Tool Permission Rule

AI Employees may request actions, but permission must be checked independently.

Automation Rule

Manual proof comes before automation.

Client Rule

No client-facing delivery without human approval.

Decision Rule Principle:

The rule should make the decision easier, safer, and more repeatable.

8. Assign Owner And Next Action

Every operational decision needs an owner and a next action.

Possible owners:

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

Next actions may include:

  • create page
  • replace page
  • update registry
  • route to Brain
  • request evidence
  • prepare handoff
  • validate output
  • park
  • reject
  • escalate
  • run small test
  • stop workflow
  • log outcome
  • log failure

Owner Rule:

A decision without an owner becomes operational noise.

9. Validate Or Escalate

Before a decision becomes action, it may need validation or escalation.

Validation is required when:

  • source quality is weak
  • risk is medium or higher
  • output affects MCR
  • output affects M
  • output affects money
  • output affects public content
  • output affects client work
  • tool action is requested
  • automation is proposed

Escalation is required when:

  • decision authority is unclear
  • risk is high
  • evidence is missing
  • action may affect M’s active build
  • finance exposure exists
  • compliance concern exists
  • client safety is involved
  • human approval is required

Validation Rule:

Decisions should move forward only after the right level of validation.

10. Log Outcome And Review

Important operational decisions should be logged.

Logging may include:

  • decision made
  • decision type
  • source
  • owner
  • next action
  • risk level
  • validation result
  • outcome
  • failure
  • learning
  • date reviewed

The purpose of logging is not admin clutter.

The purpose is to improve future decision quality.

Review questions:

  • Was the decision correct?
  • Did it create value?
  • Did it prevent risk?
  • Did it route work properly?
  • Did it create unnecessary work?
  • Should the rule be improved?
  • Should the decision pattern become automated later?

Logging Rule:

Decisions should teach the system.

Operational Decision Types

1. ACT NOW / TEST / MONITOR / PARK / REJECT Decision

Used for:

  • newsletter signals
  • market signals
  • platform changes
  • opportunity signals
  • tool updates
  • compliance alerts
  • campaign insights

Definitions:

ACT NOW

Immediate action is justified.

Use only when:

  • signal is specific
  • impact is important
  • action is clear
  • owner is known
  • risk is acceptable or urgent

TEST

Small controlled test is justified.

Use when:

  • opportunity exists
  • evidence is partial
  • risk can be controlled
  • result can be measured

MONITOR

Watch but do not act yet.

Use when:

  • signal may matter
  • evidence is not strong enough
  • timing is not urgent
  • more confirmation is needed

PARK

Save for later.

Use when:

  • idea may be useful
  • current priority is low
  • evidence incomplete
  • workflow not ready

REJECT

Do not use.

Use when:

  • signal is weak
  • duplicate
  • irrelevant
  • unsafe
  • non-actionable
  • not useful to MWMS

Rule:

ACT NOW should be rare. TEST and MONITOR should be disciplined. PARK and REJECT protect focus.

2. Create / Update / Replace / Ignore Decision

Used for:

  • MCR pages
  • course absorption
  • framework creation
  • registry updates
  • page cleanup

Definitions:

Create

Use when no equivalent page exists and the material adds clear new system value.

Update

Use when an existing page already covers the area but needs improvement.

Replace

Use when the existing page should be overwritten with a full updated version.

Ignore

Use when the content does not improve MWMS.

Rule:

Do not create when update or replace is the correct action.

3. Route / Hold / Escalate Decision

Used for:

  • Brain-to-Brain handoffs
  • workflow movement
  • task assignment
  • Queue Review
  • Brain Room requests

Definitions:

Route

Send to the correct Brain, role, queue, or owner.

Hold

Do not move yet because evidence or context is missing.

Escalate

Move to HeadOffice, Martyn, M, Finance, Compliance, or Human Review because risk or authority requires it.

Rule:

Routing without enough context creates downstream failure.

4. Approve / Block / Downgrade Decision

Used for:

  • permission gatekeeping
  • tool actions
  • automation actions
  • external actions
  • dashboard actions
  • MCR actions
  • client actions

Definitions:

Approve

Action is allowed within current permission and risk boundary.

Block

Action is not allowed.

Downgrade

A lower-risk action is allowed instead.

Examples:

  • write becomes draft
  • publish becomes review candidate
  • send becomes draft reply
  • automation becomes manual proof
  • M handoff becomes evidence request

Rule:

Downgrade is often safer than full approval or total rejection.

5. Continue / Pause / Stop Decision

Used for:

  • workflows
  • campaigns
  • experiments
  • automation
  • development tasks
  • course absorption blocks
  • recurring reports

Definitions:

Continue

Current workflow remains useful and safe.

Pause

Workflow should temporarily stop until evidence, review, or context is available.

Stop

Workflow should end because it is unsafe, weak, duplicated, or not useful.

Rule:

Pausing is a decision, not a failure.

6. Manual / Assisted / Automated Decision

Used for:

  • workflow maturity
  • command triggers
  • recurring reports
  • Brain Room tasks
  • tool chains
  • AI Employee workflows

Definitions:

Manual

Human-driven workflow only.

Assisted

AI helps draft, classify, summarize, or prepare records, but human review controls action.

Automated

Workflow can run controlled steps with logging, validation, stop conditions, and approved permission.

Rule:

Automation must never exceed manual proof.

7. Send To M / Hold For Evidence Decision

Used for:

  • developer tasks
  • WordPress changes
  • Supabase changes
  • plugin changes
  • UI changes
  • Dev Console tasks

Definitions:

Send To M

Only when task is exact enough for M to act safely.

Hold For Evidence

Use when file path, screenshot, current state, test steps, or risk boundary is missing.

Rule:

If M would need to guess, hold.

8. Research / Finance / Experimentation Decision

Used for:

  • offer evaluation
  • campaign planning
  • opportunity routing
  • testing readiness

Definitions:

Research

Use when evidence needs verification.

Finance

Use when money, payout, cost, exposure, or break-even matters.

Experimentation

Use when a test design, hypothesis, or success metric is needed.

Rule:

No offer should move toward spend without Research and Finance clarity.

9. Schedule / Keep Manual / Retire Decision

Used for:

  • recurring reports
  • weekly digests
  • scheduled automation
  • monitoring workflows

Definitions:

Schedule

Use only when manual report has proven value.

Keep Manual

Use when the report is useful but not ready for automation.

Retire

Use when the report creates noise, duplication, or no outcome.

Rule:

Recurring work must earn its place.

10. Client Draft / Client Review / Client Delivery Decision

Used for future AIBS client reporting.

Definitions:

Client Draft

AI may draft internal version only.

Client Review

Human/client approval workflow is required.

Client Delivery

Only after approved source, validation, and human review.

Rule:

Client delivery is never the default.

Operational Decision Record Template

Use this template when recording an important operational decision.

Decision Title

Field:
Decision Title:

Decision Date

Field:
Decision Date:

Decision Type

Field:
Decision Type:

Recommended values:

  • ACT NOW / TEST / MONITOR / PARK / REJECT
  • Create / Update / Replace / Ignore
  • Route / Hold / Escalate
  • Approve / Block / Downgrade
  • Continue / Pause / Stop
  • Manual / Assisted / Automated
  • Send To M / Hold For Evidence
  • Research / Finance / Experimentation
  • Schedule / Keep Manual / Retire
  • Client Draft / Client Review / Client Delivery

Decision Question

Field:
Decision Question:

Owning Brain

Field:
Owning Brain:

Supporting Brains

Field:
Supporting Brains:

Source Material

Field:
Source Material:

Source Quality

Field:
Source Quality:

Recommended values:

  • Strong
  • Usable
  • Partial
  • Weak
  • Conflicting
  • Unverified
  • Stale
  • Unknown

Context Used

Field:
Context Used:

Evidence Summary

Field:
Evidence Summary:

Assumptions

Field:
Assumptions:

Options Considered

Field:
Options Considered:

Risk Level

Field:
Risk Level:

Recommended values:

  • Low
  • Medium
  • High
  • Critical

Decision Made

Field:
Decision Made:

Decision Reason

Field:
Decision Reason:

Confidence Level

Field:
Confidence Level:

Recommended values:

  • High
  • Medium
  • Low
  • Unknown

Human Review Required

Field:
Human Review Required: Yes / No

Validation Required

Field:
Validation Required: Yes / No

Owner Of Next Action

Field:
Owner Of Next Action:

Next Action

Field:
Next Action:

Handoff Destination

Field:
Handoff Destination:

Logging Required

Field:
Logging Required: Yes / No

Review Trigger

Field:
Review Trigger:

Expected Outcome

Field:
Expected Outcome:

Decision Status

Field:
Decision Status:

Recommended values:

  • Draft
  • Ready For Review
  • Approved
  • Routed
  • Parked
  • Rejected
  • Escalated
  • Completed
  • Reversed
  • Retired

Quick Use Version

Decision Title:
Decision Date:
Decision Type:
Decision Question:
Owning Brain:
Supporting Brains:
Source Material:
Source Quality:
Context Used:
Evidence Summary:
Assumptions:
Options Considered:
Risk Level:
Decision Made:
Decision Reason:
Confidence Level:
Human Review Required:
Validation Required:
Owner Of Next Action:
Next Action:
Handoff Destination:
Logging Required:
Review Trigger:
Expected Outcome:
Decision Status:

Examples

Example 1: Course Absorption Decision

Decision Title:
Course Lesson Absorption Decision

Decision Type:
Create / Update / Replace / Ignore

Decision Question:
Should this course lesson become new MCR structure, update existing structure, or be ignored?

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, relevant specialist Brain.

Source Material:
Course transcript or lesson block.

Source Quality:
Usable / Mostly Complete.

Context Used:
Course Absorption System v2, MCR source-of-truth rule, duplicate risk rules.

Evidence Summary:
Lesson provides a reusable framework or operational rule.

Assumptions:
Existing page search must be confirmed before saving.

Options Considered:
Create, update, replace, park, ignore, reject.

Risk Level:
Medium

Decision Made:
Create or update only if non-duplicative system value exists.

Decision Reason:
MWMS should absorb only material that improves the Brain or Blueprint.

Confidence Level:
Medium to High depending on source and duplicate status.

Human Review Required:
Yes before MCR save.

Validation Required:
Yes.

Owner Of Next Action:
Martyn

Next Action:
Create full page output or update existing page.

Handoff Destination:
MCR / Page Registry / Parking System.

Logging Required:
Yes if absorbed.

Review Trigger:
If duplicate page is found or later material overlaps.

Expected Outcome:
MWMS gains useful structure without creating clutter.

Decision Status:
Ready For Review

Example 2: Newsletter Signal Decision

Decision Title:
Newsletter Signal Routing Decision

Decision Type:
ACT NOW / TEST / MONITOR / PARK / REJECT

Decision Question:
Should this newsletter signal become action, test, monitor item, parked insight, or rejection?

Owning Brain:
HeadOffice Brain

Supporting Brains:
Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain.

Source Material:
Newsletter source and extracted insight.

Source Quality:
Usable if source is complete; partial if body is truncated.

Context Used:
Newsletter Intelligence Operating Protocol, Brain Routing Rule, HeadOffice Dashboard readiness.

Evidence Summary:
Signal may affect a platform, market, tool, compliance risk, or opportunity.

Assumptions:
Recent signals may need verification before action.

Options Considered:
ACT NOW, TEST, MONITOR, PARK, REJECT.

Risk Level:
Medium

Decision Made:
MONITOR or TEST unless evidence supports urgency.

Decision Reason:
Avoid turning newsletter noise into operational distraction.

Confidence Level:
Medium

Human Review Required:
Yes before downstream action.

Validation Required:
Yes.

Owner Of Next Action:
HeadOffice

Next Action:
Route to Queue Review, Research Brain, or Parking System.

Handoff Destination:
Newsletter Queue Review / Routed Actions / Parking System.

Logging Required:
Yes.

Review Trigger:
Same signal repeats across trusted sources or official verification appears.

Expected Outcome:
Useful intelligence is captured and noise is rejected.

Decision Status:
Ready For Review

Example 3: Developer Handoff Decision

Decision Title:
Send To M Or Hold For Evidence Decision

Decision Type:
Send To M / Hold For Evidence

Decision Question:
Is this developer task safe to send to M?

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain, Dev Console, relevant technical system.

Source Material:
Screenshot, file content, user request, current save point.

Source Quality:
Strong only if current evidence and file path are confirmed.

Context Used:
Developer Handoff Precision Skill, Exchange Zone Framework, Ambiguity Containment Framework.

Evidence Summary:
Task may require M to change a file or system.

Assumptions:
Hidden file state cannot be assumed.

Options Considered:
Send to M, request evidence, draft only, park, escalate.

Risk Level:
High

Decision Made:
Hold unless M can act without guessing.

Decision Reason:
Vague developer handoffs create build risk.

Confidence Level:
Depends on current evidence.

Human Review Required:
Always.

Validation Required:
Yes, High Risk Validation.

Owner Of Next Action:
Martyn / M / HeadOffice

Next Action:
Confirm file path and test steps, then prepare handoff.

Handoff Destination:
M / Dev Console / Brain Room.

Logging Required:
Yes for meaningful dev work.

Review Trigger:
New screenshot, file content, or M update appears.

Expected Outcome:
M receives safe, exact instructions or the task is paused.

Decision Status:
Waiting For Evidence if incomplete.

Example 4: Offer Routing Decision

Decision Title:
Offer Evaluation Routing Decision

Decision Type:
Research / Finance / Experimentation

Decision Question:
Where should this offer go next?

Owning Brain:
Affiliate Brain

Supporting Brains:
Research Brain, Finance Brain, Experimentation Brain, Ads Brain, HeadOffice Brain.

Source Material:
Offer page, affiliate network data, user-provided details.

Source Quality:
Partial until payout, proof, traffic costs, and compliance risk are verified.

Context Used:
Affiliate Product Intelligence Protocol, Finance review rule, Experimentation Brain test readiness.

Evidence Summary:
Offer may be interesting but requires verification.

Assumptions:
Vendor claims are not proof.

Options Considered:
Research, Finance, Experimentation, park, reject.

Risk Level:
High

Decision Made:
Route to Research Brain first, then Finance Brain if viable.

Decision Reason:
No offer should move toward spend without evidence and financial review.

Confidence Level:
Medium

Human Review Required:
Yes before spend.

Validation Required:
Yes.

Owner Of Next Action:
Research Brain

Next Action:
Verify offer claims, market, payout, proof, and traffic fit.

Handoff Destination:
Research Brain / Finance Brain / Parking System.

Logging Required:
Yes.

Review Trigger:
Research evidence completed or finance data becomes available.

Expected Outcome:
Weak offers are rejected early; promising offers move through controlled review.

Decision Status:
Routed

Example 5: Automation Readiness Decision

Decision Title:
Manual Or Automation Decision For Newsletter Digest

Decision Type:
Manual / Assisted / Automated

Decision Question:
Is this newsletter digest workflow ready to be scheduled or automated?

Owning Brain:
HeadOffice Brain

Supporting Brains:
Newsletter Intelligence, AI Manager, Operations Brain.

Source Material:
Manual digest outputs, queue records, failure logs, validation results.

Source Quality:
Usable if repeated manual runs exist.

Context Used:
AI Command And Trigger Framework, Recurring Intelligence And Reporting Pipeline Framework, Deployment Readiness Review Template.

Evidence Summary:
Manual reports may be useful, but recurring automation requires proof and monitoring.

Assumptions:
Successful generation does not prove report usefulness.

Options Considered:
Manual, assisted, scheduled candidate, controlled automation, park.

Risk Level:
Medium

Decision Made:
Keep manual until repeated usefulness is proven.

Decision Reason:
Scheduled weak reports become recurring noise.

Confidence Level:
Medium

Human Review Required:
Yes before scheduling.

Validation Required:
Yes.

Owner Of Next Action:
HeadOffice

Next Action:
Run several manual reports and review outcome value.

Handoff Destination:
HeadOffice Review / Report Registry.

Logging Required:
Yes.

Review Trigger:
After three useful manual runs.

Expected Outcome:
Only useful reports become scheduled.

Decision Status:
Manual Use

Decision Readiness Checklist

Before accepting an operational decision, check:

  1. Is the decision question clear?
  2. Is decision type identified?
  3. Is owning Brain clear?
  4. Are supporting Brains listed where relevant?
  5. Is source material available?
  6. Is source quality assessed?
  7. Is context current?
  8. Is evidence summarized?
  9. Are assumptions marked?
  10. Are options considered?
  11. Is risk level assigned?
  12. Is decision made explicit?
  13. Is decision reason clear?
  14. Is confidence level assigned?
  15. Is human review required?
  16. Is validation required?
  17. Is owner of next action assigned?
  18. Is next action clear?
  19. Is handoff destination defined?
  20. Is logging required?
  21. Is review trigger defined?
  22. Is expected outcome stated?
  23. Would this decision reduce uncertainty?
  24. Would this decision protect MWMS?
  25. Would this decision create useful action or learning?

If several answers are unclear, the decision is not ready.

Common Operational Decision Failure Modes

Operational decision intelligence has failed if:

  1. Decision question is vague.
  2. Decision is hidden inside a long explanation.
  3. Source quality is not checked.
  4. Assumptions are not marked.
  5. Options are not visible.
  6. Risk is ignored.
  7. Recommendation has no owner.
  8. Next action is missing.
  9. Human review is skipped.
  10. Validation is skipped.
  11. M receives work that requires guessing.
  12. MCR pages are created instead of updating existing pages.
  13. Newsletter noise becomes an action.
  14. Offers move toward spend without Finance review.
  15. Automation is approved before manual proof.
  16. Client output moves forward without approval.
  17. Decision is not logged.
  18. Decision creates activity but no outcome.

Manual Use Rule

Operational decisions should be manually proven before they become automated or turned into UI rules.

Manual use helps MWMS learn:

  • which decisions repeat
  • which decision rules work
  • which options are useful
  • where HeadOffice should intervene
  • which Brains should own which decisions
  • where AI Employees overstep
  • where validation is needed
  • which decisions may later become dashboard buttons
  • which decisions should remain human-owned
  • which decision records may become Supabase fields

Manual decision discipline comes before automation.

Future Plugin Or UI Relevance

This framework may later support:

  • Operational Decision Registry
  • HeadOffice decision dashboard
  • Routed Actions decision panel
  • Newsletter Queue decision buttons
  • Offer Evaluation decision workflow
  • AI Manager decision layer
  • Task Executor decision states
  • Permission Gatekeeper decision logs
  • M developer handoff decision gate
  • Recurring report decision review
  • AIBS client decision review workflow

Possible future fields:

  • decision_id
  • decision_title
  • decision_date
  • decision_type
  • decision_question
  • owning_brain
  • supporting_brains
  • source_material
  • source_quality
  • context_used
  • evidence_summary
  • assumptions
  • options_considered
  • risk_level
  • decision_made
  • decision_reason
  • confidence_level
  • human_review_required
  • validation_required
  • owner_next_action
  • next_action
  • handoff_destination
  • logging_required
  • review_trigger
  • expected_outcome
  • decision_status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS Operational Decision Intelligence Framework.

HeadOffice is responsible for:

  • defining operational decision rules
  • ensuring decisions are evidence-aware
  • ensuring risk controls are applied
  • preventing vague recommendations from becoming action
  • ensuring decisions have owners and next actions
  • ensuring validation and human review occur where required
  • ensuring decisions are logged when important
  • preventing premature automation
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting paid traffic, finance, compliance, public content, and future client systems
  • deciding when operational decision logic is ready for plugin/UI transformation

Individual Brains may make local low-risk operational decisions, but HeadOffice governs cross-Brain, high-risk, finance-related, developer-related, MCR-related, automation-related, and client-facing decisions.

Relationship To Other MWMS Standards

This framework supports and must align with:

  • MWMS Structured Analysis And Insight Workflow Framework
  • MWMS Forecasting And Scenario Planning Framework
  • MWMS AI Agent Operations Core
  • MWMS AI Context Routing Framework
  • MWMS AI Permission Gatekeeper Framework
  • MWMS AI Command And Trigger Framework
  • MWMS Recurring Intelligence And Reporting Pipeline Framework
  • MWMS AI Multi Agent Role Design Framework
  • MWMS AI Exchange Zone And Dependency Control Framework
  • MWMS AI Ambiguity And Partial Failure Containment 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 operational decision layer to the MWMS decision-intelligence system.

Drift Protection

This framework protects MWMS from:

  1. Making recurring decisions inconsistently
  2. Hiding decisions inside vague commentary
  3. Acting without source quality review
  4. Ignoring risk level
  5. Skipping human review
  6. Creating actions with no owner
  7. Routing work without decision logic
  8. Sending unclear work to M
  9. Creating duplicate MCR pages
  10. Treating newsletter noise as action
  11. Moving offers toward spend too early
  12. Automating before manual proof
  13. Delivering client work without approval
  14. Failing to log important decisions
  15. Measuring activity instead of decision quality

Any important decision without evidence, risk level, owner, and next action should remain draft, parked, or escalated.

Architectural Intent

The architectural intent of the MWMS Operational Decision Intelligence Framework is to make MWMS decision-driven.

MWMS is not only collecting information, building pages, creating workflows, and routing tasks.

MWMS is building a system that must make better decisions every day.

The long-term goal is that every recurring operational decision can answer:

  • What are we deciding?
  • What type of decision is this?
  • What evidence supports it?
  • What context matters?
  • What options exist?
  • What risk exists?
  • What decision was made?
  • Why was it made?
  • Who owns the next action?
  • What should happen next?
  • What should be logged?
  • When should this decision be reviewed?

When MWMS can answer these questions consistently, HeadOffice becomes a true operational intelligence layer rather than a passive information store.

Change Log

v1.0 — Initial Draft

Created the MWMS Operational Decision Intelligence Framework to define how MWMS makes recurring operational decisions across course absorption, newsletter intelligence, offer evaluation, Brain routing, MCR page work, developer handoffs, permission gatekeeping, automation readiness, recurring reporting, and future client workflows.

This framework establishes operational decision workflow stages, decision types, decision record templates, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that operational decisions must be structured enough to repeat and conservative enough to protect the system.