MWMS AI Guardrail And Preflight Check Standard

System: MWMS
Document Type: Standard
Status: Draft For MCR
Authority: HeadOffice
Applies To: All MWMS Brains, AI Employees, Agent Loops, Deep Search Workflows, Research Workflows, Affiliate Evaluation, Ads Review, Content Workflows, Newsletter Intelligence, HeadOffice Intelligence, Future Client Facing AI Systems
Primary Location: MCR
Future Operational Destination: mwmsbrain.site, mwmsheadofficebrain.site, Brain Room, Dev Console, AI Employee Dashboards, HeadOffice Dashboards, Future Client Portals
Parent Page: HeadOffice
Source Of Truth: MCR
Related Frameworks: MWMS Agent Loop Control Framework, MWMS Next Action Picker Standard, MWMS Agent Loop Context Schema, MWMS AI Work Session Persistence Standard, MWMS AI Observability Metadata Standard, MWMS AI Employee Evaluation Scorecard Standard, MWMS Deep Search Quality And Observability Framework, MWMS Research Planning And Query Rewriting Standard
Course Source: Matt Pocock AIhero Build DeepSearch In TypeScript
Absorption Status: Approved For Integration

Purpose

The purpose of this standard is to define the guardrail and preflight checks MWMS must run before an AI Employee begins meaningful work.

A preflight check is the front-door decision layer before an AI workflow starts.

It determines whether the request is:

clear enough
safe enough
allowed
worth processing
properly routed
within scope
within permissions
within cost limits
suitable for AI handling
in need of clarification
in need of human review

This standard ensures MWMS AI Employees do not immediately start searching, scraping, using tools, creating outputs, or spending tokens before the system understands whether the task should proceed.

Scope

This standard applies to all AI-assisted MWMS workflows, including:

Brain Room requests
Dev Console requests
HeadOffice Intelligence processing
Newsletter Intelligence
Research Brain investigations
Affiliate Brain offer evaluations
Ads Brain compliance checks
Content Brain research and drafting
Data Brain validation
Experimentation Brain analysis
Finance Brain cost review
Deep Search workflows
Agent loop workflows
future client-facing AIBS sessions
future autonomous or semi-autonomous AI Employees

This standard does not define exact code, SDK syntax, frontend implementation, or model-provider setup.

It defines the MWMS governance standard for checking requests before AI work begins.

Core Rule

The core rule is:

Before an AI Employee begins meaningful work, MWMS must check whether the request is clear, safe, authorised, scoped, and worth processing.

An AI Employee should not automatically begin a workflow just because a request exists.

Some requests should proceed.

Some should be clarified.

Some should be routed.

Some should be refused.

Some should be parked.

Some should require human review.

Some should be handled by deterministic workflow instead of an agent loop.

Definition Of A Preflight Check

A Preflight Check is a structured decision step that happens before the main AI workflow begins.

It checks:

clarity
safety
permission
scope
risk
cost
evidence need
workflow mode
routing
human review requirements

The preflight check decides the next safe system action.

Possible outcomes:

proceed
ask clarifying question
route to another Brain
use deterministic workflow
start controlled agent loop
require human review
refuse or reject
park for later
stop with reason

Definition Of A Guardrail

A Guardrail is a rule, check, or boundary that prevents unsafe, unclear, wasteful, or unauthorised AI behaviour.

Guardrails may apply before, during, or after a workflow.

This standard focuses mainly on before-workflow guardrails.

Examples:

safety guardrail
permission guardrail
clarity guardrail
cost guardrail
tool-use guardrail
compliance guardrail
client-facing guardrail
evidence guardrail
routing guardrail
human-review guardrail

Guardrails are not there to slow MWMS down.

They prevent expensive, risky, or low-quality AI work from starting in the wrong direction.

Why MWMS Needs Preflight Checks

Without preflight checks, AI Employees may:

answer vague questions incorrectly
search before understanding the task
scrape sources unnecessarily
waste tokens
use tools when not allowed
ignore compliance risk
produce unsafe recommendations
answer outside their Brain scope
fail to ask required clarifying questions
miss location or jurisdiction requirements
skip human review
start an agent loop where a simple workflow would be better
create unsupported or risky final outputs

With preflight checks, MWMS gains:

better safety
lower cost
better research quality
better routing
better user experience
stronger HeadOffice control
fewer failed workflows
fewer unclear outputs
stronger client readiness

Preflight Position In The Workflow

The preflight check should occur before expensive or risky actions.

Standard order:

Request received
Preflight check
Clarification if needed
Route or reject if needed
Select workflow mode
Start research plan or controlled workflow
Execute actions
Evaluate output
Store session and trace
Review, route, complete, or improve

The preflight check is the gate before the main work begins.

Preflight Outcome Types

A preflight check may produce one of the following outcomes.

Outcome	Meaning
proceed	Request is clear, safe, and allowed
ask_clarifying_question	More information is needed before work starts
route	Another Brain or workflow should handle it
deterministic_workflow	Fixed workflow is safer than agent loop
controlled_agent_loop	AI can choose approved next actions
human_review_required	Human must approve before proceeding
reject	Request should not proceed
refuse	Request is unsafe, disallowed, or outside boundaries
park	Request may be useful later but should pause now
stop	No valid action should be taken

Preflight Check Categories

MWMS preflight checks are divided into ten categories:

Clarity Check
Safety Check
Permission Check
Scope Check
Brain Routing Check
Risk Check
Cost And Usage Check
Evidence And Freshness Check
Workflow Mode Check
Human Review Check

Each category protects the workflow before it begins.

1. Clarity Check

The Clarity Check determines whether the request is specific enough to act on.

The AI Employee should ask:

What is the user asking?
Is the request ambiguous?
Is there more than one likely meaning?
Is the expected output clear?
Is the target subject clear?
Is the decision being supported clear?
Is the required Brain or workflow clear?
Are key constraints missing?
Would proceeding now create guesswork?

Examples of unclear requests:

“Tell me about this.”
“Is this good?”
“Research that.”
“What do you think?”
“Can we use this?”
“Fix this.”
“Make it better.”
“Check the policy.”

These may be clear in context, but if context is missing, clarification should happen before work begins.

Clarity Rule

If a request is ambiguous enough that proceeding could waste time, create wrong output, or cause risky assumptions, the AI Employee should ask a clarifying question before starting the workflow.

2. Safety Check

The Safety Check determines whether the request is allowed and safe for the AI Employee to handle.

The AI Employee should check:

Does the request involve unsafe instructions?
Does it involve prohibited content?
Does it involve illegal activity?
Does it involve harmful advice?
Does it require dangerous claims?
Does it create compliance risk?
Does it create platform policy risk?
Does it ask the AI to bypass safeguards?
Does it involve sensitive personal data?
Does it involve high-risk legal, medical, financial, or political areas?

Safety Rule

If the request is unsafe or disallowed, the AI Employee must refuse, stop, or escalate according to MWMS and platform policy.

The AI Employee must not begin research, source inspection, tool use, or content creation for unsafe requests.

3. Permission Check

The Permission Check determines whether the AI Employee is allowed to perform the requested work.

The AI Employee should check:

Is this Employee allowed to handle this workflow?
Is this Brain allowed to handle this request?
Is the user allowed to trigger this action?
Are the required tools authorised?
Is database access allowed?
Is external search allowed?
Is source scraping allowed?
Is publishing allowed?
Is client-facing output allowed?
Is human approval required first?

Permission Rule

If permission is missing, the AI Employee must not proceed.

It should choose one of:

request human review
route to authorised Brain
stop with reason
ask for approval
provide a limited answer without restricted action

4. Scope Check

The Scope Check determines whether the request belongs inside MWMS and the current project context.

The AI Employee should check:

Is this request relevant to MWMS?
Is this work part of the current project?
Is this course absorption, development, research, or operational work?
Does this interfere with M’s active build?
Does this belong to another project?
Is this a personal task, business task, or system task?
Should this be handled later?

Scope Rule

If the request is out of scope for the current MWMS work area, the AI Employee should route, park, or clarify before proceeding.

5. Brain Routing Check

The Brain Routing Check determines which Brain should own the work.

Possible Brain destinations include:

HeadOffice
Research Brain
Affiliate Brain
Ads Brain
Content Brain
Data Brain
Experimentation Brain
Finance Brain
Operations Brain
Risk Brain
Strategy Brain
MCR
Brain Room
Dev Console

Routing Rule

If the request belongs to another Brain, the AI Employee should route it rather than trying to complete it inside the wrong workflow.

Examples:

Request Type	Likely Destination
source investigation	Research Brain
offer evaluation	Affiliate Brain
ad policy or claim review	Ads Brain / Risk Brain
cost or budget issue	Finance Brain
test or experiment issue	Experimentation Brain
system architecture update	MCR / HeadOffice
developer support	Dev Console
operational visibility	HeadOffice

6. Risk Check

The Risk Check determines how dangerous or important the task is.

Risk categories:

Risk Level	Meaning
Low	Internal, low-cost, low-consequence
Medium	Affects workflow quality, research, or decisions
High	Affects money, campaigns, compliance, client output, or public claims
Critical	Could create legal, platform, financial, safety, or reputational harm

Risk factors include:

money involved
campaign launch involved
public claims involved
compliance involved
client-facing output involved
legal/medical/financial sensitivity
weak source evidence
user uncertainty
system permission uncertainty
irreversible action

Risk Rule

The higher the risk, the more MWMS should prefer:

deterministic workflow
official sources
human review
stronger evidence
lower AI autonomy
full observability

7. Cost And Usage Check

The Cost And Usage Check determines whether the task is worth the expected AI/tool usage.

The AI Employee should check:

Is this task worth a Deep Search workflow?
Can it be answered from existing context?
Does it require external search?
Does it require scraping?
Does it require multiple model actions?
Does it require expensive tools?
Is there a cheaper workflow path?
Is the user or workflow near usage limits?
Is the expected value worth the cost?

Cost Rule

AI Employees should not start expensive research loops for low-value, unclear, or unsafe requests.

High-cost workflows should require:

clear task
approved purpose
suitable evidence need
usage tracking
cost visibility
stop conditions

8. Evidence And Freshness Check

The Evidence And Freshness Check determines whether the task needs current or source-backed information.

The AI Employee should check:

Does this answer depend on current facts?
Does it need sources?
Does it need official sources?
Does it need jurisdiction-specific information?
Does it need date awareness?
Does it need source freshness?
Can older knowledge be used safely?
Is internal MWMS context enough?
Is web search required?

Evidence Rule

If the request depends on current or verifiable information, the AI Employee should not answer only from memory.

It should route into a research plan, search workflow, or source-backed process.

9. Workflow Mode Check

The Workflow Mode Check decides how the task should be handled.

Options:

Mode	Meaning
Simple Answer	Respond from existing safe context
Deterministic Workflow	Fixed steps, little AI choice
Assisted Workflow	AI helps inside controlled steps
Controlled Agent Loop	AI chooses next approved action
Deep Search Workflow	Research plan plus source-backed answer
Human Review First	Human approval before action
Refuse / Stop	Do not proceed

Workflow Mode Rule

Not every request needs an agent loop.

Before starting an agent loop, MWMS must ask:

Is this actually a workflow, a simple answer, a research task, or a controlled agent task?

This prevents over-agentic behaviour.

10. Human Review Check

The Human Review Check determines whether human approval is required before or after the workflow.

Human review is required when:

financial risk exists
compliance risk exists
public claims are involved
client-facing output is involved
campaign launch is affected
source evidence is weak
location or jurisdiction affects the answer
AI confidence is low
trace quality is incomplete
tool permissions are unclear
the AI Employee is not approved for the workflow

Human Review Rule

Human review should happen before expensive or risky workflow actions when risk is already visible.

Do not wait until the end if the risk is obvious at the start.

Clarification As A First-Class Action

Clarification is not a failure.

Clarification is an approved AI Employee action.

Suggested action name:

ask_clarifying_question

or:

request_clarification

Use this action when:

the request is ambiguous
the subject is unclear
multiple meanings are possible
required output is unclear
important constraints are missing
wrong assumptions could cause poor output
research would be expensive without clarification
safety depends on missing context
location or jurisdiction is missing
user intent is unclear

Clarification Rule

Ask the smallest useful clarifying question needed to proceed.

Do not overwhelm the user with unnecessary questions.

Clarification Output Standard

A clarification output should include:

what is unclear
why it matters
one clear question
optional examples if helpful

Recommended structure:

{
  "action_type": "ask_clarifying_question",
  "unclear_point": "",
  "why_it_matters": "",
  "question": "",
  "examples": []
}

Example:

Before I research this, which market are we checking — USA, Australia, or global? The answer may change because affiliate offers, ad policies, and compliance rules can differ by country.

Guardrail Gate Sequence

A standard MWMS guardrail sequence should be:

Clarity Gate
Safety Gate
Permission Gate
Scope Gate
Brain Routing Gate
Risk Gate
Cost Gate
Evidence/Freshness Gate
Workflow Mode Gate
Human Review Gate

The sequence may be compressed for low-risk workflows.

High-risk workflows should run more complete preflight checks.

Preflight Output Standard

The preflight check should return structured output.

Recommended format:

{
  "preflight_status": "",
  "decision": "",
  "reason": "",
  "clarification_required": false,
  "clarifying_question": "",
  "safe_to_proceed": false,
  "permission_status": "",
  "scope_status": "",
  "recommended_brain": "",
  "risk_level": "",
  "cost_level": "",
  "freshness_required": false,
  "sources_required": false,
  "workflow_mode": "",
  "human_review_required": false,
  "next_action": ""
}

This allows the decision to be logged, reviewed, and evaluated.

Preflight Decision Types

Suggested decision values:

Decision	Meaning
proceed_simple	safe to answer from existing context
proceed_research	begin research planning
proceed_controlled_loop	begin controlled agent loop
ask_clarification	ask user for missing information
route_to_brain	send to another Brain
require_human_review	wait for human approval
use_deterministic_workflow	use fixed workflow
park	hold for later
reject	unsuitable or not worth proceeding
refuse	unsafe or disallowed
stop	no safe action available

Safety Gate Before Tool Use

Tools should not be used before the request passes safety and permission checks.

This applies to:

web search
source scraping
browser actions
database queries
file access
email access
calendar access
ad platform access
publishing tools
automation tools
client-facing outputs

Rule

The AI Employee should not use tools first and ask safety questions later.

Evidence Gate Before Answering

If the preflight check determines that sources are required, the AI Employee should not answer from memory unless clearly marked as a limited, non-final response.

Evidence may be required for:

current facts
policy questions
compliance decisions
product availability
pricing
affiliate metrics
vendor claims
campaign decisions
financial recommendations
legal or regulated topics
client-facing outputs

Rule

If evidence is required, the workflow must gather or inspect evidence before producing a trusted answer.

Cost Gate Before Deep Search

Deep Search should not start automatically for every request.

Deep Search should be used when:

the decision is important
the information may be current or external
sources are required
evidence quality matters
the task has business value
the user or workflow expects deeper research

Deep Search should be avoided when:

the request is casual
the answer is already known from current context
the request is vague
the user only needs a simple explanation
the task is low value
cost is not justified
safety or permission is not clear

Guardrails During The Workflow

Some guardrails continue after preflight.

Examples:

stop if sources conflict
stop if cost limit reached
stop if source freshness cannot be confirmed
stop if tool permission fails
stop if output fails eval
escalate if risk increases
ask clarification if new ambiguity appears
downgrade confidence if evidence is weak

Preflight is the first gate, not the only gate.

Guardrails After The Workflow

After output is generated, MWMS should check:

did the output answer the task?
did it follow required format?
did it include sources where needed?
did it include confidence?
did it avoid unsafe claims?
did it require human review?
did it store the session and trace?
did it create a Kaizen note if useful?

These post-workflow checks connect to the MWMS AI Employee Evaluation Scorecard Standard.

Usage Visibility Rule

AI usage should be visible before it becomes a cost problem.

Preflight should decide whether usage should be tracked at a higher level.

Usage should eventually be visible by:

session
task
Brain
AI Employee
workflow
user
client
model
tool
source inspection
successful output
failed output

Usage visibility supports HeadOffice and Finance Brain.

Usage Fields For Preflight

Recommended usage-related fields:

Field	Description
estimated_cost_level	Low, medium, high
expected_model_actions	Expected number of model actions
expected_tool_actions	Expected number of tool actions
expected_sources_to_inspect	Estimated source count
usage_limit_status	Normal, near limit, exceeded, unknown
cost_approval_required	Yes or no
usage_visibility_required	Yes or no

Resumability Check

For long-running workflows, preflight should consider whether the session needs resumability.

Resumability matters when:

the workflow may take time
streaming could be interrupted
multiple sources are inspected
the workflow has several steps
the output is valuable
the session may be continued later
the user may leave and return

Rule

Long-running AI work sessions should be recoverable, resumable, or safely restorable from backend state.

This connects to the MWMS AI Work Session Persistence Standard.

Source Visibility Rule

If sources are used to produce the output, the operator should be able to see them.

Source visibility should include:

source title
source URL
source type
freshness rating
trust rating
evidence summary
whether source was used in final answer
whether source conflicted with other evidence

Rule

Sources used by AI Employees should be visible to the operator, not hidden only in backend trace logs.

Evaluator Optimizer Rule

Some AI workflows should be treated as evaluator/optimizer systems rather than open-ended agents.

This means the system:

gathers evidence
evaluates whether the evidence is enough
continues if more evidence is needed
answers if evidence is enough
escalates if risk or uncertainty remains
improves from failures

Rule

For high-value MWMS work, the AI should not merely generate. It should evaluate whether it is ready to generate.

Relationship To Agent Loop Control

This standard defines what happens before the agent loop begins.

The Agent Loop Control Framework defines what happens inside the loop.

The relationship is:

Preflight Check
→ choose workflow mode
→ start simple answer, deterministic workflow, research plan, controlled loop, route, review, or stop

If preflight fails, the loop should not begin.

Relationship To Next Action Picker

The Next Action Picker should include clarification and guardrail-aware action types.

Recommended additional action types:

ask_clarifying_question
guardrail_check
request_human_review
stop_due_to_safety
stop_due_to_permission
route_due_to_scope
proceed_after_preflight

The Next Action Picker should not bypass preflight decisions.

Relationship To Research Planning And Query Rewriting

The Research Planning And Query Rewriting Standard should run only after preflight determines that research is appropriate.

Preflight decides:

Should research begin?

Research planning decides:

What should the research look for?

Relationship To Work Session Persistence

The preflight result should be stored in the AI work session where meaningful.

A session may include:

preflight decision
clarification question
safety status
permission status
workflow mode
risk level
human review status
usage expectation
reason for proceeding or stopping

This makes the session auditable.

Relationship To Observability Metadata

Preflight decisions should be observable.

Recommended metadata:

preflight_status
preflight_decision
safe_to_proceed
clarification_required
permission_status
workflow_mode
risk_level
human_review_required
cost_level
refusal_reason
route_destination
stop_reason

This strengthens HeadOffice visibility.

Relationship To Evaluation Scorecards

Preflight quality should be evaluated.

Evaluation questions:

Did the AI ask for clarification when needed?
Did it proceed when it should have stopped?
Did it refuse correctly?
Did it route correctly?
Did it choose the right workflow mode?
Did it identify risk correctly?
Did it avoid unnecessary cost?
Did it require human review when needed?

Failures should become regression cases.

Relationship To Risk Brain

Risk Brain may later own or support high-risk guardrail logic.

Risk Brain may define:

prohibited workflows
claim-risk checks
compliance trigger rules
client-facing risk categories
escalation thresholds
platform policy risk logic
region-specific risk checks

Until Risk Brain is fully operational, HeadOffice owns this standard.

Minimum Starting Implementation

MWMS does not need a complex guardrail system immediately.

The first practical implementation should check:

Is the request clear?
Is it safe?
Is it in scope?
Which Brain owns it?
Does it need current information?
Does it need sources?
Does it need clarification?
Does it need human review?
What workflow mode should be used?

Minimum output:

{
  "decision": "",
  "reason": "",
  "clarification_required": false,
  "clarifying_question": "",
  "safe_to_proceed": true,
  "recommended_brain": "",
  "risk_level": "",
  "workflow_mode": "",
  "human_review_required": false,
  "next_action": ""
}

Future Enhancements

Future enhancements may include:

MWMS Guardrail Registry
MWMS Preflight Decision Dataset
MWMS Clarification Question Standard
MWMS AI Usage And Cost Visibility Standard
MWMS Source Visibility And Evidence Display Standard
MWMS Client Facing AI Safety Standard
MWMS Risk Brain Guardrail Framework
MWMS Permission Gatekeeper Upgrade
MWMS Workflow Mode Selection Standard
MWMS Preflight Dashboard Specification

These should be created only when implementation or system complexity justifies them.

Drift Protection

This standard prevents the following drift:

starting AI work before understanding the task
researching vague requests
using tools before safety checks
using tools without permission checks
ignoring Brain routing
wasting tokens on low-value tasks
answering current questions without current evidence
skipping clarifying questions
making every request agentic
bypassing human review
hiding risk until after output generation
treating guardrails as optional afterthoughts
losing visibility into why work proceeded or stopped

If the request fails preflight, the workflow should not continue blindly.

Architectural Intent

The architectural intent of this standard is to create a safe and intelligent front door for MWMS AI work.

MWMS is not building AI Employees that react blindly to every prompt.

MWMS is building governed AI Employees that first decide whether the work should happen, how it should happen, who should own it, and what controls are required.

Preflight checks make AI work:

safer
clearer
cheaper
more targeted
easier to route
easier to audit
easier to improve

This standard ensures MWMS AI Employees do not simply act.

They check, classify, route, clarify, and then act under governance.

Change Log

v1.0 Initial Draft

Created the MWMS AI Guardrail And Preflight Check Standard based on absorbed insights from the final block of Matt Pocock AIhero Build DeepSearch In TypeScript.

Integrated principles from course sections covering:

combined search and scrape workflows
resumable streams
evaluator/optimizer loop
showing sources in the frontend
implementing guardrails
asking clarifying questions before workflow execution
showing token and usage data
AI SDK migration as tool-change awareness

Established this standard as the MWMS front-door governance layer for checking clarity, safety, permissions, scope, routing, risk, cost, evidence needs, workflow mode, and human review requirements before AI Employee workflows begin.