System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.4
Primary Location: MCR
Future Operational Destination: Prompting Framework, HeadOffice Brain, Automation Brain, AIBS Brain, Content Brain, Ads Brain, Research Brain, Data Brain, Experimentation Brain, AI Employee Canon, Compliance Brain, Risk Brain
Parent Page: MWMS Prompting Framework
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-27
Source / Origin: AI Automations by Jack Master Prompting And Prompt System Design Block, Master Prompting With Devin Parts 1 And 2, Detailed Prompt Creation Lesson, AI Productivity Agent, RAG Chatbot, AI Researcher, Fact Checking Copilot, Client Intelligence, Meeting Note Taker, Browser Extension, Web Application, Multi Step Automation Material, Visual Generation Automation Material, AI Agent Tool Selection Material, Agent Runtime Instruction Material, Voice Transcription Input Material, And Specialist Agent Workflow Material
MWMS Classification: Prompt Architecture Framework / Automation Output Reliability Standard / AI Employee Prompt Governance / Agent Prompt Contract Standard / Tool Description Contract Standard / Tool Selection Instruction Standard / Tool Input And Result Contract Standard / Prompt Chain Design System / Structured Output Contract Standard / Prompt Quality Control Framework / Runtime Output Recovery Standard / Meta Prompt Drafting Standard / Visual Prompt Contract Standard / Voice Transcription Input Contract Standard
Primary Brain: MWMS Prompting Framework
Supporting Brains: HeadOffice Brain, Automation Brain, AIBS Brain, Content Brain, Ads Brain, Research Brain, Data Brain, Experimentation Brain, AI Employee Canon, Compliance Brain, Risk Brain, Product Brain, SIT Brain
Related Pages: MWMS Prompting Framework, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS AI Agent Orchestration Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Command And Trigger Framework, MWMS AI Guardrail And Preflight Check Standard, MWMS AI Automation Security And Risk Checklist, MWMS AI Observability Metadata Standard, MWMS AI Output Validation Standard, MWMS AI Schema And Decision Ready Output Framework, MWMS AI Workflow Pipeline Standard, MWMS Agent Loop Control Framework, MWMS AI Work Session Persistence Standard, MWMS Next Action Picker Standard, MWMS Independent Model Review And Rescue Routing Framework, MWMS Deep Search Quality And Observability Framework, MWMS Source Visibility And Evidence Display Standard, MWMS AI Usage And Cost Visibility Standard, MWMS Personalised Visual Sales Asset Production And Governance Framework, MWMS Market Driven Social Content Production Framework, MWMS Client Communication Automation Framework, MWMS AI Assisted Outreach And Sales Follow Up Automation Framework, MWMS Meeting Intelligence And Action Extraction Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, HeadOffice Kaizen Continuous Improvement Loop
Framework Purpose
This framework defines how MWMS designs, tests, governs, deploys, validates, repairs, observes, versions, and improves prompts used inside AI Employees, AI agents, automation workflows, content systems, research systems, reporting systems, diagnostic systems, communication workflows, data workflows, client facing systems, tool using systems, and visual generation systems.
It establishes that a production prompt is not a casual instruction and is not complete merely because it produces one plausible output.
A production prompt is an operating contract.
It must define:
purpose
ownership
trigger
input requirements
context sources
memory sources where applicable
authority
permissions
constraints
tool access where applicable
tool selection rules where applicable
output requirements
validation
failure behaviour
repair behaviour
retry limits
fallback routes
handoff destination
stop conditions
observability
versioning
human review
approval requirements
The framework also establishes that an agent prompt must govern not only what an agent says, but how the agent reasons within its permitted scope, selects tools, validates tool inputs, interprets tool results, verifies business outcomes, stops when authority or evidence is missing, and hands work to the correct destination.
Core Principle
A prompt is reliable only when the full operating path is reliable.
This includes:
the instruction
the input
the context
the memory
the available tools
the tool descriptions
the authority boundary
the output contract
the validation layer
the repair route
the retry limit
the fallback route
the handoff
the approval gate
the runtime evidence
the final business outcome
A strong prompt cannot compensate for:
missing data
wrong context
incorrect permissions
poor tool descriptions
unsafe tool access
ambiguous runtime instructions
unvalidated tool inputs
misinterpreted tool results
weak workflow design
missing approval
uncontrolled retries
unverified business outcomes
Prompt Reliability Objective
MWMS prompt systems must produce outputs that are:
task aligned
factually grounded
source linked where required
authority limited
schema valid where required
semantically valid
operationally usable
traceable
recoverable
safe to route
consistent across prompt stages
consistent across tool actions
clear about uncertainty
clear about completion status
suitable for human review
Prompt Architecture Model
A governed production prompt should include the following layers where applicable:
- Purpose And Ownership Layer
- Trigger And Workflow Position Layer
- Input Contract Layer
- Context And Knowledge Layer
- Memory Source Layer
- Authority And Permission Layer
- Guideline And Constraint Layer
- Example And Demonstration Layer
- Reasoning And Decision Layer
- Tool Description And Selection Layer
- Tool Input Contract Layer
- Output Contract Layer
- Tool Result And Business Outcome Layer
- Validation Layer
- Repair Retry And Fallback Layer
- Model Selection And Testing Layer
- Prompt Simplification And Efficiency Layer
- Observability And Versioning Layer
- Human Review And Governance Layer
- Specialist Contract Layer Where Applicable
Specialist contracts may include:
Agent Prompt Contract
Visual Prompt Contract
Voice Transcription Input Contract
Structured Research Prompt Contract
Client Communication Prompt Contract
Sensitive Action Prompt Contract
- Purpose And Ownership Layer
Every production prompt must define its operating purpose.
Purpose should identify:
what the prompt is intended to achieve
which Brain or AI Employee owns the task
which workflow uses the prompt
which business decision or output the prompt supports
what the prompt is not intended to do
Purpose must be narrow enough to test.
Weak Purpose Example
Help with leads.
Strong Purpose Example
Classify a newly submitted lead against the approved qualification criteria, identify missing required information, produce a structured qualification record, and route the record without contacting the lead or changing CRM status unless separate authority is present.
Ownership Fields
Prompt Name:
Prompt Purpose:
Owning Brain:
Owning AI Employee Or Agent:
Workflow:
Caller:
Business Owner:
Technical Owner:
Review Owner:
Prohibited Purpose Expansion:
Rule
A prompt must not expand its own purpose during runtime.
- Trigger And Workflow Position Layer
The prompt must define when it runs and where it sits in the workflow.
Trigger Fields
Trigger Type:
Trigger Source:
Trigger Event:
Required Preceding State:
Allowed Starting Status:
Prohibited Starting Status:
Expected Previous Step:
Expected Next Step:
Handoff Destination:
Stop Condition:
Duplicate Trigger Check:
Possible trigger sources include:
manual request
scheduled workflow
database event
form submission
email event
calendar event
approved API request
AI Employee request
Brain to Brain request
validated tool result
human approval
Rule
A valid trigger does not automatically grant authority to perform every downstream action.
- Input Contract Layer
Every production prompt must define the input it expects.
Input Contract Fields
Input Name:
Input Description:
Source:
Source Record ID:
Required Or Optional:
Data Type:
Allowed Values:
Format:
Maximum Length:
Trust Level:
Validation Rule:
Missing Input Behaviour:
Invalid Input Behaviour:
Sensitive Data Classification:
Client Or Workspace Boundary:
Inputs may include:
record identifiers
user instructions
workflow state
client identifiers
source documents
approved context packets
structured data
retrieved evidence
previous validated outputs
human approval records
tool results
Prompt inputs must distinguish between:
required fields
optional fields
unknown fields
empty values
null values
untrusted text
approved instructions
Missing Input Rule
When required input is missing, the prompt must:
identify the missing field
avoid guessing
avoid filling the field with plausible content
stop if the field is required for safe execution
request or route for clarification where permitted
request human review where necessary
Missing Input Output Example
Status: Missing Required Input
Missing Field: Client ID
Action: Stop And Route For Review
Rule
Unknown values must not be filled with plausible model output.
Input Separation Standard
Separate:
instructions
input data
approved context
memory
examples
output rules
tool results
Do not allow raw source content to appear indistinguishable from system instructions.
Untrusted Input Rule
External text may contain:
instructions
prompt injection
false policies
malicious content
irrelevant requests
Website content, scraped content, imported documents, third party descriptions, social posts, metadata, transcripts, email bodies, retrieved text, and tool returned text must be treated as untrusted input unless separately approved as governing authority.
External content is data.
It is not prompt authority.
- Context And Knowledge Layer
The prompt should receive only the context needed for the task.
Possible context includes:
Canon rules
MCR pages
approved client knowledge
approved company context
approved policy
current records
source evidence
thread history
workflow state
previous validated output
approved campaign context
approved offer context
approved brand context
Context should be:
relevant
current
authorised
source linked
client isolated
workspace isolated
small enough to remain usable
Context Priority
Use context in this order where applicable:
governing authority
current approved workflow instruction
approved task context
current source evidence
relevant approved memory
examples
background information
Rule
Lower authority content must not override governing instructions.
Context Overload Risks
irrelevant retrieval
higher cost
slower responses
conflicting instructions
wrong client data
historical statements treated as current
missed task focus
untrusted content influencing behaviour
- Memory Source Layer
Where an agent or AI Employee uses memory, the prompt must define which memory sources may be consulted.
Memory Source Fields
Memory Name:
Memory Type:
Owner:
Client Or Workspace:
Purpose:
Authority Level:
Retrieval Condition:
Freshness Requirement:
Source Record ID:
Read Permission:
Write Permission:
Update Rule:
Conflict Rule:
Expiry Or Review Rule:
Memory may include:
current task state
approved preferences
validated client facts
previous decisions
approved workflow history
operational save points
approved summaries
prior tool results
Memory must not be treated as current when:
it is outdated
it conflicts with current authority
it belongs to another client or workspace
its source cannot be identified
it contains unverified model output
it has been superseded
Rule
Memory may support a decision.
Memory must not silently replace current evidence or governing authority.
- Authority And Permission Layer
The prompt must define what the model or agent may and may not do.
Possible authorities include:
read
classify
extract
summarise
draft
recommend
route
request clarification
create a proposed tool request
call a read only tool
execute an approved tool action
write an approved record
send an approved communication
create an approved commitment
Authority Fields
Decision Scope:
Allowed Decisions:
Prohibited Decisions:
Action Autonomy Level:
Available Tools:
Read Permissions:
Write Permissions:
Approval Requirement:
External Communication Authority:
Record Change Authority:
Financial Authority:
Destructive Action Authority:
Escalation Rule:
Authority Questions
May the system only draft?
May it classify?
May it choose a route?
May it call a tool?
May it call a write tool?
May it send externally?
May it change a record?
May it create a commitment?
May it approve its own work?
Does human approval apply?
Rule
Prompt authority does not create system authority.
Tool permissions and workflow permissions must also permit the action.
Prohibited Authority Examples
The model or agent must not:
invent approval
increase its authority
claim a tool succeeded before confirmation
send because it drafted successfully
change pricing without authority
change policy
access unrelated client context
execute a high risk action without approval
repeat a state changing action without checking prior execution
authorise a person’s likeness
authorise a person’s voice
authorise logo use
waive a disclosure requirement
approve an unsupported claim
approve external delivery
publish without publication authority
- Guideline And Constraint Layer
Guidelines explain how the task should be performed.
Constraints define what must not occur.
Guidelines may define:
tone
analysis method
evidence standard
classification logic
prioritisation
length
clarity
decision focus
tool selection discipline
uncertainty treatment
Constraints may define:
prohibited claims
privacy boundaries
forbidden actions
allowed labels
maximum output
maximum tool scope
required uncertainty
no invented fields
no unsupported conclusions
no authority expansion
no duplicate state changing execution
Rule
Guidelines and constraints must be specific enough to test.
Duplicate Constraint Rule
Repeated instructions may create noise or conflict.
Remove unnecessary duplication.
Conflicting Constraint Rule
When two instructions conflict, resolve the conflict before deployment.
Do not expect the model to choose the correct business rule.
- Example And Demonstration Layer
Examples can show the model:
correct structure
acceptable reasoning pattern
tone
label use
field population
edge case handling
failure behaviour
tool selection
tool refusal
tool result interpretation
handoff behaviour
Examples should be:
relevant
correct
representative
small enough to remain useful
free from obsolete rules
free from hidden client data
free from unsafe authority assumptions
Examples must not be treated as authority when they conflict with the current contract.
- Reasoning And Decision Layer
The prompt should define the decision process required for the task without requiring uncontrolled or hidden business rule invention.
The reasoning layer may require the system to:
identify the task
check required inputs
check authority
check context freshness
check memory relevance
identify available tools
select the minimum necessary tool
validate tool inputs
evaluate evidence
apply approved criteria
identify uncertainty
choose an allowed status
stop when no valid route exists
route for approval where required
The reasoning layer must not instruct the model to:
invent criteria
invent missing facts
choose outside the allowed labels
override permissions
treat confidence as evidence
continue after a mandatory stop condition
Rule
The model may reason within the approved decision space.
It may not create a new decision space.
- Agent Prompt Contract
Purpose
The Agent Prompt Contract governs agents that must interpret a task, use context or memory, select tools, perform permitted actions, evaluate results, and produce a final status or handoff.
An Agent Prompt Contract is required when an AI system may:
choose between multiple tools
perform multiple workflow steps
make an operational decision
write or change records
send or schedule external communication
create tasks or appointments
retrieve and combine evidence
coordinate specialist prompts
continue across multiple agent loops
Agent Prompt Contract Fields
Agent Name:
Agent Role:
Operating Purpose:
Owning Brain:
Owning AI Employee:
Caller:
Trigger:
Workflow:
Input Contract:
Context Sources:
Memory Sources:
Available Tools:
Tool Selection Rules:
Decision Scope:
Allowed Decisions:
Prohibited Decisions:
Action Autonomy Level:
Read Permissions:
Write Permissions:
Evidence Requirements:
Output Contract:
Tool Result Contract:
Business Outcome Requirement:
Handoff Destination:
Stop Conditions:
Escalation Rule:
Human Approval Requirement:
Retry Limit:
Fallback Route:
Observability Requirement:
Agent Version:
Last Reviewed:
Agent Role Rule
The role must describe an operating responsibility.
It must not use inflated identity language that implies authority the agent does not possess.
Operating Purpose Rule
The operating purpose must define:
the task the agent performs
the business state it may change
the outcome it supports
the outcome it may not claim
Decision Scope Rule
The agent may choose only among decisions explicitly permitted by the contract.
Prohibited Decisions Rule
Prohibited decisions must be stated directly.
The absence of a prohibition does not grant authority.
Action Autonomy Levels
Level 0: Observe Only
The agent may read approved information and produce no operational change.
Level 1: Draft Only
The agent may create drafts, recommendations, classifications, or proposed actions.
Level 2: Prepare Approved Action
The agent may create a structured action request but may not execute it.
Level 3: Execute Low Risk Approved Action
The agent may execute predefined low risk actions within approved scope.
Level 4: Execute Conditional Action
The agent may act only when defined evidence, permission, validation, and approval conditions are satisfied.
Level 5: Human Controlled High Impact Action
The agent may prepare and validate the action, but a human must approve execution.
Rule
The selected autonomy level must be recorded.
Runtime instructions must not increase it.
Stop Conditions
An agent must stop when:
required input is missing
authority is missing
no suitable tool exists
tool input cannot be validated
client or workspace identity is uncertain
a required approval is absent
a state changing action may already have executed
evidence is insufficient
tool results conflict
a critical transcription field is uncertain
retry limit is reached
a prohibited action is requested
the requested outcome falls outside the agent’s operating purpose
Escalation Rule
Escalation must identify:
reason
missing authority or evidence
current workflow state
actions already attempted
tool results received
risk
recommended next reviewer
safe next step
- Tool Description Contract
Purpose
An agent can select tools reliably only when each tool has a clear, governed description.
A tool name alone is not a sufficient operating contract.
Every agent accessible tool must have a Tool Description Contract.
Tool Description Contract Fields
Tool Name:
Tool ID:
Tool Version:
Owning System:
Purpose:
Use When:
Do Not Use When:
Required Inputs:
Optional Inputs:
Input Types:
Output:
Output Types:
Side Effects:
Read Or Write:
Permission Requirement:
Approval Requirement:
Maximum Scope:
Idempotency Support:
Duplicate Execution Risk:
Expected Failure Result:
Timeout Behaviour:
Retry Permission:
Fallback:
Example Valid Call:
Example Invalid Call:
Observability Fields:
Last Reviewed:
Purpose Rule
The purpose must state what the tool actually does.
It must not use vague descriptions such as:
handles records
manages communication
helps with scheduling
Use When Rule
Use When must define the conditions that make the tool appropriate.
Do Not Use When Rule
Do Not Use When must define:
prohibited use cases
missing authority conditions
unsafe states
wrong workflow states
wrong client or workspace conditions
duplicate execution risks
Side Effect Rule
Every state changing tool must disclose its side effects.
Possible side effects include:
record creation
record update
external communication
calendar commitment
task creation
financial commitment
publication
deletion
archiving
status change
notification
Tool Description Quality Rule
A tool description must allow an agent to distinguish that tool from every other available tool.
Overlapping tools must define their differences explicitly.
- Tool Selection Instructions
An agent with tool access must follow explicit tool selection instructions.
Required Tool Selection Instructions
Choose the minimum necessary tool.
Use no tool when the task can be completed safely without one.
Do not call a tool merely because it is available.
Do not invent a tool.
Do not invent tool capabilities.
Do not call a prohibited tool.
Do not call a write tool when a read tool is sufficient.
Do not call an external communication tool when drafting is sufficient.
Do not repeat a state changing tool call without checking whether it already executed.
Do not widen the requested scope.
Do not substitute a similar tool without confirming that its purpose and permissions match.
Stop when no suitable tool exists.
Return a structured uncertainty or blocked status when selection cannot be made safely.
Route for approval when required authority is missing.
Tool Selection Sequence
- Identify the required outcome.
- Check whether a tool is necessary.
- Identify tools whose Use When conditions match.
- Remove tools whose Do Not Use When conditions apply.
- Check authority and permissions.
- Check side effects.
- Choose the minimum scope tool.
- Validate required tool inputs.
- Check duplicate execution risk.
- Execute only when the action is permitted.
- Evaluate the returned result.
- Verify the business outcome separately where required.
No Suitable Tool Status
Status: No Suitable Tool
Requested Outcome:
Available Tools Reviewed:
Reason No Tool Is Suitable:
Authority Status:
Required Handoff:
Rule
Tool availability is not tool suitability.
- Tool Input Contract
Every agent tool call must use a validated Tool Input Contract.
Tool Input Contract Fields
Tool Name:
Tool Version:
Requested Action:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Record ID:
Target ID:
Recipient Or Destination:
Date:
Time:
Timezone:
Required Fields:
Optional Fields:
Data Types:
Allowed Values:
Maximum Scope:
Source Evidence:
Source Record IDs:
Approval Status:
Approval Record ID:
Idempotency Key:
Prior Execution Check:
Sensitive Data Classification:
Validation Result:
Validation Errors:
Tool Input Validation Must Check
required fields
data types
record identifiers
client identity
workspace identity
date
time
timezone
recipient or target
requested action
maximum scope
idempotency key
approval status
source evidence
allowed workflow state
duplicate execution risk
Input Scope Rule
The agent must provide only the information required for the tool call.
It must not include unrelated client, personal, confidential, or operational data.
Critical Identifier Rule
An agent must not guess:
record IDs
client IDs
workspace IDs
email addresses
telephone numbers
payment details
calendar dates
appointment times
approval IDs
destructive action targets
Idempotency Rule
Where a tool changes state, the call should include or derive a stable idempotency key where supported.
Where idempotency is not supported, the agent must perform a prior execution check before repeating the action.
- Output Contract Layer
Every production prompt must define the output expected.
Output Contract Fields
Output Purpose:
Output Format:
Required Fields:
Optional Fields:
Allowed Labels:
Data Types:
Null Behaviour:
Unknown Value Behaviour:
Maximum Length:
Source Citation Requirement:
Evidence Requirement:
Confidence Requirement:
Uncertainty Requirement:
Recommended Action Field:
Handoff Field:
Validation Rule:
Storage Destination:
Downstream Consumer:
Outputs may be:
human readable text
structured JSON
database ready fields
classification labels
decision records
action requests
research summaries
draft communications
tool requests
tool result records
visual assets
status records
The output contract must distinguish between:
fact
source evidence
inference
recommendation
decision
action request
tool status
business outcome
uncertainty
Rule
Structured output is not valid merely because it parses.
- Tool Result Contract
Purpose
A tool call result must be interpreted through a governed Tool Result Contract.
A successful API response is not automatically a successful business outcome.
Tool Result Contract Fields
Tool Name:
Tool Call ID:
Requested Action:
Requested At:
Accepted At:
Completed At:
Tool Status:
Tool Response:
Created Or Changed Record IDs:
External Message ID:
Calendar Event ID:
Task ID:
Partial Failure Details:
Validation Result:
Duplicate Execution Check:
Business Outcome Status:
Business Outcome Evidence:
Follow Up Required:
Retry Permitted:
Handoff Required:
Tool Status Values
Tool Call Requested
Tool Call Accepted
Tool Call Succeeded
Tool Call Failed
Tool Call Partially Succeeded
Tool Call Rejected
Tool Call Timed Out
Tool Call Status Unknown
Business Outcome Values
Business Outcome Verified
Business Outcome Not Verified
Business Outcome Partially Verified
Business Outcome Failed
Business Outcome Pending
Business Outcome Not Applicable
Required Distinction
The agent must distinguish between:
the request being generated
the tool accepting the request
the tool completing the technical action
the correct record or target being affected
the intended business outcome being achieved
Example
Tool Call Succeeded:
A calendar event record was created.
Business Outcome Not Verified:
The correct attendee has not confirmed the appointment.
Rule
A tool action must not be reported as complete until the tool confirms the technical result.
A business outcome must not be reported as achieved until the required business evidence confirms it.
- Business Outcome Verification
Business Outcome Verification is required when a technical action is only one step toward the intended result.
Examples include:
calendar event created versus appointment successfully arranged
email sent versus recipient received and accepted the request
lead record created versus lead correctly qualified
task created versus work assigned to the correct project
document generated versus approved document stored in the correct location
payment request created versus payment received
content published versus correct public page verified
Business Outcome Verification Fields
Intended Outcome:
Technical Action:
Required Evidence:
Evidence Source:
Expected State:
Observed State:
Verification Status:
Mismatch:
Corrective Action:
Reviewer:
Verified At:
Rule
Technical execution and business completion are separate states.
- Cross Tool Consistency Check
Purpose
Where one agent uses multiple tools, the agent must confirm that the results agree before reporting completion or routing downstream.
Cross Tool Consistency Checks May Include
calendar time matches email confirmation
lead identity matches CRM record
task project matches Project Manager Brain
document link matches stored record
client identity matches workspace
public research matches approved company context
tool output matches final response
created record status matches workflow state
recipient matches approved contact
currency and amount match approved commercial terms
Cross Tool Consistency Check Fields
Tool A:
Tool A Result:
Tool B:
Tool B Result:
Compared Fields:
Expected Match:
Observed Match:
Mismatch Type:
Risk:
Resolution:
Final Status:
Mismatch Status Values
Consistent
Minor Mismatch
Material Mismatch
Critical Mismatch
Unable To Verify
Rule
A material mismatch must block completion until corrected or escalated.
- Validation Layer
Generated output must be validated before it moves forward.
Validation may include:
schema validation
required field validation
type validation
allowed value validation
cross field validation
semantic validation
business rule validation
source validation
authority validation
duplicate action validation
tool input validation
tool result validation
business outcome validation
cross tool consistency validation
prompt chain consistency validation
transcription confidence validation
Visual and media outputs may also require:
generated text validation
logo accuracy validation
brand validation
composition validation
reference asset rights validation
likeness validation
voice validation
disclosure validation
claim validation
Validation Result Values
Valid
Invalid
Needs Repair
Needs Human Review
Blocked
Validation must distinguish:
format failure
missing data
unsupported claim
wrong classification
wrong client
wrong workspace
wrong authority
unsafe action
unverifiable output
invalid tool input
tool failure
partial tool success
business outcome not verified
cross tool mismatch
uncertain critical transcription field
invalid visual text
inaccurate logo
unapproved likeness or voice
missing disclosure
Rule
Passing a parser does not prove that the meaning is correct.
- Repair Retry And Fallback Layer
Invalid output must not flow forward merely because generation completed.
Repair Rules
A repair prompt may correct:
formatting
missing required fields where the source value exists
invalid labels
schema shape
field ordering
escaping
minor structural errors
A repair prompt must not silently change:
meaning
claims
evidence
approval
authority
commercial commitments
legal interpretation
record identity
client identity
workspace identity
tool target
recipient
dates
amounts
likeness permission
voice permission
logo permission
disclosure requirements
Retry Rules
A retry should receive useful failure information.
A retry may include:
validation errors
missing fields
invalid values
required format
failed quality criteria
tool error status
cross tool mismatch details
transcription uncertainty
A retry limit must be defined.
Repeated blind retries are not a reliability strategy.
A retry must not repeat a state changing tool action unless prior execution has been checked.
Fallback Rules
Fallback may include:
different approved model
simpler output
manual review
human completion
workflow stop
safe default route
read only route
draft only route
A fallback must not increase authority or bypass governance.
Rule
Invalid output must stop, repair, retry, fall back, or escalate according to defined rules.
- Model Selection And Testing Layer
Model selection should be based on task requirements.
Test for:
quality
instruction following
structured output consistency
reasoning suitability
vision capability where required
image or video generation capability where required
transcription capability where required
cost
latency
context capacity
tool use reliability
tool selection reliability
tool input accuracy
tool result interpretation
failure behaviour
provider availability
safety behaviour
Do not select a model only because:
it is fashionable
it produced one good example
it has the largest parameter count
it is the default in a tool
Testing should use:
normal inputs
missing inputs
ambiguous inputs
edge cases
malicious or instruction like inputs
long inputs
conflicting context
invalid source data
realistic production data
multiple similar tools
no suitable tool cases
missing approval cases
duplicate action risks
partial tool success
conflicting tool results
uncertain transcription
brand sensitive visual requests
visuals containing required text
logo bearing visuals
reference asset prompts
likeness or voice requests
Rule
The chosen model must be tested for the actual task, agent contract, tool set, and output contract.
- Prompt Simplification And Efficiency Layer
Longer prompts are not automatically better.
Review for:
duplicated instructions
conflicting rules
irrelevant background
unnecessary role language
excessive examples
repeated output instructions
avoidable chain stages
inflated wording
duplicated tool descriptions
overlapping tool access
unused context
Simplification must not remove:
critical constraints
authority boundaries
input contracts
tool selection rules
tool input contracts
tool result contracts
business outcome checks
output contracts
validation rules
failure handling
approval gates
Rule
Keep the simplest prompt architecture that performs reliably.
- Observability And Versioning Layer
Important prompts need metadata, logging, versioning, and review.
Prompt Metadata Fields
Prompt Name:
Prompt Version:
Brain Or AI Employee:
Agent Name:
Agent Version:
Workflow:
Prompt Type:
Generation Method:
Model Used:
Provider:
Input Variables:
Context Sources:
Memory Sources:
Available Tools:
Tool Description Versions:
Output Contract:
Schema Version:
Validation Rules:
Repair Prompt Version:
Retry Limit:
Fallback Route:
Test Status:
Average Cost:
Average Latency:
Valid Output Rate:
Tool Selection Accuracy:
Tool Input Validation Rate:
Tool Success Rate:
Business Outcome Verification Rate:
Cross Tool Consistency Rate:
Repair Rate:
Retry Rate:
Human Correction Rate:
Failure Modes:
Last Reviewed:
Owner:
Change Notes:
Runtime Trace Fields
Task ID:
Workflow ID:
Agent Version:
Prompt Version:
Template Version:
Model:
Provider:
Input Record IDs:
Context Record IDs:
Memory Record IDs:
Reference Asset IDs:
Tool Descriptions Loaded:
Tool Selected:
Tool Selection Reason:
Tool Input Validation:
Idempotency Key:
Prior Execution Check:
Tool Call Requested:
Tool Call Accepted:
Tool Action Result:
Tool Call ID:
Tool Returned Record IDs:
Business Outcome Status:
Business Outcome Evidence:
Cross Tool Consistency Result:
Output Status:
Validation Result:
Validation Errors:
Repair Attempted:
Retry Count:
Fallback Used:
Human Review:
Approval Status:
Selected Output ID:
Final Storage Location:
Outcome:
Rule
A production prompt should be traceable from input to outcome.
Prompt Versioning Standard
Create a new version when changing:
task purpose
agent role
agent autonomy
input contract
context source
memory source
authority
important instructions
available tools
tool descriptions
tool selection rules
tool input contract
tool result contract
business outcome verification
examples
output contract
schema
template
model
provider
validation
repair behaviour
retry behaviour
fallback
visual composition requirements
controlled variables
prohibited elements
reference asset handling
voice transcription rules
runtime instruction boundary
A formatting correction that affects downstream parsing should still be versioned.
- Human Review And Governance Layer
Human review may be required where prompts affect:
external communication
financial decisions
legal or compliance interpretation
medical or safety matters
client commitments
pricing
scope
production data
destructive actions
public claims
high value recommendations
brand assets
logos
likeness
voice
synthetic media
regulated claims
disclosures
appointments
payments
access permissions
publication
Human Review Should Examine
task alignment
input completeness
source evidence
output meaning
schema result
confidence
risk
authority
recommended action
tool selection
tool input
tool request
tool result
business outcome
cross tool consistency
brand accuracy
visual text accuracy
logo accuracy
reference asset use
likeness or voice permission
disclosure status
candidate selection
Human review must not be a blind approval button.
The reviewer should see enough evidence to understand what is being approved.
Governance Ownership
HeadOffice owns cross system prompt governance.
The relevant Brain owns task specific prompt quality.
Prompting Framework owns prompt architecture standards.
Automation Brain owns workflow reliability.
Data Brain owns structured output integrity.
AI Agent Operations Core owns agent operating controls.
SIT Brain supports independent review and rescue.
Experimentation Brain supports prompt and model testing.
Compliance and Risk Brains review sensitive prompt systems.
- Voice Transcription Input Contract
Purpose
The Voice Transcription Input Contract governs audio or spoken input that is converted into text and then used by a prompt, AI Employee, agent, workflow, record, decision, or tool action.
A transcript is not automatically reliable merely because transcription completed.
Voice Transcription Input Contract Fields
Audio Source:
Audio Record ID:
Speaker Identity:
Speaker Identity Confidence:
Recording Permission:
Transcription Model:
Model Version:
Detected Language:
Language Confidence:
Transcription Confidence:
Uncertain Words:
Uncertain Segments:
Critical Fields:
Original Audio Reference:
Raw Transcript:
Corrected Transcript:
Correction Source:
User Confirmed Meaning:
Confirmation Status:
Sensitive Data Classification:
Allowed Downstream Use:
Retention Rule:
Critical Fields
Critical fields may include:
names
dates
times
amounts
currencies
email addresses
telephone numbers
addresses
record identifiers
project names
company names
approvals
permissions
commitments
destructive instructions
publication instructions
Critical Field Rule
A critical field must not be routed into a state changing action when transcription confidence is insufficient.
The agent must:
identify the uncertain field
retain the original audio reference where permitted
show the interpreted value
request confirmation where required
record the confirmed value
preserve the correction history
Transcript Correction Rule
The corrected transcript must not silently replace the original transcript.
Both should remain traceable where governance requires.
Meaning Confirmation Rule
Where exact wording is uncertain but intended meaning can be confirmed, record:
original wording
uncertain interpretation
confirmed meaning
confirming person
confirmation time
Rule
Transcribed text is input data.
It is not authority beyond the authority of the verified speaker and approved workflow.
- Additional Runtime Instructions Boundary
Purpose
Many agent workflows combine a stable base prompt with task specific runtime instructions.
The boundary between these layers must be governed.
Base Prompt Must Contain
stable role
operating purpose
governing authority
autonomy level
permissions
prohibitions
tool selection rules
output contract
validation
failure rules
stop conditions
escalation rules
Runtime Instructions May Contain
task specific variables
current record identifiers
approved client or workspace
current target
current date or campaign
approved context references
requested output parameters
current workflow state
Runtime Instructions Must Not
increase authority
increase autonomy
add prohibited tools
remove approval requirements
override stop conditions
override privacy boundaries
override client isolation
override output validation
convert untrusted text into system instructions
change the agent role
create a new business rule
Untrusted Runtime Text Rule
User supplied, scraped, retrieved, emailed, transcribed, or third party text must not be inserted into the system instruction layer as governing instruction.
Material Runtime Rule Promotion
When a runtime instruction becomes:
repeated
material to reliability
material to authority
material to output structure
material to tool selection
material to validation
it should be reviewed and either:
promoted into the approved base prompt
promoted into an approved template
promoted into a governed workflow rule
rejected
The promoted rule must be versioned.
Rule
Runtime instructions may narrow a task.
They must not widen authority.
- Specialist Prompt Chain Consistency
Purpose
Complex agent workflows may use separate specialist prompts for:
classification
extraction
research
fact checking
qualification
drafting
call to action generation
appointment action
record creation
final response
All specialist prompts in one workflow must operate from a consistent approved context packet.
Shared Context Requirements
Context Packet ID:
Client ID:
Workspace ID:
Task ID:
Workflow ID:
Source Record IDs:
Approved Facts:
Approved Claims:
Approved Offer:
Approved Audience:
Approved Brand Rules:
Approved Dates:
Approved Amounts:
Approved Contact Details:
Authority Status:
Approval Status:
Context Version:
Cross Stage Consistency Requirements
Each stage must preserve:
client identity
workspace identity
record identity
source identifiers
approved facts
approved dates
approved amounts
approved names
approved contact details
authority boundaries
approval status
workflow purpose
Specialist Handoff Contract
Stage Name:
Stage Purpose:
Input Record:
Input Context Version:
Required Fields:
Allowed Transformations:
Prohibited Transformations:
Output Contract:
Output Record ID:
Validation Result:
Next Stage:
Handoff Status:
Drift Detection
A specialist stage must not:
change an approved fact without evidence
change an amount
change a date
change a recipient
change a company
change a claim
change authority
change approval status
change the requested outcome
When a difference is detected, the workflow must identify whether it is:
a valid correction supported by evidence
an approved transformation
a formatting change
an unsupported drift
Rule
Prompt chains must preserve factual, operational, and authority consistency from first input to final outcome.
- Visual Prompt Contract
Purpose
The Visual Prompt Contract extends the existing prompt architecture for image, video, animation, avatar, synthetic media, personalised visual sales asset, social creative, ad creative, presentation visual, thumbnail, product visual, and other generated media workflows.
It does not replace the general input, authority, validation, observability, versioning, or human review controls in this framework.
It applies those controls to the specific failure modes of visual generation.
A Visual Prompt Contract must be created whenever a visual generation prompt is intended for repeated, automated, client facing, commercial, public, personalised, branded, or synthetic media use.
Visual Prompt Contract Fields
Asset Type:
Commercial Or Content Objective:
Recipient Or Audience:
Scene:
Subject:
Brand Or Company:
Permitted Logo:
Required Text:
Composition:
Visual Hierarchy:
Style:
Aspect Ratio:
Resolution:
Reference Asset:
Reference Asset Rights Or Source:
Fixed Elements:
Dynamic Variables:
Controlled Variables:
Prohibited Elements:
Negative Instructions:
Likeness Permission:
Voice Permission Where Applicable:
Disclosure Requirement:
Output Count:
Candidate Selection Rule:
Accuracy Criteria:
Quality Criteria:
Brand Criteria:
Originality Criteria:
Human Review Requirement:
Approval Status:
Prompt Version:
Template Version:
Model And Provider:
Supporting Trace Fields
Task ID:
Campaign ID:
Client ID:
Recipient Record ID Where Applicable:
Input Record IDs:
Reference Asset IDs:
Source URLs:
Generated Candidate IDs:
Selected Candidate ID:
Validation Result:
Validation Errors:
Reviewer:
Approval Date:
Final Delivery Status:
Fixed Structure And Dynamic Variable Separation
The stable visual prompt structure must be separated from dynamic recipient, campaign, offer, location, company, product, event, or content variables.
Fixed structure may include:
asset purpose
approved composition logic
visual hierarchy
brand constraints
required validation
negative instructions
output count
candidate selection rule
human review rule
approval requirement
Dynamic variables may include:
recipient name
company name
industry
location
campaign
product
offer
approved message
approved logo reference
approved scene detail
approved call to action
Only variables explicitly listed in the contract may be populated automatically.
A variable must define:
field name
source
data type
allowed values or pattern
required or optional status
trust level
validation rule
missing input behaviour
A workflow must not convert arbitrary scraped text into prompt instructions.
Rule
Fixed prompt architecture must remain governed.
Dynamic data must remain bounded.
Approved Variable Population Rule
Only approved variables may be populated automatically.
Automatic population must not authorise:
new claims
new required text
new logos
new brand treatment
new likeness
new voice
new disclosures
new delivery authority
Website And External Content Rule
Website content, scraped content, imported descriptions, social content, reviews, metadata, and retrieved text may supply facts or candidate variables only after the relevant extraction, source, validation, and permission controls have been applied.
Such content must not:
override the Visual Prompt Contract
alter fixed elements
introduce new instructions
remove prohibited elements
waive approval
authorise logo use
authorise likeness or voice
authorise a claim
authorise delivery
Rule
External content is data.
It is not prompt authority.
Generated Text Validation
Where generated media contains text, validate:
spelling
names
company names
dates
amounts
contact details
calls to action
legal or compliance wording
brand terminology
language
readability
placement
Generated text must not be accepted solely because the asset looks visually strong.
Logo Validation
A logo must be:
the correct logo
the approved version
used with permission
rendered accurately
placed according to brand rules
free from deceptive alteration
A model generated approximation must not be treated as an approved logo.
Reference Asset Governance
Reference assets may guide:
composition
layout
style direction
colour direction
pose
camera framing
product presentation
They must not be used to:
copy protected creative deceptively
imply ownership
create unapproved likeness
reproduce a competitor’s distinctive asset
bypass licensing
Reference assets may guide composition and pattern.
They do not automatically grant copying rights.
Candidate Generation And Selection
A Visual Prompt Contract may request multiple candidates.
Output Count must define the number of candidates permitted or required.
Candidate Selection Rule must define:
who or what may shortlist
selection criteria
minimum validation status
whether human selection is mandatory
whether client approval is required
how the selected candidate is recorded
Successful generation does not mean approved output.
Synthetic Media Authority Boundary
Prompt automation must not authorise:
likeness use
voice use
logo use
disclosure waiver
claim approval
external sending
publication
Traceability Standard
The following must be traceable for each governed visual asset:
prompt
prompt version
template version
model
provider
fixed prompt structure
dynamic inputs
controlled variables
reference assets
reference asset source or rights status
generated candidates
validation results
selected candidate
human reviewer where required
approval status
final delivered or published output
Where an asset changes after approval, the changed asset must receive the appropriate new version, validation, and approval status.
Asset Governance Handoff
The Visual Prompt Contract governs prompt and generation reliability.
The relevant asset governance framework governs whether the resulting asset is suitable, permitted, approved, and ready for its intended use.
Rule
Generation success is not delivery authority.
- Preflight Checklist
Before deploying a governed production prompt, confirm:
Purpose
purpose defined
owner defined
workflow defined
caller defined
trigger defined
prohibited purpose expansion defined
Inputs
required inputs defined
data types defined
record identifiers defined
client and workspace defined
missing input behaviour defined
untrusted input separated
Context And Memory
context sources approved
context current
memory sources approved
client isolation confirmed
source record IDs available
conflict rules defined
Authority
autonomy level defined
allowed decisions defined
prohibited decisions defined
tool permissions defined
approval requirements defined
external communication authority defined
state changing authority defined
stop conditions defined
Agent Contract
agent role defined
operating purpose defined
available tools defined
tool selection rules defined
decision scope defined
evidence requirements defined
handoff defined
escalation defined
Tools
each tool has a Tool Description Contract
Use When defined
Do Not Use When defined
side effects defined
read or write status defined
permission requirement defined
approval requirement defined
duplicate execution risk defined
example valid and invalid calls defined
Tool Inputs
required fields defined
types defined
identifiers defined
target defined
date and timezone defined where required
maximum scope defined
idempotency or prior execution check defined
approval evidence defined
Tool Results
technical status values defined
partial success behaviour defined
business outcome requirement defined
business outcome evidence defined
cross tool consistency checks defined
Outputs
output format defined
required fields defined
allowed labels defined
null behaviour defined
unknown value behaviour defined
evidence fields defined
uncertainty fields defined
handoff fields defined
Validation
schema validation defined
semantic validation defined
authority validation defined
tool input validation defined
tool result validation defined
business outcome validation defined
cross tool consistency validation defined
prompt chain consistency defined
Repair And Recovery
repair rules defined
retry limit defined
duplicate state change protection defined
fallback defined
escalation defined
Voice Transcription
audio source defined where applicable
transcription model recorded
confidence recorded
uncertain words recorded
critical fields defined
confirmation requirement defined
original audio reference retained where permitted
corrected transcript traceable
Runtime Instructions
base prompt boundary defined
runtime variable boundary defined
authority increase prohibited
untrusted text excluded from system instructions
material runtime rules subject to promotion and versioning
Visual Contract
asset purpose defined
fixed and dynamic elements separated
approved variables defined
generated text validation defined
logo validation defined
reference asset rights recorded
likeness permission recorded
voice permission recorded where applicable
disclosure requirement defined
output count defined
candidate selection rule defined
human review requirement defined
approval status defined
selected output traceable
asset governance handoff defined
Governance
prompt version recorded
agent version recorded
tool description versions recorded
schema version recorded
template version recorded
model and provider recorded
owner recorded
review date recorded
change notes recorded
human approval recorded where required
Runtime
task ID recorded
workflow ID recorded
input record IDs recorded
context record IDs recorded
memory record IDs recorded
tool selected recorded
tool input validation recorded
tool result recorded
business outcome recorded
cross tool consistency recorded
validation result recorded
repair attempt recorded
retry count recorded
fallback recorded
selected output recorded where applicable
final storage location recorded
outcome recorded
- Prompt Asset Record
Each governed prompt should maintain a Prompt Asset Record containing:
Prompt Name
Prompt ID
Prompt Version
Agent Name Where Applicable
Agent Version Where Applicable
Owning Brain
Owning AI Employee
Purpose
Workflow
Caller
Trigger
Inputs
Context Sources
Memory Sources
Authority
Guidelines
Constraints
Examples
Chain Position
Available Tools
Tool Description Versions
Tool Selection Rules
Tool Input Contract
Tool Result Contract
Business Outcome Requirement
Output Contract
Allowed Labels
Schema
Validation Rules
Model
Provider Where Applicable
Test Inputs
Quality Criteria
Repair Rules
Retry Limit
Fallback
Stop Conditions
Escalation
Human Review Requirement
Cost Notes
Latency Notes
Failure Modes
Observability
Last Reviewed Date
A governed visual generation prompt must additionally define the applicable Visual Prompt Contract fields and must remain subject to the relevant asset governance framework.
A governed voice input workflow must additionally define the applicable Voice Transcription Input Contract fields.
- Recommended AI Employee And Agent Roles
Prompt Architecture Reviewer
Primary Brain: Prompting Framework
Purpose:
Reviews prompt purpose, structure, authority, input contracts, agent contracts, tool contracts, output contracts, and governance.
Prompt Chain Designer
Primary Brain: Prompting Framework / Automation Brain
Purpose:
Breaks complex tasks into controlled prompt stages with explicit handoffs and shared context identifiers.
Agent Prompt Contract Reviewer
Primary Brain: Prompting Framework / AI Agent Operations Core
Purpose:
Reviews agent role, purpose, autonomy, decision scope, tools, stop conditions, escalation, and outcome reporting.
Tool Description Contract Reviewer
Primary Brain: Automation Brain / Prompting Framework
Purpose:
Reviews tool purpose, selection conditions, side effects, permissions, inputs, outputs, duplicate execution risks, and failure behaviour.
Tool Selection Evaluator
Primary Brain: Experimentation Brain / Prompting Framework
Purpose:
Tests whether agents choose the minimum necessary suitable tool and stop when no suitable tool exists.
Tool Input Validation Reviewer
Primary Brain: Data Brain / Automation Brain
Purpose:
Reviews identifiers, data types, targets, scope, approval, idempotency, and evidence before tool execution.
Tool Result And Outcome Reviewer
Primary Brain: Automation Brain / HeadOffice Brain
Purpose:
Distinguishes technical tool success from verified business outcome.
Cross Tool Consistency Reviewer
Primary Brain: Data Brain / Automation Brain
Purpose:
Checks that results from multiple tools agree before completion.
Voice Transcription Reliability Reviewer
Primary Brain: Prompting Framework / Data Brain
Purpose:
Reviews transcription confidence, critical fields, correction history, and confirmation requirements.
Prompt Quality Evaluator
Primary Brain: Prompting Framework / Experimentation Brain
Purpose:
Scores output quality, consistency, schema validity, tool behaviour, and workflow suitability.
Prompt Cost And Latency Analyst
Primary Brain: Finance Brain / Prompting Framework
Purpose:
Measures cost, latency, repair cost, retry cost, tool cost, and cost per accepted output.
Specialist Knowledge Injector
Primary Brain: Research Brain / Prompting Framework
Purpose:
Identifies approved knowledge required for a prompt.
Prompt Observability Steward
Primary Brain: Data Brain / Prompting Framework
Purpose:
Tracks prompt versions, models, tools, outputs, validation, retries, repairs, cost, and acceptance.
AI Employee Prompt Reviewer
Primary Brain: AI Employee Canon / Prompting Framework
Purpose:
Reviews role prompts, task prompts, tool prompts, and failure rules.
Prompt Failure Mode Analyst
Primary Brain: Prompting Framework / Risk Brain
Purpose:
Identifies recurring failures and recommends corrections.
Model Selection Tester
Primary Brain: Experimentation Brain / Prompting Framework
Purpose:
Tests models for quality, structure, cost, latency, transcription, tool selection, and result interpretation.
Prompt Asset Librarian
Primary Brain: Prompting Framework / Data Brain
Purpose:
Maintains prompt assets, schemas, tool descriptions, test records, and versions.
Meta Prompt Drafting Assistant
Primary Brain: Prompting Framework
Purpose:
Creates structured first draft prompts.
Prompt Simplification Reviewer
Primary Brain: Prompting Framework / Automation Brain
Purpose:
Removes prompt bloat and conflicting instructions.
Structured Output Contract Reviewer
Primary Brain: Data Brain / Prompting Framework
Purpose:
Reviews output fields, labels, types, null behaviour, and downstream compatibility.
Prompt Repair And Recovery Reviewer
Primary Brain: Automation Brain / SIT Brain
Purpose:
Reviews repair prompts, retry limits, fallbacks, and recovery safety.
Visual Prompt Contract Reviewer
Primary Brain: Prompting Framework / Content Brain / Ads Brain
Purpose:
Reviews fixed structure, approved variables, generated text, logo accuracy, reference assets, permissions, disclosures, candidate selection, validation, and approval routing for generated visual assets.
- Drift Protection
This framework protects MWMS from:
treating prompts as casual messages
building automation on vague prompts
relying on one successful output
accepting AI generated prompts without testing
assuming longer prompts are better
ignoring prompt failures
not versioning prompts
allowing prompts to invent authority
allowing runtime instructions to increase authority
allowing untrusted text to become system instruction
allowing agents to call tools merely because they are available
allowing agents to invent tool capabilities
allowing state changing tool calls to repeat blindly
treating a successful API call as a completed business outcome
allowing conflicting tool results to pass
using uncertain transcription for critical actions
allowing specialist prompt stages to drift from shared facts
treating generated visuals as approved assets
allowing prompt automation to authorise likeness, voice, logo, claims, delivery, or publication
Drift Signals
“We can let the agent work it out.”
“The tool is available, so it can use it.”
“The API returned success, so the job is done.”
“The runtime prompt can override that.”
“The transcript is probably right.”
“The next specialist prompt can fix it.”
“The output is structured, so it must be correct.”
“We do not need to record the tool result.”
“We do not need to check whether the action already happened.”
“We can approve the generated asset later.”
Rule
When these drift signals appear, return to purpose, input contracts, context, memory, authority, Agent Prompt Contract controls, Tool Description Contract controls, tool selection, tool input validation, tool result status, business outcome verification, cross tool consistency, Voice Transcription Input Contract controls, runtime instruction boundaries, prompt chain consistency, output contracts, validation, controlled repair, retry limits, fallback safety, observability, Visual Prompt Contract controls, asset governance, and explicit approval.
- Implementation Sequence
Phase 1: Identify The Prompt Asset
Define:
purpose
owner
workflow
caller
trigger
output
risk
Phase 2: Define Contracts
Create:
input contract
context contract
memory contract where applicable
authority contract
Agent Prompt Contract where applicable
Tool Description Contracts where applicable
Tool Input Contract where applicable
output contract
Tool Result Contract where applicable
Voice Transcription Input Contract where applicable
Visual Prompt Contract where applicable
Phase 3: Define Validation And Recovery
Define:
schema validation
semantic validation
authority validation
tool validation
business outcome verification
cross tool consistency
repair
retry
fallback
stop
escalation
Phase 4: Test
Test:
normal input
missing input
ambiguous input
wrong client
wrong workspace
prompt injection
no suitable tool
similar tools
missing authority
duplicate state change
partial tool success
tool conflict
uncertain transcription
specialist chain drift
visual text errors
logo errors
approval failures
Phase 5: Deploy With Observability
Record:
prompt version
agent version
tool description versions
model
provider
inputs
context
memory
tool selection
tool calls
tool results
business outcome
validation
repair
retry
fallback
human review
final outcome
Phase 6: Review And Improve
Review:
failure modes
tool selection errors
duplicate action risks
unverified outcomes
cross tool mismatches
transcription corrections
prompt chain drift
human corrections
cost
latency
output quality
governance adherence
- Change Log
v1.4
Date: 2026-06-27
Update Type: Focused Agent And Tool Reliability Expansion
Preserved the existing prompt architecture, input contract, context, authority, output contract, schema validation, repair, retry, fallback, model testing, observability, versioning, human review, and Visual Prompt Contract controls.
Added Agent Prompt Contract fields covering:
Agent Role
Operating Purpose
Owning Brain
Caller
Trigger
Input Contract
Context Sources
Memory Sources
Available Tools
Tool Selection Rules
Decision Scope
Prohibited Decisions
Action Autonomy Level
Evidence Requirements
Output Contract
Tool Result Contract
Handoff Destination
Stop Conditions
Escalation Rule
Added Tool Description Contract controls covering:
Tool Name
Purpose
Use When
Do Not Use When
Required Inputs
Optional Inputs
Output
Side Effects
Read Or Write
Permission Requirement
Approval Requirement
Failure Result
Duplicate Execution Risk
Example Valid Call
Example Invalid Call
Added explicit Tool Selection Instructions requiring agents to:
choose the minimum necessary tool
avoid unnecessary tool calls
avoid inventing tools or capabilities
avoid prohibited tools
avoid repeating state changing calls without prior execution checks
stop when no suitable tool exists
return structured uncertainty
route for approval when authority is missing
Added Tool Input Contract controls covering:
required fields
data types
record identifiers
client and workspace
date and timezone
recipient or target
requested action
idempotency key
approval status
source evidence
maximum scope
Added Tool Result Contract status distinctions covering:
Tool Call Requested
Tool Call Accepted
Tool Call Succeeded
Tool Call Failed
Tool Call Partially Succeeded
Business Outcome Verified
Business Outcome Not Verified
Added Business Outcome Verification controls separating technical execution from business completion.
Added Cross Tool Consistency Check controls requiring agreement between related tool results before completion.
Added Voice Transcription Input Contract controls covering:
audio source
transcription model
transcription confidence
detected language
uncertain words
critical fields
confirmation requirement
original audio reference
corrected transcript
user confirmed meaning
Added Additional Runtime Instructions Boundary controls establishing that:
the base prompt contains stable role and governance
runtime instructions contain task specific variables
runtime instructions must not increase authority
runtime instructions must not override prohibitions
untrusted text must not be inserted into governing system instructions
material runtime rules must be versioned or promoted into an approved prompt or template
Added Specialist Prompt Chain Consistency controls requiring shared approved context, source identifiers, factual consistency, authority consistency, and explicit handoff contracts across agent workflow stages.
Change Impact Declaration
This is a focused additive governance update.
It does not replace the existing framework architecture.
It does not remove or weaken any existing prompt, validation, authority, recovery, testing, observability, visual generation, or approval control.
It extends the existing framework into governed agent prompt architecture, tool description and selection control, tool input and result reliability, business outcome verification, cross tool consistency, voice transcription reliability, runtime instruction authority boundaries, and specialist prompt chain consistency.
Pages Created
None.
Pages Updated
MWMS Prompt Architecture And Automation Output Reliability Framework updated from v1.3 to v1.4.
Pages Deprecated
None.
Standalone Pages Not Created
MWMS Agent Prompt Contract Framework
MWMS Tool Description Contract Standard
MWMS Tool Selection Instruction Standard
MWMS Tool Input Contract Standard
MWMS Tool Result Contract Standard
MWMS Business Outcome Verification Framework
MWMS Cross Tool Consistency Framework
MWMS Voice Transcription Input Contract Framework
MWMS Runtime Instruction Authority Boundary Framework
MWMS Specialist Prompt Chain Consistency Framework
These were not created because the missing intelligence belongs inside the existing MWMS Prompt Architecture And Automation Output Reliability Framework and its related agent, tool permission, automation, memory, observability, and workflow governance pages.
Registries Requiring Update
Prompting Framework Page Registry
MCR Page Registry
MCR Copy Map where the framework version is recorded
MWMS Course Absorption Decision Registry
Canon Version Update Required
No immediate Prompting Framework Canon or HeadOffice Canon version change is required unless either directly records this framework version or contains agent prompt, tool selection, runtime instruction, transcription, or prompt chain rules that conflict with v1.4.
The Agent Prompt Contract, Tool Description Contract, Tool Selection Instructions, Tool Input Contract, Tool Result Contract, Business Outcome Verification, Cross Tool Consistency Check, Voice Transcription Input Contract, Runtime Instruction Authority Boundary, and Specialist Prompt Chain Consistency controls should be included during the next scheduled Prompting Framework, HeadOffice, AI Agent Operations Core, Automation Brain, and relevant Brain alignment review.
Change Log Entry Required
Yes.
The v1.4 update must be recorded in:
MWMS System Change Log
Prompting Framework Page Registry change history where applicable
MCR Page Registry change history where applicable
MWMS Course Absorption Decision Registry
Strategic Absorption Result
The remaining AI agent, tool selection, runtime instruction, voice transcription, and specialist workflow material has been absorbed into the existing MWMS Prompt Architecture And Automation Output Reliability Framework without creating duplicate standalone pages or platform specific tool instructions.
The update converts agent prompting from a broad instruction and output model into a governed operating contract that defines the agent’s role, purpose, caller, trigger, inputs, context, memory, tools, tool selection rules, decision scope, autonomy, evidence, outputs, tool results, stop conditions, escalation, and handoff.
It establishes that every agent accessible tool requires a clear Tool Description Contract, every state changing call requires validated inputs and duplicate execution control, every returned tool result must be distinguished from the intended business outcome, and multi tool workflows must pass cross tool consistency checks.
It also establishes that voice transcription is an uncertain input source requiring confidence, critical field, correction, and confirmation controls; runtime instructions may narrow tasks but cannot widen authority; and specialist prompt chains must preserve the same approved context, facts, identifiers, permissions, and workflow purpose from first stage to final outcome.
The resulting framework now governs prompts as:
purpose defined
input contracted
context controlled
memory bounded
authority limited
agent contracted where applicable
tool described
tool selection controlled
tool input validated
output contracted
tool result distinguished
business outcome verified
cross tool checked
schema validated
semantically reviewed
transcription controlled where applicable
runtime authority bounded
prompt chain consistent
repair controlled
retry limited
fallback safe
human reviewable
visual contract governed where applicable
asset governance linked
observable
versioned
continuously improved
END OF FULL FILE OUTPUT