System: MWMS
Document Type: Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: AIBS Brain, HeadOffice Brain, AI Manager, AI Employee Router, Brain Room, Client Brain Systems, Offer Brain, Content Brain, Sales Brain, Creative Brain, Research Brain, Compliance Brain, Future AIBS Client Systems
Parent Page: AIBS Brain
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR
Purpose
The purpose of this document is to define the AIBS Brain Client AI System Package Structure Standard.
This standard establishes the core package structure MWMS should use when preparing, selling, building, reviewing, and maintaining future client-facing AI Business Systems.
AIBS client systems must not be sold or delivered as random prompt packs, tool setups, generic automations, or one-off AI experiments.
A client AI system package must be built from structured business intelligence.
The package must clearly define:
the client business context
the client offer
the right-fit buyer
the client voice
the client proof
the client objections
the client workflows
the client AI skills
the client approval rules
the client reporting structure
the client audit and maintenance path
This standard exists to make future AIBS client delivery structured, repeatable, governable, and commercially packageable.
Without this standard, MWMS risks:
unclear client deliverables
overbuilding before client context is ready
selling AI tools instead of AI business systems
mixing strategy, context, skills, reports, and automation without structure
building client systems from incomplete intake
creating client outputs without approval gates
failing to define what is included and not included
making future AIBS delivery hard to repeat
creating client systems that are difficult to maintain
This standard defines the package spine for future AIBS client systems.
Scope
This standard applies to all future MWMS client-facing AI Business System packages, client Brain systems, client context libraries, client AI Employee packages, client skill systems, client reporting systems, and client workflow support systems.
This includes:
AIBS Brain
HeadOffice Brain
AI Manager
AI Employee Router
Brain Room
Client Brain Systems
Offer Brain
Content Brain
Creative Brain
Sales Brain
Conversion Brain
Research Brain
Compliance Brain
future AIBS client systems
This standard applies when MWMS is preparing or delivering:
client AI system setup
client Brain build
client context library
client offer intelligence package
client content system
client sales support system
client reporting system
client workflow assistant system
client AI skill package
client approval and review system
client audit and maintenance package
This standard does not authorize technical development, plugin changes, Supabase changes, WordPress changes, automation wiring, software setup, publishing, credential handling, client implementation, or M developer action.
Core Definition
A Client AI System Package is a structured set of client-specific context files, AI workflow rules, skill candidates, review gates, reporting standards, and maintenance processes that allow AI Employees or AI-assisted workflows to support a client’s business more reliably.
A Client AI System Package is not:
a prompt pack
a chatbot only
a tool stack only
a folder of uploaded files
a generic automation
a one-off AI setup
a random collection of documents
a replacement for client judgment
A Client AI System Package is:
a governed client-specific intelligence layer
a structured context library
a workflow support system
a skill-ready operating base
a review-controlled AI output system
a future recurring maintenance asset
Core Principle
The core principle of this standard is:
AIBS packages must be built around business context, not AI tools.
Tools may support the system.
Automations may later extend the system.
But the core package is the client’s structured business intelligence.
If the client context is weak, the AI system will be weak.
If the package structure is clear, MWMS can deliver client value more consistently.
Package Structure Overview
A standard AIBS client AI system package may include ten core layers.
Layer 1: Client Business Snapshot
Layer 2: Client Offer And Buyer Foundation
Layer 3: Client Voice And Brand Language
Layer 4: Client Differentiation, Objections, And Proof
Layer 5: Client Methodology And Expert Thinking
Layer 6: Client Workflow Map
Layer 7: Client AI Skill Package
Layer 8: Client Asset And Output System
Layer 9: Client Approval, Privacy, And Review Gates
Layer 10: Client Audit, Reporting, And Maintenance System
Not every client requires every layer on day one.
However, full AIBS packages should move toward this structure over time.
Layer 1: Client Business Snapshot
Purpose
The Client Business Snapshot defines the client’s business context before any deeper AI system work begins.
It gives MWMS and future AI Employees a clear overview of the client’s business model, priorities, constraints, current systems, and intended AI use.
This layer prevents MWMS from building AI systems without understanding the business.
Included Components
Client Business Snapshot
Client Current Business Model
Client Revenue Streams
Client Main Business Goal
Client Current Bottlenecks
Client Current Tool Stack
Client Current Repeating Workflows
Client AI Opportunity Areas
Client Human Approval Boundaries
Client Risk Notes
Required Questions
What does the client business do?
Who does the client serve?
What does the client sell?
What is the main business goal?
What currently takes too much time?
What work repeats regularly?
What work depends too heavily on the owner or team?
What tools are currently used?
What should AI not touch?
What requires human review?
Output
The output of this layer is a clear client business summary that supports scope, context creation, workflow mapping, and package design.
Layer 1 Drift Risks
Do not begin with AI tools before business context.
Do not assume the client needs automation before process clarity.
Do not treat vague business descriptions as enough for system design.
Layer 2: Client Offer And Buyer Foundation
Purpose
The Client Offer And Buyer Foundation defines the client’s primary offer and the right-fit buyer for that offer.
This layer prevents AI Employees from creating content, sales assets, reports, or recommendations for vague audiences or unclear offers.
Included Components
Client Right-Fit Client Profile
Client Offer Profile
Client Buyer-Offer Fit Summary
Client Good-Fit And Bad-Fit Buyer Notes
Client Buying Trigger Notes
Client False Belief Notes
Client Trust Barrier Notes
Client Next-Step Logic
Required Questions
What is the client’s primary offer?
Who is the offer for?
What problem does the offer solve?
What outcome does the buyer want?
What does the buyer currently believe?
What makes the buyer hesitate?
What is included in the offer?
What is not included?
What should the buyer do next?
What kind of buyer is not a fit?
Output
The output of this layer is the buyer-offer foundation that all future client AI outputs must use.
Layer 2 Drift Risks
Do not build assets for multiple unclear buyers.
Do not create client content before the primary offer is clear.
Do not invent buyer language.
Do not invent offer details.
Layer 3: Client Voice And Brand Language
Purpose
The Client Voice And Brand Language layer defines how the client should sound across AI-generated or AI-assisted outputs.
This layer prevents AI from flattening the client’s voice into generic marketing language.
Included Components
Client Voice Architecture
Client Preferred Language
Client Banned Language
Client Retired Language
Client Founder Or Brand Phrases
Client CTA Style
Client Tone Rules
Client Platform Style Adjustments
Client Examples Of Strong Voice
Client Examples Of Weak Voice
Required Questions
How should the client sound?
What should the client never sound like?
What phrases does the client use naturally?
What phrases should be avoided?
What old language has been retired?
How direct should the client be?
How formal or informal should the client be?
What kind of CTA style fits?
What examples show the voice correctly?
Output
The output of this layer is an approved or draft client voice file that guides content, sales, reporting, emails, scripts, and public-facing output.
Layer 3 Drift Risks
Do not treat general tone adjectives as enough.
Do not mix customer language with client voice.
Do not reuse one client’s voice for another client.
Do not activate voice without review where client-facing output is involved.
Layer 4: Client Differentiation, Objections, And Proof
Purpose
This layer defines why the client’s offer is meaningfully different, what may stop the buyer from acting, and what proof is approved to support claims.
This layer prevents generic positioning, weak sales messaging, and unsupported claims.
Included Components
Client Differentiation Profile
Client Objection Library
Client Proof Library
Client Claims Control Notes
Client Proof Permissions
Client Compliance Notes
Client Proof Gaps
Client Restricted Claims
Required Questions
What makes the client’s offer different?
What does the market usually do?
What does the client reject?
What does the client do instead?
Why does that matter to the buyer?
What objections will buyers have?
What proof exists?
What claims can the proof support?
What claims can the proof not support?
What proof requires approval?
What claims are restricted?
Output
The output of this layer is a positioning, objection, and proof control system for client messaging.
Layer 4 Drift Risks
Do not invent proof.
Do not use client proof without approval.
Do not create unsupported claims.
Do not make vague superiority claims.
Do not pressure bad-fit buyers.
Layer 5: Client Methodology And Expert Thinking
Purpose
This layer captures how the client creates value, how the client thinks, how the client diagnoses problems, and what expert judgment guides the client’s work.
This layer prevents AI from producing surface-level or generic advice.
Included Components
Client Methodology Map
Client Expert Thinking Rules
Client Diagnostic Logic
Client Process Sequence
Client Decision Rules
Client Escalation Rules
Client Quality Criteria
Client Do-Not-Skip Steps
Required Questions
How does the client create transformation?
What is the client’s method?
What steps matter most?
What does the client look for when diagnosing?
What mistakes do beginners or competitors make?
What should AI never simplify?
What requires expert judgment?
When should the AI stop and request review?
Output
The output of this layer is the client’s process and judgment system, structured for AI use.
Layer 5 Drift Risks
Do not invent methodology.
Do not reduce expert judgment into generic tips.
Do not create client AI skills before the methodology is clear.
Do not automate unclear expert judgment.
Layer 6: Client Workflow Map
Purpose
The Client Workflow Map identifies which client tasks repeat, which tasks are suitable for AI assistance, which tasks require human review, and which tasks should not be automated.
This layer converts business context into possible operating workflows.
Included Components
Client Workflow Map
Client Repeating Task List
Client Manual Workflow List
Client AI-Assisted Workflow Candidates
Client No-AI Workflow List
Client Human Review Requirements
Client Tool Boundary Notes
Client Handoff Points
Client Workflow Priority List
Required Questions
What tasks repeat weekly?
What tasks repeat monthly?
What work is slow or inconsistent?
What work follows a known process?
What work requires client approval?
What work should AI assist with?
What work should stay manual?
What work should not be touched by AI?
Where does output go after AI drafts it?
Output
The output of this layer is a client workflow map that supports skill creation, reporting, task routing, and future automation decisions.
Layer 6 Drift Risks
Do not automate before workflow clarity.
Do not create AI skills for tasks that do not repeat.
Do not assume tool access.
Do not remove human review from sensitive workflows.
Layer 7: Client AI Skill Package
Purpose
The Client AI Skill Package defines reusable AI-assisted procedures that support the client’s actual workflows.
This layer turns repeated client work into governed AI skill candidates or installed client-specific skills.
Included Components
Client Skill Candidate List
Client Installed Skill Records
Client Skill Trigger Conditions
Client Skill Required Input
Client Skill Required Context
Client Skill Procedure
Client Skill Forbidden Actions
Client Skill Output Format
Client Skill Validation Rule
Client Skill Handoff Destination
Client Skill Review Requirement
Possible Client Skills
Client Content Brief Skill
Client Voice Checker Skill
Client Report Drafting Skill
Client Sales Follow-Up Skill
Client Objection Response Skill
Client Lead Magnet Drafting Skill
Client Webinar Outline Skill
Client Customer Support Draft Skill
Client Meeting Summary Skill
Client Workflow Summary Skill
Required Questions
Which tasks repeat?
Which tasks have a clear procedure?
Which tasks require context?
Which tasks produce a defined output?
Which tasks can be validated?
Which tasks require human review?
Which tasks should remain manual?
Which skills are client-specific only?
Output
The output of this layer is a client-specific skill package or skill candidate list.
Layer 7 Drift Risks
Do not install skills before input, context, output, and validation are clear.
Do not reuse client-specific skills elsewhere without approval.
Do not treat client skill creation as automation approval.
Layer 8: Client Asset And Output System
Purpose
The Client Asset And Output System defines what business assets the client AI system may produce or assist with.
This layer gives client output a clear structure, review path, and destination.
Included Components
Client Content Asset System
Client Sales Asset System
Client Lead Magnet Asset System
Client Webinar Asset System
Client Report System
Client Email Draft System
Client Landing Page Draft System
Client Ad Draft System
Client Internal SOP Draft System
Client Output Status Rules
Client Output Handoff Rules
Possible Outputs
content briefs
social posts
email drafts
newsletter drafts
sales scripts
lead magnet outlines
webinar outlines
landing page drafts
client reports
workflow summaries
meeting summaries
FAQ drafts
objection responses
ad draft concepts
Required Questions
What outputs will the system create?
What output formats are allowed?
Which outputs are internal only?
Which outputs are client-facing?
Which outputs require approval?
Which outputs require compliance review?
Where does each output go?
What should AI never produce?
Output
The output of this layer is a controlled client asset and output system.
Layer 8 Drift Risks
Do not let AI output float without destination.
Do not send client-facing output without review.
Do not create claims-heavy assets without proof review.
Do not create public assets from draft context.
Layer 9: Client Approval, Privacy, And Review Gates
Purpose
This layer defines the review, approval, privacy, and permission boundaries that protect client trust.
This layer ensures client-specific material does not leak, get misused, or become active without approval.
Included Components
Client Approval Rules
Client Review Gate Protocol
Client Privacy Boundary
Client Context Isolation Notes
Client Proof Approval Records
Client Public Use Permissions
Client Internal Use Permissions
Client Ad Use Restrictions
Client Generalization Rules
Client Restricted Material Notes
Required Questions
What requires client approval?
What can be used internally?
What can be client-facing?
What can be public?
What cannot be used?
What proof is approved?
What proof is restricted?
What data is sensitive?
Can this material be generalized?
Who reviews what?
Output
The output of this layer is a client review and privacy boundary system.
Layer 9 Drift Risks
Do not use client material outside approved scope.
Do not reuse client proof publicly without approval.
Do not generalize client workflows without review.
Do not mix client context with MWMS context.
Layer 10: Client Audit, Reporting, And Maintenance System
Purpose
This layer defines how the client AI system is reviewed, maintained, reported on, and improved over time.
This layer supports recurring AIBS value.
Included Components
Client Audit Schedule
Client Context Review Cycle
Client Skill Review Cycle
Client Report Template
Client Improvement Log
Client Drift Signals
Client Proof Review Schedule
Client Voice Review Schedule
Client Workflow Review Schedule
Client Monthly Or Quarterly Review Notes
Required Questions
How often should the client system be reviewed?
What signals show drift?
What context may become stale?
What skills need review?
What reports should be created?
What should be tracked?
What should be improved?
What changes require client approval?
What happens when the client offer changes?
Output
The output of this layer is an ongoing maintenance and reporting structure for the client system.
Layer 10 Drift Risks
Do not treat client AI systems as set-and-forget.
Do not ignore repeated corrections.
Do not leave stale client context active.
Do not forget approval expiry or proof review.
Package Tiers
MWMS may use this structure to support future package tiers.
Foundation Package
Purpose:
Create the minimum viable client AI context base.
Possible Includes:
Client Business Snapshot
Right-Fit Client Profile
Offer Profile
Voice Architecture
Objection Library
Proof Status Notes
Basic Workflow Map
Approval Rules
Best For:
early clients
simple offers
manual AI support
low-complexity systems
Growth Package
Purpose:
Build a stronger operational client AI system.
Possible Includes:
Foundation Package items
Differentiation Profile
Methodology Map
Expert Thinking Rules
Customer Language Bank
Proof Library
Retired Language
Client Skill Candidates
Client Report Template
Basic Audit Schedule
Best For:
clients with active content, sales, or reporting needs
businesses ready for AI-assisted workflows
Scale Package
Purpose:
Create a more complete client Brain and AI-assisted operating system.
Possible Includes:
Growth Package items
Installed Client Skills
Asset Output System
Client Approval Records
Client Audit System
Monthly Reporting Layer
Workflow Optimization Notes
Skill Review Schedule
Best For:
clients with multiple recurring workflows
clients needing monthly AI support
future white-label delivery
Optimization Package
Purpose:
Maintain and improve an existing client AI system.
Possible Includes:
context audits
skill audits
proof review
voice review
asset review
workflow improvement
monthly or quarterly reports
Kaizen improvement notes
Best For:
recurring AIBS revenue
client retention
long-term system improvement
Package Component Statuses
Every package component should have a status.
Possible statuses:
Not Started
Source Intake Started
Draft Created
Internal Review Complete
Client Review Required
Client Approved
Client Approved With Restrictions
Active
Restricted
Needs Update
Paused
Parked
Archived
Retired
Rejected
No component should have unclear status.
Minimum Viable Client AI System Package
The minimum viable package should include:
Client Business Snapshot
Client Right-Fit Client Profile
Client Offer Profile
Client Voice Notes Or Voice Architecture
Client Main Objections
Client Proof Status
Client Workflow Map
Client Approval Rules
Client Review Requirement
Client Privacy Boundary
This minimum version may support manual or draft client work.
It should not be treated as a complete client AI system.
Full Client AI System Package
A full client AI system package should include:
Client Business Snapshot
Client Right-Fit Client Profile
Client Offer Profile
Client Voice Architecture
Client Differentiation Profile
Client Objection Library
Client Methodology Map
Client Expert Thinking Rules
Client Customer Language Bank
Client Proof Library
Client Brand Visual Style
Client Retired Language
Client Compliance Notes
Client Workflow Map
Client Skill Package
Client Asset And Output System
Client Approval Rules
Client Privacy Boundary
Client Report System
Client Audit Schedule
Client Maintenance Plan
Package Build Workflow
MWMS uses the following workflow.
Step 1: Client Fit Check
Determine whether the client is suitable for an AIBS package.
Step 2: Source Material Intake
Gather and classify client material.
Step 3: Client IP Excavation
Extract client beliefs, methodology, expert thinking, voice, proof, and buyer language.
Step 4: Context Library Construction
Build the client context files.
Step 5: Workflow Mapping
Identify repeated client workflows and skill candidates.
Step 6: Package Scope Decision
Decide whether the package is Foundation, Growth, Scale, Optimization, or custom.
Step 7: Review And Approval Gates
Set internal and client review requirements.
Step 8: Manual Use Setup
Begin with human-reviewed manual or assisted outputs.
Step 9: Skill Installation Where Ready
Install client-specific skills only when ready.
Step 10: Reporting And Audit Setup
Define maintenance and review cycle.
Step 11: Closeout And Handoff
Record what was created, what is active, what is draft, what needs review, and what happens next.
Package Readiness Checklist
Before calling a client package ready, check:
Is the client fit clear?
Is the package tier clear?
Is source material collected?
Is evidence strength marked?
Is the primary offer clear?
Is the right-fit buyer clear?
Is voice clear?
Are objections captured?
Is proof status clear?
Are client approval rules defined?
Is client context isolated?
Is privacy level assigned?
Are workflows mapped?
Are skill candidates identified?
Are output types defined?
Are review gates defined?
Is audit cadence assigned?
Is next action clear?
If not, the package is not fully ready.
Client Package Output Template
Use this structure when recording a client package.
Client Name:
Package Name:
Package Tier:
Package Status:
Owning Brain:
Supporting Brains:
Primary Offer:
Primary Buyer:
Source Material Status:
Context Library Components:
Workflow Components:
Skill Components:
Asset Components:
Approval Components:
Privacy Boundary:
Proof Status:
Reporting Components:
Audit Schedule:
Review Required:
Client Approval Status:
Active Components:
Draft Components:
Parked Components:
Next Action:
Notes:
Package Boundary Rules
Rule 1: Package Does Not Mean Automation
AIBS package structure does not authorize automation.
Rule 2: Package Does Not Grant Tool Access
Tool permissions must be handled separately.
Rule 3: Package Does Not Remove Human Review
Client-facing output requires review gates.
Rule 4: Package Must Stay Client-Specific
Client context must remain isolated.
Rule 5: Package Must Define Included And Not Included
Scope must be clear.
Rule 6: Package Must Have Maintenance Path
Client AI systems decay if not reviewed.
Rule 7: Package Must Be Honest About Readiness
Draft package components must not be sold or described as active.
Common Failure Modes
MWMS must prevent:
selling AI tools instead of AI systems
unclear client deliverables
package scope creep
client package built without source material
client package built around vague offer
client package built without review gates
client proof used without approval
client skills installed too early
client system described as automated when it is not
client context mixed with MWMS context
client system launched without audit plan
package output created without closeout
Governance Role
AIBS Brain owns the AIBS Brain Client AI System Package Structure Standard.
HeadOffice governs cross-system alignment, source-of-truth discipline, and risk escalation.
Compliance Brain governs claim, privacy, public-facing, paid traffic, regulated, and proof-related risks.
AIBS Brain is responsible for:
client package structure
client package tier logic
client package readiness
client context package standards
client skill package standards
client reporting and audit package logic
client approval and privacy alignment
future recurring AIBS delivery structure
HeadOffice is responsible for:
ensuring client packages align with MWMS governance
ensuring client context remains isolated
ensuring package status is not overstated
ensuring high-risk work is routed to review
Relationship To Other MWMS Standards
This standard supports and must align with:
MWMS Document Structure Standard
MWMS AI Brain Build Implementation Checklist
MWMS Client Brain Intake And Onboarding Protocol
MWMS Client Context Isolation And Privacy Boundary Standard
MWMS Client Approval And Review Gate Protocol
MWMS Client IP Excavation Framework
MWMS Source Material Intake And Evidence Inventory Checklist
MWMS Minimum Viable Context Library Rule
MWMS Missing Context And Evidence Gap Handling Rule
MWMS Context File Promotion And Approval Protocol
MWMS Context Change Propagation And Dependency Map Protocol
MWMS Context Library Hygiene And Retired Language Rule
MWMS Offer Context Library Standard
MWMS Context Library Governance And Folder Map Standard
MWMS AI Context Activation And Usage Protocol
MWMS AI Context Pack Template Standard
MWMS Voice Architecture And Brand Language Standard
MWMS Right-Fit Client And Offer Profile Standard
MWMS Differentiation And Objection Library Standard
MWMS Proof Library And Claims Control Standard
MWMS AI Skill Brainstorm And Prioritization Framework
MWMS Manual Build Versus Skill Build Decision Rule
MWMS AI Skill Installation And Usage Protocol
MWMS AI Brain Readiness Review Checklist
MWMS AI Brain Audit And Decay Prevention Framework
MWMS AI Brain Page And Asset Registry Standard
MWMS AI Brain Build Handoff And Closeout Standard
MWMS Architecture Registry
AIBS Brain Canon
This standard defines the client package structure that future AIBS delivery should use.
Drift Protection
This standard protects MWMS from:
unstructured client AI packages
tool-first client delivery
unclear client deliverables
client context leakage
client proof misuse
client skill sprawl
client systems without review gates
client systems without maintenance
client systems without clear package scope
future AIBS delivery inconsistency
Any future client AI system package that does not define business context, offer, buyer, voice, proof, workflows, skills, approval gates, privacy boundary, reporting, and audit path should be treated as an AIBS package drift risk.
Architectural Intent
The architectural intent of the AIBS Brain Client AI System Package Structure Standard is to make future AIBS delivery commercially clear, operationally repeatable, and governable.
MWMS is not building random AI support.
MWMS is building client-specific AI business systems.
The long-term goal is that every future AIBS client package can answer:
What package tier is this?
What business context was captured?
What offer does it support?
Who is the right-fit buyer?
What context files exist?
What workflows are supported?
What skills are included?
What outputs can be created?
What requires approval?
What proof can be used?
What privacy boundary applies?
What reporting exists?
What audit schedule keeps it current?
When MWMS can answer these questions consistently, AIBS packages become easier to sell, build, review, maintain, and scale.
Change Log
v1.0 — Initial Draft
Created the AIBS Brain Client AI System Package Structure Standard as the standard for structuring future client-facing AI Business System packages.
This standard defines the ten core package layers: Client Business Snapshot, Client Offer And Buyer Foundation, Client Voice And Brand Language, Client Differentiation, Objections, And Proof, Client Methodology And Expert Thinking, Client Workflow Map, Client AI Skill Package, Client Asset And Output System, Client Approval, Privacy, And Review Gates, and Client Audit, Reporting, And Maintenance System.
It also defines package tiers, component statuses, minimum viable package requirements, full package requirements, package build workflow, readiness checklist, output template, boundary rules, failure modes, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
AIBS Brain Client AI System Package Structure Standard
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
AIBS Brain Page Registry
HeadOffice Page Registry
Compliance Brain Page Registry
Client Asset Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
AIBS Architect Employee
HeadOffice Manager Employee
AI Manager
AI Employee Router
Brain Room Assistant
Client IP Excavator
Context Library Builder
Skill Auditor
Offer Strategist Employee
Content Planner Employee
Creative Strategist Employee
Sales Strategist Employee
Research Analyst Employee
Compliance Reviewer Employee
Required behaviour updates:
AI Employees must structure future AIBS client packages around business context, offer, buyer, voice, differentiation, objections, proof, methodology, workflows, skills, assets, approval gates, privacy boundaries, reporting, and audit.
AI Employees must not treat client packages as prompt packs, tool setups, generic automations, or unsupervised AI systems.
AI Employees must identify client package tier, package status, active components, draft components, parked components, approval requirements, privacy boundaries, proof status, audit schedule, and next action before calling a client package ready.
AI Employees must use AIBS Brain as the canonical Brain name in MCR references, registry references, parent fields, future operational destinations, and employee impact sections.
END AIBS BRAIN CLIENT AI SYSTEM PACKAGE STRUCTURE STANDARD v1.0