AIFC-032: AI Operating Modes

Status: Draft 0.1 Standard: AI-First Community Standard Abbreviation: AIFC Builds on:

• AIFC-020 Human-Managed AI
• AIFC-021 AI as External Expert Capacity
• AIFC-022 AI-NDA Boundary
• AIFC-024 Human Capability Reserve
• AIFC-030 AI Capacity Planning
• AIFC-031 AI Autonomy and Intensity

Purpose of this document: Define named AI operating modes that allow a community to change AI involvement consciously instead of treating AI use as a single fixed state.

1. Purpose of this document

This document defines AI Operating Modes.

AI use changes according to context.

A community may need conservative AI use in sensitive areas, balanced AI use in normal operations, aggressive AI use during migration, mission-focused AI use for a temporary objective, and AI-off or reduced-AI modes during risk, budget, or trust problems.

Operating modes make these changes explicit, visible, and governable.

2. Core principle

The core principle of this document is:

AI involvement must be governed through explicit operating modes, not improvised by habit or pressure.

An operating mode defines the current relationship between AI capacity, intensity, autonomy, data boundary, risk, review, fallback, and ownership.

3. Definition

AI Operating Mode is a named state of AI involvement in a community, workflow, team, or AI engagement.

It defines:

• AI Intensity,
• AI Autonomy,
• allowed scope,
• approval rules,
• AI Capacity,
• budget behavior,
• AI-NDA Boundary,
• fallback,
• owner,
• trigger conditions,
• exit conditions,
• communication rules.

Minimum requirement

Significant AI use must have a defined operating mode or equivalent governance state.

4. Why operating modes matter

Without operating modes, AI governance becomes vague.

People may not know:

• how much AI should be used,
• what AI may do independently,
• who can approve escalation,
• when AI should be reduced,
• what happens during incidents,
• how budget exhaustion affects AI use,
• whether sensitive data may be used,
• whether fallback is available.

Operating modes turn these questions into explicit rules.

Minimum requirement

The community must be able to tell which mode significant AI work is in.

5. Recommended operating modes

AIFC recommends at least these modes:

Conservative Mode
Balanced Mode
Aggressive Mode
Mission Mode
Emergency AI-Off Mode
Reduced-AI Mode

Communities may define additional modes if they are clear, owned, and auditable.

6. Conservative Mode

Conservative Mode is used when risk, uncertainty, sensitivity, or low maturity requires careful AI use.

Typical use:

• new workflows,
• sensitive data,
• low trust in outputs,
• early adoption,
• high values impact,
• security or legal sensitivity.

Typical settings

• lower AI Intensity,
• low AI Autonomy,
• human approval for significant outputs,
• stricter AI-NDA Boundary,
• stronger source checking,
• higher review depth.

Minimum requirement

Conservative Mode must preserve human decision ownership and review.

7. Balanced Mode

Balanced Mode is the normal operating mode for mature, governed AI use.

AI is actively used, but significant decisions and changes still pass through review.

Typical use:

• normal operations,
• documentation work,
• workflow improvement,
• backlog support,
• maintenance,
• decision support.

Typical settings

• moderate AI Intensity,
• contextual AI Autonomy,
• review gates for significant actions,
• cost visibility,
• source-of-truth write-back,
• standard AI-NDA rules.

Minimum requirement

Balanced Mode must include review gates and source-of-truth rules.

8. Aggressive Mode

Aggressive Mode increases AI involvement to move faster inside an approved scope.

Typical use:

• migration,
• cleanup,
• large transformation,
• backlog reduction,
• urgent knowledge structuring,
• high-volume repetitive work.

Typical settings

• high AI Intensity,
• higher autonomy for low-risk work,
• narrowed scope,
• stronger monitoring,
• explicit budget,
• clear exit condition.

Required elements

Aggressive Mode must have:

• purpose,
• owner,
• scope,
• time limit,
• AI-NDA Boundary where needed,
• cost boundary,
• risk boundary,
• fallback,
• retrospective.

Minimum requirement

Aggressive Mode must be explicitly approved and time-bounded.

9. Mission Mode

Mission Mode is a temporary high-focus AI mode for a specific objective.

It is not normal operation.

Typical use:

• launch preparation,
• recovery effort,
• migration sprint,
• urgent cleanup,
• public release preparation,
• incident analysis.

Typical settings

• high AI Capacity allocation,
• focused scope,
• clear owner,
• fast review process,
• strong progress visibility,
• explicit end state.

Required elements

Mission Mode must define:

• mission objective,
• start and end,
• owner,
• budget,
• risk boundary,
• data boundary,
• review rules,
• fallback,
• exit criteria,
• retrospective.

Minimum requirement

Mission Mode must not become permanent by default.

10. Emergency AI-Off Mode

Emergency AI-Off Mode reduces or stops AI use because continuing AI would create unacceptable risk.

Typical triggers:

• data incident,
• AI-NDA Boundary violation,
• vendor trust issue,
• model failure,
• legal risk,
• security risk,
• severe budget problem,
• loss of human review capability.

Typical settings

• AI Intensity reduced to zero or near zero,
• autonomy revoked,
• integrations paused,
• fallback activated,
• incident response started,
• owner review required.

Required elements

Emergency AI-Off Mode must define:

• who can trigger it,
• what is stopped,
• what continues,
• fallback workflow,
• communication,
• review,
• re-entry conditions.

Minimum requirement

Critical AI-dependent workflows must have an AI-off or reduced-AI path.

11. Reduced-AI Mode

Reduced-AI Mode lowers AI use without fully turning it off.

Typical use:

• budget pressure,
• temporary review shortage,
• model quality decline,
• increased risk,
• trust reduction,
• need to rebuild Human Capability Reserve.

Typical settings

• lower AI Intensity,
• lower autonomy,
• narrower scope,
• stronger prioritization,
• more human work,
• reduced model cost tier.

Minimum requirement

Reduced-AI Mode must preserve critical operations and prevent unsafe shortcuts.

12. Mode selection

Mode selection should consider:

• purpose,
• values,
• risk,
• data sensitivity,
• review capacity,
• AI Capacity,
• budget,
• urgency,
• Human Capability Reserve,
• fallback availability.

Example

Sensitive Operational DNA review
-> Conservative Mode

Public documentation cleanup
-> Balanced or Aggressive Mode

Launch migration with clear owner and timeline
-> Mission Mode

Vendor trust incident
-> Emergency AI-Off Mode

Minimum requirement

Operating mode selection must be explainable.

13. Mode scope

An operating mode may apply to:

• the whole community,
• a team,
• a workflow,
• a product,
• an AI engagement,
• an AI team member,
• a data domain,
• a time-limited mission.

Mode scope should be explicit.

Minimum requirement

Operating mode must define what it applies to.

14. Mode ownership

Every significant operating mode must have an owner.

The owner is accountable for:

• mode selection,
• mode changes,
• escalation,
• de-escalation,
• budget,
• risk,
• review capacity,
• communication,
• retrospective.

Minimum requirement

Operating modes with significant impact must have a human or community owner.

15. Mode transition

Mode transitions must be governed.

Examples:

• Conservative -> Balanced after successful review period.
• Balanced -> Aggressive for approved cleanup.
• Aggressive -> Balanced after mission completion.
• Balanced -> Reduced-AI due to budget pressure.
• Any mode -> Emergency AI-Off after incident.

Minimum requirement

Significant mode transitions must be recorded or traceable.

16. Escalation rules

Escalation means moving toward higher AI Intensity, higher autonomy, higher capacity, or broader scope.

Escalation requires stronger governance when risk increases.

Minimum requirement

Mode escalation must require approval appropriate to risk.

17. De-escalation rules

De-escalation means reducing AI Intensity, autonomy, capacity, or scope.

It may be triggered by:

• incident,
• budget threshold,
• missing review capacity,
• weak output quality,
• AI dependency,
• AI-NDA risk,
• loss of trust.

Minimum requirement

Every high-intensity or high-autonomy mode must have a de-escalation path.

18. Trigger conditions

Operating modes should define trigger conditions.

Examples:

• budget threshold reached,
• risk increased,
• data classification changed,
• mission started,
• incident detected,
• review queue overloaded,
• fallback test failed.

Minimum requirement

High-risk modes must define trigger conditions.

19. Exit conditions

Operating modes should define exit conditions.

Examples:

• mission objective completed,
• budget restored,
• incident closed,
• review backlog reduced,
• fallback restored,
• risk accepted or mitigated.

Minimum requirement

Temporary modes must define exit conditions.

20. Relationship with AI Capacity Planning

Operating modes determine capacity allocation.

Aggressive Mode and Mission Mode consume more AI Capacity.

Emergency AI-Off Mode and Reduced-AI Mode reduce or redirect capacity.

Minimum requirement

Mode changes must consider AI Capacity and budget.

21. Relationship with AI Autonomy and Intensity

Operating modes combine intensity and autonomy.

They should define both.

High intensity does not automatically mean high autonomy.

Minimum requirement

Every significant operating mode must define AI Intensity and AI Autonomy.

22. Relationship with AI-NDA Boundary

Operating modes must respect the AI-NDA Boundary.

Aggressive or Mission Mode must not override data boundaries just because the work is urgent.

Minimum requirement

Mode escalation must not bypass AI-NDA Boundary approval.

23. Relationship with Human Capability Reserve

Operating modes affect human capability.

High AI modes may require additional practice, review calibration, and fallback drills.

Reduced-AI or AI-off modes may be used deliberately to rebuild Human Capability Reserve.

Minimum requirement

Operating modes must consider impact on Human Capability Reserve.

24. Relationship with Human Cockpit Layer

The Human Cockpit Layer should show operating mode status.

It may show:

• current mode,
• scope,
• owner,
• AI Intensity,
• AI Autonomy,
• budget state,
• risk state,
• pending approvals,
• fallback state,
• mode transition history.

Minimum requirement

Significant operating modes must be human-visible.

25. Relationship with Source of Truth

Operating mode decisions should be recorded when they materially affect the community.

Temporary modes, high-risk escalations, and emergency mode changes should not live only in chat.

Minimum requirement

Significant operating mode changes must be recorded in the source of truth or a Decision Record.

26. Operating mode record

Example metadata:

ai_operating_mode:
  id:
  title:
  status: proposed | active | paused | completed | revoked | archived
  mode: conservative | balanced | aggressive | mission | emergency_ai_off | reduced_ai
  owner:
  scope:
  purpose:
  start:
  end:
  trigger:
  exit_condition:
  ai_intensity:
  ai_autonomy:
  capacity_limit:
  budget_limit:
  ai_nda_boundary:
  fallback:
  approval_rules:
  communication_required: true | false
  retrospective_required: true | false

This structure is illustrative.

The final schema should be defined in the agent-actionable layer of the standard.

27. Mode communication

People affected by an operating mode should know:

• what mode is active,
• what changed,
• why it changed,
• what AI may do,
• what humans must review,
• what fallback exists,
• when the mode will be reviewed.

Minimum requirement

Significant mode changes must be communicated to affected people.

28. Mode retrospective

After significant mode use, the community should review:

• whether the mode was appropriate,
• whether value was created,
• whether risk was controlled,
• whether costs were acceptable,
• whether human capability changed,
• whether the mode should be repeated, changed, or retired.

Minimum requirement

Mission, Aggressive, Emergency AI-Off, and other high-impact modes must have retrospective.

29. Anti-patterns

AIFC rejects the following anti-patterns.

29.1 Mode by habit

The community uses the same AI mode everywhere because it is familiar.

29.2 Permanent Mission Mode

A temporary high-intensity mode becomes normal operation.

29.3 Emergency AI-Off without fallback

AI is turned off but critical work cannot continue.

29.4 Aggressive Mode without boundary

AI intensity increases without scope, owner, budget, or risk boundary.

29.5 Mode without owner

No one is accountable for the mode.

29.6 Mode invisible to humans

AI behavior changes but people cannot see the mode.

29.7 Mode escalation without approval

AI Intensity or autonomy increases without governance.

29.8 No de-escalation path

The community can increase AI use but cannot reduce it cleanly.

29.9 Budget-driven unsafe autonomy

The community switches to cheaper or more autonomous AI behavior without safety review.

29.10 AI-off treated as failure

AI-off mode is treated as embarrassment instead of resilience.

30. Minimal requirements

In the area of AI Operating Modes, an AIFC community must at minimum:

1. Define operating modes for significant AI use.
2. Distinguish Conservative, Balanced, Aggressive, Mission, Emergency AI-Off, and Reduced-AI behavior or equivalents.
3. Define mode scope.
4. Define mode owner.
5. Define AI Intensity and AI Autonomy for significant modes.
6. Define escalation and de-escalation rules.
7. Define trigger and exit conditions for high-risk or temporary modes.
8. Align modes with AI Capacity and budget.
9. Respect AI-NDA Boundaries.
10. Protect Human Capability Reserve.
11. Make significant modes visible in the Human Cockpit Layer.
12. Record significant mode changes in the source of truth or a Decision Record.
13. Communicate significant mode changes to affected people.
14. Run retrospective for high-impact modes.

31. Summary

AI Operating Modes make AI involvement governable.

They let a community say:

This is normal AI use.
This is careful AI use.
This is temporary high-intensity AI use.
This is reduced AI use.
This is AI-off recovery.

AIFC therefore says:

Name the mode.
Define the scope.
Assign the owner.
Set intensity and autonomy.
Protect data boundaries.
Keep fallback possible.
Review and exit temporary modes.

AI Operating Modes turn AI involvement into a visible operating state.