Tag: ai

ZenOps 069

Rethinking Organizations as Living Systems

Organizations are traditionally designed as structures.

  • Hierarchies
  • Departments
  • Roles
  • Processes

They are described using terms like:

  • Efficiency
  • Control
  • Performance

And managed through:

  • Planning
  • Reporting
  • Coordination

This view treats organizations as:

Machines

But as complexity increases, this model begins to fail.

Because organizations do not behave like machines.

They behave like:

Living systems

The Limits of the Machine Model

The machine model assumes:

  • Predictable behavior
  • Clear cause and effect
  • Control through structure

This works when:

  • Systems are simple
  • Environments are stable

But modern organizations face:

  • Constant change
  • Complex interactions
  • Emergent behavior

In this context:

  • Machine thinking breaks down

What Is a Living System?

A living system is characterized by:

  • Continuous adaptation
  • Interconnected components
  • Dynamic behavior
  • Self-regulation

Examples include:

  • Biological organisms
  • Ecosystems
  • Human societies

These systems:

  • Evolve over time
  • Respond to their environment
  • Maintain internal coherence

Organizations Already Behave This Way

Even when designed as machines, organizations:

  • Adapt informally
  • Develop internal cultures
  • Create emergent behaviors

This is why:

  • Processes are often bypassed
  • Informal networks become critical
  • Change initiatives behave unpredictably

The reality is:

Organizations are already living systems

We just do not treat them as such.

The Shift in Perspective

ZenOps invites a fundamental shift:

From:

  • Designing organizations as machines

To:

  • Understanding them as living systems

This changes how we think about:

  • Structure
  • Control
  • Change
  • Leadership

Structure Becomes Emergent

In a living system:

  • Structure is not fixed

It emerges from:

  • Interactions
  • Patterns
  • Relationships

This aligns with:

  • ORIGIN (objects and relations)
  • PML (patterns)

Structure becomes:

A result, not a starting point

Control Becomes Regulation

Instead of:

  • Controlling through rules

We regulate through:

  • Feedback
  • Awareness
  • Adjustment

This aligns with:

  • QT (readiness)
  • CQ (awareness)

Control becomes:

Self-regulation

Change Becomes Evolution

Traditional change is:

  • Planned
  • Phased
  • Controlled

In living systems, change is:

  • Continuous
  • Adaptive
  • Emergent

Organizations evolve through:

  • Pattern refinement
  • Learning cycles
  • Feedback loops

Health Becomes Coherence

As we explored in IT-MEDICINE:

  • Health is information coherence

For organizations, this means:

  • Alignment between strategy and execution
  • Consistency in communication
  • Coherent relationships

A healthy organization is:

Coherent

Example: Traditional Organization

  • Fixed roles
  • Defined processes
  • Centralized decision-making

Problems:

  • Slow adaptation
  • Misalignment
  • Hidden inefficiencies

Example: Living Organization

  • Fluid roles
  • Pattern-based work
  • Distributed decision-making

Characteristics:

  • Rapid adaptation
  • Continuous learning
  • Emergent structure

The Role of 5Q in Living Systems

Each dimension of 5Q contributes to organizational life:

  • IQ → structural clarity
  • EQ → relational coherence
  • SQ → collaborative flow
  • MQ → shared purpose
  • CQ → system awareness

Together, they create:

Organizational intelligence

The Role of FLEXI

FLEXI enables living behavior through:

  • One-day micro-sprints
  • Volunteer-based work allocation
  • Continuous feedback

This creates:

  • Flow instead of rigid execution
  • Adaptation instead of fixed planning

The Role of OPUS

OPUS provides:

  • Memory
  • Learning
  • Pattern accumulation

This allows the organization to:

  • Learn from itself
  • Improve over time
  • Evolve systematically

Leadership in Living Systems

Leadership shifts from:

  • Command and control

To:

  • Enabling and guiding

Leaders:

  • Maintain coherence
  • Support pattern development
  • Facilitate alignment

They act as:

System stewards

The Deeper Insight

Organizations fail when we treat them as:

  • Static

They succeed when we recognize them as:

  • Dynamic

Living systems require:

  • Awareness
  • Adaptation
  • Continuous learning

From Design to Cultivation

In machine systems, we:

  • Design

In living systems, we:

Cultivate

We create conditions for:

  • Growth
  • Alignment
  • Evolution

The Future Organization

The organization of the future will be:

  • Adaptive
  • Learning-driven
  • Pattern-based
  • Coherence-focused

It will:

  • Respond to change naturally
  • Improve continuously
  • Align people and systems dynamically

Closing Reflection

Organizations have always been alive.

We simply tried to control them as if they were not.

ZenOps reveals a different path:

  • Understand their nature
  • Align with their behavior
  • Enable their evolution

Because when we treat organizations as living systems, something changes:

  • Control becomes alignment
  • Change becomes growth
  • Work becomes flow

And in that shift, organizations become:

Not just more efficient.

But:

More intelligent, more adaptive, and more human

This is not just a new way to design organizations.

It is a new way to understand them.

As systems that live.

Evolve.

And continuously become something new.

ZenOps 070

Policy as Experimental Design

Public policy has traditionally been approached as:

  • Planning
  • Decision-making
  • Implementation

Governments:

  • Define goals
  • Design policies
  • Roll them out at scale

This process assumes:

We know what will work before we apply it

But reality tells a different story.

Policies often lead to:

  • Unintended consequences
  • Partial success
  • Complete failure

Not because the intentions were wrong.

But because the system being acted upon is:

Complex, dynamic, and not fully understood

The Core Problem

Policy operates under uncertainty.

  • Human behavior is unpredictable
  • Systems are interconnected
  • Outcomes are emergent

Yet policy is often treated as:

  • A fixed solution

Applied to:

  • A changing system

This creates a mismatch:

Static solutions applied to dynamic reality

A New Perspective

ZenOps introduces a different way to think about policy:

Policy as experimental design

Instead of asking:

  • “What policy should we implement?”

We ask:

  • “What experiment should we run?”

What Is Experimental Design?

In science, experimental design involves:

  • Defining a hypothesis
  • Testing it under controlled conditions
  • Observing outcomes
  • Refining understanding

This process acknowledges:

  • Uncertainty
  • The need for evidence
  • Continuous learning

Applying This to Policy

Policy becomes:

  • A hypothesis about how a system will respond

For example:

  • “If we introduce this regulation, behavior will change in this way”

Instead of assuming correctness, we:

  • Test the hypothesis

The Policy Lifecycle Reimagined

Traditional policy lifecycle:

  1. Define policy
  2. Implement
  3. Evaluate

Experimental policy lifecycle:

  1. Observe system (x)
  2. Model behavior (m(x))
  3. Define intervention pattern (p)
  4. Test in controlled environment
  5. Validate outcomes
  6. Scale if successful

This aligns directly with:

ZenOps and Delivery Science

Small-Scale Experiments

Instead of:

  • Nationwide rollout

We begin with:

  • Small, controlled experiments

This allows us to:

  • Test assumptions
  • Identify unintended effects
  • Refine policy before scaling

Example: Economic Policy

Traditional:

  • Implement tax reform at scale
  • Observe long-term effects

Experimental:

  • Test policy in a controlled region
  • Measure behavior changes
  • Adjust based on results

Example: Education Policy

Traditional:

  • Introduce curriculum changes nationwide

Experimental:

  • Pilot new approaches in selected schools
  • Measure learning outcomes
  • Refine before expansion

The Role of Data

Experimental policy relies on:

  • Data collection
  • Measurement
  • Analysis

This transforms policy from:

  • Opinion-driven

To:

Evidence-driven

OPUS for Policy

OPUS can function as:

  • A repository of policy experiments
  • A database of outcomes
  • A system for pattern validation

This enables:

  • Knowledge accumulation across governments
  • Reuse of successful interventions
  • Avoidance of known failures

Pattern-Based Policy

Policies can be defined as:

  • Patterns

Each policy includes:

  • Context
  • Intervention
  • Expected outcome

Through validation, these patterns become:

  • Proven approaches

The Role of CQ in Governance

CQ enables policymakers to:

  • Recognize uncertainty
  • Reflect on outcomes
  • Adapt based on evidence

Without CQ:

  • Policies remain rigid

With CQ:

  • Policies become:

Adaptive and learning-driven

From Control to Learning

Traditional policy focuses on:

  • Control

Experimental policy focuses on:

  • Learning

Instead of:

  • Forcing outcomes

We:

  • Discover what works

Managing Risk Through Experimentation

Large-scale policy changes carry:

  • High risk

Experimental design reduces risk by:

  • Testing before scaling
  • Identifying failures early
  • Limiting impact of incorrect assumptions

Continuous Policy Evolution

Policies are no longer:

  • Static

They become:

  • Continuously evolving systems

Each iteration:

  • Improves understanding
  • Refines intervention
  • Enhances outcomes

The Deeper Insight

Policy is not about:

  • Getting it right the first time

It is about:

Learning what works over time

From Governance to System Design

This shift transforms governance from:

  • Decision-making

To:

System design

Where policymakers:

  • Design experiments
  • Observe outcomes
  • Evolve systems

The Future of Policy

With experimental design, policy becomes:

  • More adaptive
  • More evidence-based
  • More responsive to reality

It allows governments to:

  • Learn faster
  • Fail safely
  • Improve continuously

Closing Reflection

Policy has always aimed to improve society.

But without a structured way to learn, progress is slow and uncertain.

ZenOps offers a different path:

  • Treat policy as experimentation
  • Ground decisions in evidence
  • Evolve continuously

Because in a complex world, certainty is rare.

But learning is always possible.

And when policy becomes a process of learning, something powerful happens:

  • Decisions improve
  • Systems adapt
  • Outcomes align more closely with reality

Policy stops being a static directive.

And becomes:

A living system of discovery, validation, and continuous improvement

ZenOps 071

Governments as Learning Systems

Governments have traditionally been designed as:

  • Decision-making bodies
  • Administrative structures
  • Controllers of policy and regulation

They operate through:

  • Laws
  • Plans
  • Programs

And are evaluated based on:

  • Outcomes
  • Stability
  • Efficiency

But as complexity increases, a fundamental limitation becomes clear:

Governments are slow to learn

The Core Problem

Modern societies are:

  • Complex
  • Dynamic
  • Rapidly changing

Yet governments often operate as if:

  • Conditions are stable
  • Solutions are known
  • Change can be centrally controlled

This leads to:

  • Delayed responses
  • Ineffective policies
  • Repeated mistakes

The underlying issue is not capability.

It is:

Lack of structured learning

From Decision Systems to Learning Systems

ZenOps introduces a new paradigm:

Governments as learning systems

Instead of focusing on:

  • Making the right decisions upfront

Governments focus on:

  • Learning what works over time

What Is a Learning System?

A learning system:

  • Observes reality
  • Forms models
  • Tests interventions
  • Validates outcomes
  • Adapts continuously

This aligns directly with:

  • x → m(x) → p → validation

Government Through the Lens of ZenOps

Applied to governance:

1. Observation (x)

  • Collect real-world data
  • Understand societal conditions
  • Identify emerging issues

2. Modeling (m(x))

  • Represent systems and relationships
  • Understand cause and effect
  • Identify leverage points

3. Pattern Formation (p)

  • Define policy interventions
  • Structure expected outcomes
  • Create repeatable approaches

4. Validation

  • Test policies through experiments
  • Measure impact
  • Compare outcomes

5. Adaptation

  • Refine policies
  • Improve models
  • Evolve understanding

The Role of Experimental Policy

As discussed previously, policy becomes:

  • Experimental design

This enables governments to:

  • Test before scaling
  • Learn from outcomes
  • Reduce risk

OPUS as Government Memory

A learning government requires:

Memory

OPUS provides:

  • A repository of policy experiments
  • A database of validated patterns
  • A system for accumulating knowledge

This prevents:

  • Loss of learning
  • Repetition of mistakes

Pattern-Based Governance

Policies become:

  • Patterns

Each pattern includes:

  • Context
  • Intervention
  • Outcome

Over time, governments build:

  • Libraries of validated policies

The Role of CQ in Governance

CQ is critical for:

  • Recognizing uncertainty
  • Reflecting on outcomes
  • Adapting decisions

Without CQ:

  • Governments become rigid

With CQ:

  • Governments become:

Self-aware systems

From Static Plans to Adaptive Systems

Traditional governance relies on:

  • Long-term plans

Learning systems rely on:

  • Continuous adaptation

Plans are replaced by:

  • Evolving strategies

Example: Economic Policy

Traditional:

  • Implement policy
  • Evaluate after years

Learning system:

  • Test interventions
  • Monitor continuously
  • Adjust in real time

Example: Public Health

Traditional:

  • Apply broad measures
  • React to outcomes

Learning system:

  • Model disease spread
  • Test interventions
  • Adapt based on data

Speed of Learning as a Competitive Advantage

In a global context, the ability to:

  • Learn faster

Becomes more important than:

  • Planning better

Governments that learn quickly:

  • Adapt faster
  • Respond better
  • Achieve better outcomes

The Feedback Loop

A learning government operates through:

  1. Observe
  2. Model
  3. Test
  4. Validate
  5. Adapt

This loop runs:

  • Continuously
  • At multiple levels
  • Across domains

The Role of Technology

Technology enables learning systems by:

  • Collecting data
  • Analyzing patterns
  • Supporting decision-making

Combined with ZenOps, it creates:

  • Intelligent governance systems

From Control to Evolution

Traditional governance seeks to:

  • Control systems

Learning governance seeks to:

  • Evolve systems

This is a fundamental shift.

The Deeper Insight

Governments fail not because:

  • They lack authority

But because:

  • They lack structured learning

Without learning:

  • Mistakes repeat
  • Systems stagnate

Toward Adaptive Governance

A learning government is:

  • Adaptive
  • Evidence-based
  • Continuously improving

It does not aim to:

  • Be perfect

It aims to:

Get better over time

The Human Element

Learning systems require:

  • Awareness
  • Reflection
  • Openness to change

This depends on:

  • CQ in leadership
  • Culture of learning
  • Acceptance of experimentation

The Future of Governance

As governments evolve into learning systems:

  • Policies become more effective
  • Systems become more resilient
  • Societies become more adaptive

Governance becomes:

  • A continuous process

Not a static structure

Closing Reflection

The role of government is not just to:

  • Decide

It is to:

Learn

Because in a complex world, no system can:

  • Know everything in advance

But every system can:

  • Learn

And when governments embrace this, something profound happens:

  • Decisions improve
  • Systems evolve
  • Societies thrive

Governments stop being rigid structures.

And become:

Living systems of continuous learning, adaptation, and improvement

This is the future of governance.

Not defined by control.

But by:

The ability to learn, evolve, and align with reality

ZenOps 072

The Role of AI in ZenOps

As ZenOps evolves into a full system of:

  • Conscious Delivery
  • Delivery Science
  • Pattern-based learning
  • Adaptive organizations and governance

A natural question arises:

Where does AI fit into all of this?

Because AI is often framed as:

  • Automation
  • Intelligence
  • Replacement of human work

But within ZenOps, AI takes on a different role.

Not as a replacement.

But as an amplifier.

The Misconception of AI

Most discussions around AI focus on:

  • Replacing human effort
  • Automating tasks
  • Increasing efficiency

This view is limited.

It treats AI as:

A tool for execution

But ZenOps is not primarily about execution.

It is about:

Understanding

AI as a Pattern Engine

At its core, AI is:

A pattern recognition and pattern generation system

It can:

  • Detect patterns in large datasets
  • Suggest pattern combinations
  • Predict outcomes based on patterns

This aligns directly with:

  • PML (Pattern Modeling Language)
  • OPUS (pattern storage)
  • Pattern mining

AI in the ZenOps Stack

AI integrates into ZenOps at multiple layers.

1. Observation (x)

AI can:

  • Analyze large volumes of data
  • Detect signals humans might miss
  • Identify emerging trends

2. Modeling (m(x))

AI can:

  • Suggest object-relation structures
  • Identify dependencies
  • Propose system models

3. Pattern Formation (p)

AI can:

  • Generate candidate patterns
  • Combine existing patterns
  • Suggest new approaches

4. Validation

AI can:

  • Simulate scenarios
  • Predict outcomes
  • Assist in testing patterns

5. Pattern Mining

AI excels at:

  • Discovering hidden patterns
  • Identifying correlations
  • Scaling knowledge extraction

AI as a Co-Thinker

In ZenOps, AI is not just:

  • A tool

It becomes:

A co-thinker

Working alongside humans to:

  • Explore possibilities
  • Test hypotheses
  • Refine understanding

The Role of Humans

AI does not replace human capability.

It complements it.

Humans provide:

  • CQ (awareness)
  • Context understanding
  • Meaning and purpose (MQ)
  • Relational insight (EQ)

AI provides:

  • Scale
  • Speed
  • Pattern detection

Together, they form:

A combined intelligence system

Example: Software Development

Without AI:

  • Developers design patterns
  • Validate manually
  • Learn slowly

With AI:

  • Patterns are suggested
  • Risks are identified early
  • Validation is accelerated

Development becomes:

  • Faster
  • More reliable
  • More informed

Example: Policy Design

Without AI:

  • Policies rely on limited data
  • Outcomes are uncertain

With AI:

  • Simulations test policy scenarios
  • Patterns of impact are predicted
  • Decisions are evidence-supported

Policy becomes:

More adaptive and informed

AI and OPUS

OPUS provides the structured knowledge base.

AI uses OPUS to:

  • Learn from past patterns
  • Suggest new ones
  • Improve recommendations over time

This creates:

A continuously improving intelligence system

AI and Mímir

Within Mímir, AI becomes:

  • A core component of collective intelligence

It helps:

  • Coordinate across domains
  • Discover cross-domain patterns
  • Accelerate system evolution

The Risk of AI Without Structure

AI without ZenOps structure leads to:

  • Uninterpretable outputs
  • Misapplied patterns
  • Lack of trust

Because AI needs:

  • Clear models
  • Defined patterns
  • Validation mechanisms

ZenOps provides this structure.

CQ as the Guardrail

CQ ensures that AI is used:

  • Thoughtfully
  • Critically
  • Responsibly

It allows humans to:

  • Question AI outputs
  • Interpret results
  • Maintain control

From Automation to Augmentation

The real role of AI in ZenOps is:

Augmentation

It enhances:

  • Human thinking
  • Pattern recognition
  • Decision-making

It does not replace:

  • Awareness
  • Judgment
  • Meaning

AI and Learning Acceleration

AI dramatically increases:

  • Speed of learning
  • Depth of analysis
  • Breadth of pattern discovery

This supports:

  • Faster QT achievement
  • Better pattern validation
  • Continuous improvement

The Deeper Insight

AI is not intelligent in isolation.

Its value comes from:

The patterns it operates on

ZenOps defines those patterns.

Toward a Human-AI System

The future is not:

  • Humans vs AI

It is:

Humans + AI as a unified system

Where:

  • Humans provide awareness and meaning
  • AI provides scale and computation

The Evolution of Work

With AI in ZenOps:

  • Routine tasks diminish
  • Pattern thinking increases
  • Awareness becomes critical

Work shifts from:

  • Doing

To:

Understanding and designing

Closing Reflection

AI is one of the most powerful technologies of our time.

But its true potential is not in:

  • Replacing human work

It is in:

Enhancing human understanding

ZenOps provides the framework for this.

It ensures that AI is:

  • Grounded in structure
  • Guided by awareness
  • Applied with purpose

Because in the end, the goal is not to build smarter machines.

It is to create:

Smarter systems of thinking

Where humans and AI together can:

  • Understand more
  • Learn faster
  • Build better

This is the role of AI in ZenOps.

Not as a tool.

But as:

A partner in the evolution of understanding itself

ZenOps 073

AI as Pattern Discovery Engine

In the previous essay, we explored the role of AI in ZenOps as:

An amplifier of understanding

But to truly understand its power, we must go deeper.

Because AI’s most important capability is not automation.

It is not even prediction.

It is something more fundamental:

Pattern discovery

The Core Nature of AI

At its foundation, AI operates by:

  • Identifying patterns in data
  • Learning relationships between inputs and outputs
  • Generalizing from examples

This makes AI uniquely suited for one task above all:

Finding patterns humans cannot easily see

From Pattern Recognition to Pattern Discovery

There is an important distinction:

  • Pattern recognition → identifying known patterns
  • Pattern discovery → uncovering new patterns

Humans are good at:

  • Recognizing familiar structures
  • Applying learned patterns

AI excels at:

  • Discovering hidden structures
  • Identifying subtle correlations
  • Exploring vast pattern spaces

Why Pattern Discovery Matters

In ZenOps, patterns are:

  • The fundamental units of knowledge

They define:

  • How systems behave
  • How problems are solved
  • How outcomes are produced

The more patterns we discover:

  • The more we understand
  • The more we can improve systems

The Limitation of Human Discovery

Human pattern discovery is limited by:

  • Experience
  • Cognitive capacity
  • Bias

We tend to:

  • See what we expect
  • Miss subtle relationships
  • Focus on familiar structures

This creates blind spots.

AI Expands the Search Space

AI can analyze:

  • Massive datasets
  • Complex interactions
  • High-dimensional relationships

It can explore:

  • Combinations of patterns
  • Variations across contexts
  • Emergent behaviors

This expands pattern discovery from:

  • Local

To:

Global

Example: Software Systems

Human observation:

  • Identify common bugs
  • Recognize known performance issues

AI discovery:

  • Detect rare failure patterns
  • Identify hidden dependencies
  • Discover optimization opportunities

Example: Organizational Behavior

Human observation:

  • Recognize communication issues
  • Identify visible conflicts

AI discovery:

  • Detect subtle misalignment patterns
  • Identify hidden collaboration structures
  • Predict team dynamics

Example: Policy Systems

Human observation:

  • Evaluate policy outcomes

AI discovery:

  • Identify unexpected causal relationships
  • Detect unintended consequences
  • Suggest alternative interventions

AI Within OPUS

OPUS provides:

  • Structured pattern data
  • Validation results
  • Contextual information

AI uses this to:

  • Discover new patterns
  • Refine existing ones
  • Suggest improvements

This creates:

A continuously evolving pattern ecosystem

From Data to Discovery

Without AI:

  • Data accumulates

With AI:

  • Data reveals

AI transforms:

  • Stored experience

Into:

New knowledge

Pattern Discovery as a Continuous Process

AI does not discover patterns once.

It does so:

  • Continuously
  • Across domains
  • At increasing levels of complexity

This aligns with:

  • ZenOps feedback loops
  • Delivery Science evolution

The Role of Humans in Discovery

AI can discover patterns.

But humans must:

  • Interpret them
  • Validate their meaning
  • Apply them appropriately

This requires:

  • CQ (awareness)
  • Context understanding
  • Judgment

From Discovery to Validation

Not all discovered patterns are:

  • Useful
  • Correct
  • Applicable

ZenOps ensures that patterns are:

  • Tested (StoryQ)
  • Validated
  • Proven

AI suggests.

ZenOps verifies.

The Risk of Unchecked Discovery

Without validation, AI can produce:

  • False patterns
  • Spurious correlations
  • Misleading insights

This is why pattern discovery must be:

Grounded in structure and validation

Toward Autonomous Pattern Systems

As AI and OPUS evolve, we approach:

  • Semi-autonomous pattern systems

Where:

  • AI discovers patterns
  • Systems test them
  • Knowledge evolves continuously

Humans guide:

  • Direction
  • Meaning
  • Application

The Deeper Insight

Knowledge is not static.

It is:

Discovered within data

AI accelerates this discovery.

From Learning to Discovery

Traditional systems focus on:

  • Learning existing knowledge

AI-enabled systems focus on:

  • Discovering new knowledge

This shifts the frontier from:

  • Application

To:

Exploration

Cross-Domain Pattern Discovery

One of the most powerful capabilities of AI is:

  • Discovering patterns across domains

For example:

  • Patterns in biology applied to IT
  • Organizational patterns applied to policy
  • Learning patterns applied to systems

This enables:

Unified understanding

The Future of Pattern Discovery

As AI advances:

  • Pattern discovery becomes faster
  • Insights become deeper
  • Knowledge becomes interconnected

This creates:

  • A continuously expanding understanding of systems

Closing Reflection

AI’s greatest contribution is not doing work for us.

It is:

Showing us what we did not know to look for

In ZenOps, this becomes transformative.

Because once patterns are discovered:

  • They can be understood
  • They can be validated
  • They can be applied

And in that process, something remarkable happens:

  • Systems improve
  • Knowledge expands
  • Understanding deepens

We move beyond:

  • What we already know

Into:

What is waiting to be discovered

This is AI as a pattern discovery engine.

Not just a tool for answers.

But a partner in uncovering:

The hidden structure of reality itself

ZenOps 074

Human + AI: A New Cognitive Loop

As we have explored the role of AI in ZenOps, a clear picture emerges.

AI is not simply:

  • A tool
  • A system
  • A replacement for human effort

And humans are not simply:

  • Decision-makers
  • Executors
  • Isolated thinkers

Together, they form something new:

A combined cognitive system

This is not a metaphor.

It is a structural shift in how thinking itself happens.

The Traditional Cognitive Loop

Before AI, human cognition followed a familiar loop:

  1. Observe reality
  2. Interpret based on experience
  3. Make decisions
  4. Act
  5. Learn from outcomes

This loop is powerful.

But it is limited by:

  • Memory
  • Cognitive capacity
  • Exposure to patterns

Learning is:

  • Slow
  • Local
  • Experience-bound

The Introduction of AI

AI enters this loop by adding:

  • Massive pattern memory
  • High-speed analysis
  • Broad pattern discovery

This transforms the loop.

The New Cognitive Loop

With AI, the loop becomes:

  1. Human observes reality (x)
  2. AI analyzes patterns within data
  3. Human interprets with CQ (awareness)
  4. AI suggests patterns and predictions (p)
  5. Human selects and contextualizes
  6. System validates outcomes (StoryQ / QT)
  7. OPUS stores results
  8. AI learns from accumulated knowledge

This is:

A continuous human-AI feedback loop

What Changes in This Loop?

Several fundamental shifts occur.

1. Scale of Perception

Humans:

  • See specific instances

AI:

  • Sees patterns across vast datasets

Together:

  • Perception becomes deeper and broader

2. Speed of Learning

Traditional learning:

  • Requires repeated experience

AI-assisted learning:

  • Leverages accumulated knowledge

Learning becomes:

  • Faster
  • More efficient
  • More scalable

3. Nature of Thinking

Thinking shifts from:

  • Isolated reasoning

To:

  • Collaborative cognition

Humans and AI think together.

The Role of Each Component

Human Role

Humans provide:

  • CQ → awareness and reflection
  • EQ → relational understanding
  • MQ → meaning and direction
  • Context interpretation

Humans answer:

  • Why does this matter?
  • What should we do?

AI Role

AI provides:

  • Pattern discovery
  • Pattern suggestion
  • Pattern scaling
  • Data-driven insight

AI answers:

  • What patterns exist?
  • What might happen?

Example: Software Development

Traditional loop:

  • Developer writes code
  • Tests it
  • Learns through debugging

Human-AI loop:

  • Developer defines problem
  • AI suggests patterns
  • Developer selects and refines
  • System validates
  • Results stored in OPUS
  • AI improves suggestions

Development becomes:

A continuous learning loop

Example: Policy Design

Traditional:

  • Policymakers design policy
  • Implement
  • Evaluate later

Human-AI loop:

  • AI analyzes societal data
  • Suggests intervention patterns
  • Humans interpret context
  • Policies tested experimentally
  • Results stored and refined

Policy becomes:

Adaptive and evidence-driven

The Role of OPUS in the Loop

OPUS acts as:

  • Memory
  • Knowledge base
  • Learning repository

It ensures that:

  • Every cycle improves the system
  • Knowledge accumulates
  • Patterns evolve

CQ as the Integrator

CQ is what makes this loop coherent.

It ensures that:

  • AI outputs are interpreted correctly
  • Human decisions are reflective
  • Learning is conscious

Without CQ:

  • The loop becomes mechanical

With CQ:

  • The loop becomes:

Conscious cognition

From Linear Thinking to Cyclical Intelligence

Traditional thinking is often:

  • Linear

Human-AI cognition is:

  • Cyclical
  • Continuous
  • Self-improving

Each cycle:

  • Enhances understanding
  • Refines patterns
  • Improves outcomes

The Emergence of Collective Intelligence

When many human-AI loops connect through OPUS:

  • Knowledge becomes shared
  • Patterns become global
  • Learning becomes collective

This creates:

Collective intelligence at scale

The Shift in Human Capability

As this loop becomes standard:

  • Humans rely less on memory
  • More on interpretation
  • More on awareness

Capability shifts from:

  • Knowing

To:

Understanding and guiding

The Risk of Imbalance

This system requires balance.

If humans over-rely on AI:

  • Critical thinking declines

If AI is underutilized:

  • Potential is lost

The goal is:

Integration

The Deeper Insight

Cognition is no longer confined to the human mind.

It becomes:

A system-level process

Distributed across:

  • Humans
  • AI
  • Knowledge systems

Toward a New Form of Intelligence

This loop represents a new form of intelligence:

  • Not purely human
  • Not purely artificial

But:

Hybrid intelligence

The Future of Work and Thinking

As this loop matures:

  • Decision-making improves
  • Learning accelerates
  • Systems become more adaptive

Work becomes:

  • More cognitive
  • More reflective
  • More meaningful

Closing Reflection

The integration of humans and AI is often discussed in terms of:

  • Jobs
  • Automation
  • Efficiency

But its deeper impact is on:

How we think

Because when humans and AI form a continuous cognitive loop, something profound happens:

  • Thinking becomes collaborative
  • Learning becomes continuous
  • Understanding becomes deeper

We move beyond:

  • Individual cognition

Into:

A shared system of intelligence

Where humans and AI together can:

  • Explore more
  • Learn faster
  • Build better systems

This is not just an evolution of technology.

It is an evolution of cognition itself.

And we are only at the beginning.

ZenOps 077

Capturing Experience (x) — What Actually Happens in Task Management

In the previous post, we transformed a simple TODO-app into:

A living system

But to truly understand how such a system works, we must go deeper into the foundation of ZenOps:

Experience (x)

Because everything begins here.

Not with:

  • Models
  • Patterns
  • Systems

But with:

What actually happens

The Illusion of Task Management

Traditional task management systems capture:

  • Task titles
  • Status changes
  • Assignments
  • Deadlines

They tell us:

  • What was supposed to happen

But not:

  • What actually happened

This is a critical distinction.

Because real systems are not defined by intention.

They are defined by:

Experience

What Is Experience (x)?

In ZenOps, experience is:

The raw, unstructured reality of events as they occur

It includes:

  • Actions taken
  • Decisions made
  • Interactions between people
  • Outcomes observed
  • Deviations from expectation

Experience is:

  • Messy
  • Contextual
  • Dynamic

The Gap Between Plan and Reality

In any task system, there is always a gap between:

  • Planned behavior
  • Actual behavior

For example:

A task is created with the intention:

  • “Complete feature X”

But what actually happens may include:

  • Clarifications needed
  • Unexpected dependencies
  • Reassignments
  • Delays
  • Workarounds

Traditional systems ignore this richness.

ZenOps captures it.

What Actually Happens in Task Management

Let us observe a simple task lifecycle:

  1. Task is created
  2. Task is assigned
  3. Work begins
  4. Issues arise
  5. Task is transferred
  6. Work resumes
  7. Task is completed

This seems straightforward.

But the real experience includes:

  • Why the task was created
  • How it was understood
  • Where confusion occurred
  • Why it was transferred
  • What changed during execution

This is:

Experience (x)

Capturing the Full Experience

To capture experience properly, we must record:

1. Context

  • Why the task exists
  • What problem it solves

2. Actions

  • What was done
  • In what sequence

3. Interactions

  • Who interacted with the task
  • How responsibilities shifted

4. Decisions

  • Why changes were made
  • What alternatives were considered

5. Outcomes

  • What result was achieved
  • How it differed from expectations

Example: Task Transfer

Traditional record:

  • Task reassigned from User A to User B

ZenOps experience capture:

  • Task was reassigned because User A lacked context
  • Transfer occurred after delay
  • User B clarified requirements
  • Task scope was adjusted

This reveals:

  • A pattern of misunderstanding
  • A system-level issue

Experience as Signal

Every task contains signals:

  • Friction
  • Misalignment
  • Inefficiency
  • Success

If we capture only:

  • Status

We lose these signals.

If we capture experience:

  • We gain insight

From Events to Meaning

Experience is not just data.

It becomes meaningful when we can:

  • Interpret it
  • Structure it
  • Learn from it

This is the transition from:

  • x → m(x)

The Role of CQ in Capturing Experience

CQ enables us to:

  • Notice what is happening
  • Reflect on actions
  • Recognize deviations

Without CQ:

  • Experience is lost

With CQ:

  • Experience becomes:

Observable

The Challenge of Capturing x

Capturing experience is difficult because:

  • It requires effort
  • It is often implicit
  • It is rarely structured

People tend to:

  • Focus on completing tasks
  • Not on observing them

Embedding Experience Capture in Systems

A ZenOps TODO-app must:

  • Capture experience naturally
  • Integrate it into workflows
  • Avoid excessive overhead

This can be done through:

  • Lightweight annotations
  • Event tracking
  • Context-aware logging

Example: Micro-Reflection

After completing a task, the system prompts:

  • What was unclear?
  • What changed during execution?
  • What would you do differently?

This creates:

  • Structured experience

From Tasks to Experience Streams

Instead of viewing tasks as:

  • Isolated units

We see them as:

Streams of experience

Each task becomes:

  • A narrative
  • A sequence of events
  • A source of learning

The Foundation of Everything

Without experience:

  • There is nothing to model
  • No patterns to define
  • No validation to perform

Experience is:

The raw material of understanding

The Deeper Insight

Most systems fail not because:

  • They lack execution

But because:

  • They do not understand what actually happens

From Invisible to Visible

Capturing x makes the invisible:

  • Visible

We begin to see:

  • Where systems break
  • Where patterns emerge
  • Where improvement is possible

The First Step Toward Intelligence

Before a system can:

  • Learn
  • Adapt
  • Improve

It must:

Observe itself

Closing Reflection

Task management has always been about:

  • Organizing work

ZenOps transforms it into:

Understanding work

Because once we capture experience (x), something changes:

  • Tasks become data
  • Data becomes insight
  • Insight becomes patterns

And from there, the entire system begins to evolve.

Not based on assumptions.

But based on:

What actually happens

This is the beginning of true intelligence in systems.

Not in planning.

Not in execution.

But in:

Observation

Because if we cannot see reality clearly…

We cannot improve it.

And capturing experience is how we begin to see.

ZenOps 076

The TODO-App as a Living System

Throughout the ZenOps journey, we have explored systems at every scale:

  • Individuals
  • Teams
  • Organizations
  • Governments
  • Society

But to truly understand a paradigm, we must ground it.

We must take something simple.

Something concrete.

Something familiar.

And ask:

What does ZenOps look like in practice?

Let us begin with the simplest possible system:

A TODO-app

Why a TODO-App?

A TODO-app appears trivial.

  • Create tasks
  • Assign tasks
  • Complete tasks

But beneath this simplicity lies a complete system:

  • Objects (tasks, users)
  • Relations (assignment, ownership)
  • Behavior (create, transfer, complete)
  • Outcomes (work delivered)

It is a perfect microcosm of:

Delivery systems

The Traditional TODO-App

Most TODO-apps are designed as:

  • Task lists
  • Status trackers
  • Simple workflows

They answer:

  • What needs to be done?
  • Who is doing it?
  • What is the status?

But they do not answer:

  • Why is this task structured this way?
  • What pattern does this represent?
  • How can this system improve?

They track:

Activity

Not:

Understanding

Reframing the TODO-App

In ZenOps, the TODO-app becomes:

A living system

Not just a tool for managing tasks.

But a system that:

  • Learns
  • Adapts
  • Improves

The Core Elements

Let us map the TODO-app to ZenOps.

Experience (x)

  • A user creates a task
  • A task is assigned
  • A task is completed or fails

This is raw experience.

Modeling (m(x))

We define:

  • Objects → Task, User
  • Relations → AssignedTo, DependsOn, TransferredTo

This is the ORIGIN model.

Patterns (p)

We define patterns such as:

  • Task Creation Pattern
  • Task Assignment Pattern
  • Task Transfer Pattern
  • Task Completion Pattern

Each pattern includes:

  • Context
  • Inputs
  • Transformation
  • Outputs

Validation

Using StoryQ, we define:

  • Expected behavior

Example:

  • Given a task is assigned
  • When the assignee accepts
  • Then the task state becomes “in progress”

This ensures:

  • Patterns are correct

Execution (FLEXI)

Work is executed through:

  • One-day micro-sprints
  • Volunteer-based task selection

Only tasks above QT are:

  • Executed

The TODO-App as a Learning System

Unlike traditional apps, this system:

  • Captures every interaction
  • Stores patterns in OPUS
  • Validates outcomes

Each task becomes:

  • A data point
  • A learning opportunity

Example: Task Transfer

Traditional system:

  • Task is reassigned
  • Status updated

ZenOps system:

  • Transfer pattern is applied
  • Outcome is validated
  • Context is recorded

Over time, the system learns:

  • When transfers succeed
  • When they fail
  • What patterns improve outcomes

Pattern Evolution

As tasks are processed:

  • Patterns are refined
  • New patterns emerge
  • Inefficient patterns are replaced

The TODO-app evolves from:

  • Static functionality

To:

Adaptive behavior

AI Integration

AI analyzes the system to:

  • Suggest better task assignments
  • Predict delays
  • Recommend pattern improvements

For example:

  • “Tasks of this type succeed when assigned to users with this pattern profile”

Workforce Matching in Action

Using 5Q:

  • Tasks are matched to individuals

Not just based on:

  • Availability

But based on:

  • Capability
  • Pattern performance
  • Context

CQ in the TODO-App

Users are not passive.

They:

  • Reflect on tasks
  • Improve patterns
  • Understand system behavior

The app becomes:

A tool for awareness

From Tasks to Patterns

The key shift is:

From:

  • Managing tasks

To:

Managing patterns

Tasks become:

  • Instances of patterns

Example: Recurring Tasks

Instead of repeating tasks:

  • The system identifies patterns

For example:

  • “Weekly reporting” becomes a pattern

Which can be:

  • Optimized
  • Automated
  • Improved

The Feedback Loop

The TODO-app operates as a loop:

  1. Task created (x)
  2. Modeled (m(x))
  3. Pattern applied (p)
  4. Validated
  5. Stored in OPUS
  6. Improved through AI

This loop runs:

  • Continuously

From Tool to System

The TODO-app is no longer:

  • A productivity tool

It becomes:

A delivery system

Scaling the Concept

This simple system can scale to:

  • Team coordination
  • Project management
  • Organizational workflows

The same principles apply.

The Deeper Insight

Even the simplest system can become:

  • Intelligent
  • Adaptive
  • Self-improving

When we:

  • Capture patterns
  • Validate behavior
  • Learn continuously

The Bridge to OPUS

The TODO-app becomes:

  • The entry point to OPUS

Every task contributes to:

  • The global knowledge system

From Micro to Macro

This is where everything connects.

The TODO-app is:

  • A micro-system

But it reflects:

  • The same structure as society

Closing Reflection

It is easy to think of ZenOps as:

  • Abstract
  • Conceptual
  • Large-scale

But its power lies in:

  • Practical application

Because if we can turn a simple TODO-app into a living system…

We can do the same for:

  • Teams
  • Organizations
  • Governments
  • Society

The transformation begins with something small.

A task.

A pattern.

A validation.

And from there, something remarkable emerges:

A system that does not just manage work.

But:

Understands it, improves it, and evolves with it

This is the TODO-app as a living system.

Simple in form.

But profound in implication.

Because it proves that:

Any system can become conscious

When we design it to learn.

ZenOps 078

Modeling the TODO Domain with ORIGIN (m(x))

In the previous post, we explored the foundation of all systems:

Experience (x)

We saw that task management is not just:

  • Tasks
  • Status
  • Assignments

But a rich stream of:

  • Actions
  • Decisions
  • interactions
  • Outcomes

Now we take the next step in the ZenOps formula:

x → m(x)

We move from:

  • Raw experience

To:

Structured understanding

Why Modeling Matters

Experience alone is not enough.

It is:

  • Unstructured
  • Contextual
  • Difficult to reason about

To understand a system, we must:

  • Structure it
  • Define its components
  • Clarify relationships

This is the purpose of:

Modeling

Introducing ORIGIN

ORIGIN is the ZenOps framework for modeling reality.

It is based on a simple but powerful principle:

  • Thinking creates objects
  • Feeling creates relations

This gives us:

  • Objects (o)
  • Relations (r)

Together forming:

m(x) = (o, r)

From Experience to Model

Let us return to the TODO-app.

We observed experiences such as:

  • Tasks being created
  • Tasks being assigned
  • Tasks being transferred
  • Tasks being completed

Now we ask:

What are the objects and relations behind these events?

Identifying Objects

Objects are:

  • Distinct entities in the system

In the TODO domain, key objects include:

  • Task
  • User
  • State
  • Comment
  • Context

Each object represents:

  • Something that exists

Identifying Relations

Relations describe:

  • How objects interact

In the TODO domain, relations include:

  • Task → assignedTo → User
  • Task → dependsOn → Task
  • Task → hasState → State
  • Task → hasContext → Context
  • User → interactsWith → Task

Relations capture:

  • Structure
  • Flow
  • Dependencies

Example: Task Assignment

Experience:

  • A task is assigned to a user

Model:

  • Object: Task
  • Object: User
  • Relation: assignedTo(Task, User)

This transforms:

  • An event

Into:

A structured relationship

Example: Task Transfer

Experience:

  • A task is transferred from User A to User B

Model:

  • Task → assignedTo → User A
  • Transition → assignedTo → User B

We also capture:

  • Why the transfer occurred

This introduces:

  • Context relations

Beyond Surface Modeling

A shallow model might stop at:

  • Tasks and users

But ORIGIN encourages deeper modeling:

  • Why does a task exist?
  • What problem does it solve?
  • What dependencies influence it?

This introduces higher-level objects:

  • Goal
  • Requirement
  • Constraint

Modeling Context

Context is critical.

Without it, models are:

  • Incomplete
  • Misleading

In the TODO domain, context includes:

  • Project
  • Priority
  • Environment
  • Dependencies

Relations connect context to tasks.

From Static to Dynamic Models

Traditional models are:

  • Static

But real systems are:

  • Dynamic

ORIGIN models must capture:

  • State transitions
  • Changing relations
  • Evolving structures

For example:

  • Task moves from “created” to “in progress” to “completed”

Modeling State

State is an object.

But it is also:

  • A representation of change

We define:

  • Task → hasState → State

And track transitions between states.

The Role of Time

Time is implicit in experience.

In modeling, we must capture:

  • Sequence of events
  • Order of interactions

This allows us to understand:

  • Flow

From Model to Insight

Once we have a model, we can:

  • Analyze relationships
  • Identify bottlenecks
  • Detect inefficiencies

For example:

  • Tasks frequently transferred between users

This reveals:

  • A pattern of misalignment

CQ and Modeling

CQ enables:

  • Awareness of structure
  • Recognition of missing elements
  • Refinement of models

Without CQ:

  • Models remain incomplete

With CQ:

  • Models become:

Accurate representations of reality

The Power of Explicit Models

When models are explicit:

  • Everyone shares the same understanding
  • Ambiguity is reduced
  • Communication improves

This is critical for:

  • Collaboration
  • System design
  • Pattern definition

The Bridge to Patterns

Modeling is not the end.

It is the bridge to:

Patterns (p)

From:

  • Objects and relations

We derive:

  • Behavior

Example: From Model to Pattern

Model:

  • Task → assignedTo → User
  • Task → hasState → State

Pattern:

  • Assignment Pattern
  • State Transition Pattern

Patterns define:

  • How the system behaves

ORIGIN in the TODO-App

The TODO-app now becomes:

  • A structured system

Not just:

  • A list of tasks

But:

  • A network of objects and relations

The Deeper Insight

Without modeling:

  • Systems remain opaque

With modeling:

  • Systems become understandable

From Chaos to Structure

Experience is:

  • Chaotic

Modeling brings:

  • Structure

This enables:

  • Reasoning
  • Analysis
  • Improvement

The Foundation of Everything

Every advanced capability depends on modeling:

  • Pattern definition
  • Validation
  • AI analysis
  • System improvement

Without m(x):

  • None of this is possible

Closing Reflection

We began with:

  • Raw experience

Now we have:

  • Structured understanding

The TODO-app is no longer just:

  • A tool

It is:

A model of work itself

And once we can model work, something changes:

  • We can understand it
  • We can improve it
  • We can evolve it

Because we are no longer reacting to events.

We are:

Seeing the structure behind them

This is the power of ORIGIN.

Turning experience into:

A system we can truly understand

ZenOps 080

From Model to Patterns (u(m) = p)

We have now walked through the first critical stages of ZenOps:

  • Experience (x) → what actually happens
  • Modeling (m(x)) → objects and relations
  • Boundaries (EQ) → where the system begins and ends

At this point, something important has emerged:

Clarity

We can see:

  • What exists
  • How it is connected
  • Where responsibilities lie

But clarity alone does not create action.

To move from understanding to execution, we need something more:

Patterns

This is the transformation:

u(m) = p

What Does u(m) Mean?

u(m) represents:

A meta-function applied to a model

It is the process of:

  • Interpreting structure
  • Identifying behavior
  • Extracting repeatable transformations

It answers the question:

Given this structure, how does the system behave?

From Static to Dynamic

Models (m(x)) are:

  • Structural
  • Static representations

Patterns (p) are:

  • Behavioral
  • Dynamic transformations

The shift is:

From:

  • What the system is

To:

  • What the system does

Why This Step Matters

Without patterns:

  • Models remain descriptive
  • Systems remain passive

With patterns:

  • Systems become executable
  • Behavior becomes predictable
  • Knowledge becomes reusable

Identifying Patterns in the TODO Domain

Let us return to the TODO-app.

We have:

  • Objects → Task, User, State
  • Relations → assignedTo, dependsOn, hasState

Now we ask:

What behaviors exist within this structure?

Pattern 1: Task Creation

Context:

  • A new unit of work is identified

Input:

  • Task description
  • Context

Transformation:

  • Create Task object
  • Assign initial state

Output:

  • Task exists in system

Pattern 2: Task Assignment

Context:

  • A task requires ownership

Input:

  • Task
  • User

Transformation:

  • Establish assignedTo relation

Output:

  • Responsibility is defined

Pattern 3: Task Transfer

Context:

  • Current assignment is no longer valid

Input:

  • Task
  • Current User
  • New User

Transformation:

  • Update assignedTo relation
  • Record reason

Output:

  • Responsibility shifts

Pattern 4: Task Completion

Context:

  • Work has been performed

Input:

  • Task
  • Completion criteria

Transformation:

  • Change state to completed

Output:

  • Task is finished

Patterns as Transformations

Each pattern represents:

A transformation of the system

From one state to another.

Patterns define:

  • Behavior
  • Flow
  • Change

The Structure of a Pattern

In ZenOps, every pattern includes:

  • Context → when it applies
  • Input → what it requires
  • Transformation → what happens
  • Output → what changes

This makes patterns:

  • Explicit
  • Testable
  • Reusable

From Implicit to Explicit Behavior

In traditional systems:

  • Behavior is hidden in code
  • Understanding is fragmented

In ZenOps:

  • Behavior is explicit
  • Patterns are visible

This creates:

  • Shared understanding
  • Better communication

CQ and Pattern Extraction

Extracting patterns requires:

  • Awareness
  • Reflection
  • Recognition of repetition

CQ enables us to:

  • See patterns in behavior
  • Distinguish signal from noise

Patterns Reveal System Logic

Once patterns are defined, we can see:

  • How the system operates
  • Where inefficiencies exist
  • Where improvements are possible

Example: Detecting Inefficiency

Observation:

  • Tasks are frequently transferred

Pattern insight:

  • Assignment pattern is unstable

Possible improvement:

  • Improve initial assignment logic

From Patterns to Prediction

Patterns allow us to:

  • Predict outcomes

Given:

  • Context + input

We can anticipate:

  • Likely results

Patterns as Units of Knowledge

In ZenOps, patterns are:

  • The smallest useful units of knowledge

They are:

  • Reusable
  • Validatable
  • Transferable

The Bridge to Validation

Patterns are not yet:

  • Proven

They must be:

Validated

This leads to the next stage:

  • StoryQ
  • Evidence
  • QT

From Understanding to Execution

With patterns, the system can now:

  • Execute behavior
  • Apply logic
  • Deliver outcomes

The TODO-App Transformed

Our TODO-app now contains:

  • Experience (x)
  • Models (m(x))
  • Boundaries (EQ)
  • Patterns (p)

It is no longer:

  • A static system

It is:

An executable system

The Deeper Insight

Understanding structure is powerful.

But understanding behavior is transformative.

Patterns are what make systems:

  • Alive
  • Functional
  • Evolvable

From Observation to Action

We have now crossed a critical threshold:

From:

  • Observing systems

To:

  • Defining how they act

Closing Reflection

Every system we interact with is governed by patterns.

Most of them are:

  • Implicit
  • Unexamined
  • Unoptimized

ZenOps makes them:

  • Explicit
  • Understandable
  • Improvable

Because once we can see patterns, something changes:

  • Behavior becomes predictable
  • Systems become controllable
  • Improvement becomes possible

And from this point forward, we are no longer just modeling reality.

We are:

Designing how reality behaves

This is the transformation:

u(m) = p

Where structure becomes behavior.

And understanding becomes:

Action