Decision Scheduler — Coordinating AI Decision Execution in the Runtime OS

🎥 The YouTube version is also available:

Runtime OS Architecture: Centralized, Edge & Federated AI Decision Systems

Books: Runtime OS Implementation Guide: A Practical Architecture Integrating AI Agents, Human Gates, and Decision Traces

Just as a traditional Operating System (OS) serves as the foundation for safely coordinating computational resources such as CPUs, memory, and processes, a Runtime OS can be understood as the foundation for safely coordinating intelligence, humans, rules, organizations, and the physical world.

While a conventional OS is responsible for coordinating:

• CPU
• Memory
• Processes

a Runtime OS coordinates:

• Decision-making
• AI agents
• Boundaries
• Responsibility
• Human approval

From this perspective, the architecture of a Runtime OS has a remarkably strong correspondence with the architecture of a traditional operating system.

The Signal Input Layer corresponds to device drivers.

The Decision Scheduler corresponds to the CPU Scheduler.

The Decision Runtime Kernel corresponds to the operating system kernel.

The Boundary Layer corresponds to permission and access control.

In other words, AI-era decision systems can be understood as operating-system-like architectures.

This article focuses on the Decision Scheduler.

Overview (Equivalent to the CPU Scheduler)

Within the Runtime OS, the Decision Scheduler is one of its most critical core components.

Just as the CPU Scheduler plays the central role in a traditional operating system, the Decision Scheduler controls the flow of intelligence and decision-making within a Runtime OS.

In a conventional operating system, the CPU is a limited computational resource that must be shared safely and efficiently among multiple processes.

The operating system continuously determines:

• Which process should execute
• How much CPU time should be allocated
• The execution order of processes
• How interrupts should be handled
• How execution priorities should be assigned

Without a scheduler, a single process could monopolize the CPU, eventually bringing the entire system to a halt.

In other words, a CPU Scheduler is the mechanism that controls:

What should execute, when it should execute, and for how long.

Exactly the same challenge exists within a Runtime OS.

However, the Runtime OS is not scheduling CPU time.

Instead, it schedules:

• Decision-making
• Agent execution
• Human review
• Boundary evaluation
• Escalation
• Workflow coordination

The scarce resource within a Runtime OS is therefore not computational power.

Rather, it is:

The ability to make decisions safely.

This is why every Runtime OS requires a Decision Scheduler.

The Role of the Decision Scheduler

The Decision Scheduler determines:

Which decisions should be executed, under what conditions, and in what order.

More specifically, it determines:

• Which agents should be activated
• Which signals should receive priority
• Which boundaries should be applied
• Whether a Human Gate is required
• Whether escalation is necessary
• Whether execution should be suspended
• Whether decisions conflict with one another
• Whether they violate existing organizational policies

The scheduler is therefore an intelligence scheduler, rather than simply a process scheduler.

Why Is a Decision Scheduler Necessary?

If an AI system operated in complete isolation, a scheduler would not be particularly important.

However, real-world environments simultaneously involve:

• Multiple AI agents
• Human operators
• Business rules
• Laws and regulations
• Safety standards
• Operational constraints
• Organizational authority

Consider a manufacturing environment.

At any given moment, the system may receive:

• Temperature anomaly signals
• AI inspection results
• Worker reports
• Quality control rules
• Production schedules
• Safety boundaries

The central question becomes:

Which issue should be handled first?

For example, should the system:

• Immediately stop the production line?
• Wait for human approval?
• Execute additional AI analysis?
• Escalate the situation?
• Ignore the event as noise?

The component responsible for making these decisions is the Decision Scheduler.

Correspondence with the CPU Scheduler

A conventional operating system follows the execution flow:

Process
    ↓
CPU Scheduler
    ↓
CPU Execution

A Runtime OS follows an analogous structure:

Signal
    ↓
Decision Scheduler
    ↓
Decision Execution

The equivalent of CPU time within a Runtime OS is therefore:

Decision execution authority.

What Does the Decision Scheduler Manage?

The Decision Scheduler manages a wide variety of decision-related resources.

1. Signal Priority

The scheduler first evaluates the priority of incoming signals.

Signal	Priority
Human safety risk	Critical
Factory shutdown risk	High
Quality anomaly	Medium
Routine operational log	Low

2. Agent Scheduling

The scheduler determines which AI agents should be activated.

Examples include:

• Risk Analysis Agent
• Vision Inspection Agent
• Human Approval Agent
• Policy Validation Agent
• Escalation Agent

It also controls:

• Parallel or sequential execution
• Retry policies
• Termination conditions
• Execution ordering

3. Boundary Selection

The scheduler determines which boundaries should govern each decision.

Examples include:

• Safety Boundary
• Financial Boundary
• Medical Boundary
• Privacy Boundary
• Operational Boundary

For example, a financial transaction may require different boundaries depending on:

• Transfer amount
• Destination country
• Applicable regulations
• AML (Anti-Money Laundering) requirements
• Approval authority

4. Human Gate Scheduling

The scheduler determines whether human approval is required.

Examples include:

Action	Human Gate
Replying to an email	Not required
Contract modification	Required
Factory shutdown	Mandatory
Medical decision changes	Mandatory

The scheduler further determines:

• Who should approve the decision
• The required approval level
• Timeout policies
• Whether overrides are permitted

5. Escalation Control

When a situation exceeds predefined thresholds, the scheduler initiates escalation.

For example:

AI Agent
      ↓
Supervisor Agent
      ↓
Human Operator
      ↓
Manager
      ↓
Emergency Stop

This hierarchical escalation mechanism closely resembles interrupt handling in a traditional operating system.

Fairness in the Runtime OS

A scheduler in a conventional operating system is designed with several important objectives in mind:

• Preventing starvation
• Ensuring fairness
• Minimizing latency

A Runtime OS must address similar concerns.

It must ensure that:

• Critical decisions are never ignored.
• Human approvals do not remain pending indefinitely.
• Individual AI agents cannot monopolize the system or behave uncontrollably.
• Boundary bypasses are detected and prevented.

In other words, a Runtime OS requires decision fairness.

Rather than ensuring fair CPU allocation, it ensures the fair, safe, and timely execution of decisions across an organization.

The Essence of the Runtime OS Scheduler

In a traditional operating system, the scheduler exists to:

Control the execution order of CPU processes.

In contrast, the scheduler of a Runtime OS exists to:

Control the execution order of social and organizational decisions.

A Runtime OS coordinates decisions across:

• AI
• Humans
• Organizations
• Laws and regulations
• Safety requirements
• Operational environments

Its responsibility is to determine:

What should be executed right now.

Relationship with the Decision Trace Model (DTM)

Within the Decision Trace Model (DTM), the Decision Scheduler occupies the central position in the decision-making pipeline.

Event
    ↓
Signal
    ↓
Decision Scheduler
    ↓
Decision
    ↓
Boundary
    ↓
Human
    ↓
Execution
    ↓
Trace

The Decision Scheduler is therefore:

The core mechanism that transforms signals into executable decisions.

Design Principles of the Decision Scheduler

The Decision Scheduler can be defined as follows:

A Decision Scheduler is the core component of the Runtime OS that orchestrates multiple signals, AI agents, boundaries, human gates, organizational policies, and escalation conditions to determine which decisions should be executed, in what order, under which authority, and within what safety constraints.

This is the fundamental role of the scheduler within a Runtime OS.

Reference Architecture

The basic architecture of the Decision Scheduler is organized as follows:

Normalized Signal
        ↓
Decision Request Builder
        ↓
Priority Evaluator
        ↓
Policy / Boundary Resolver
        ↓
Agent Planner
        ↓
Human Gate Resolver
        ↓
Escalation Controller
        ↓
Decision Queue
        ↓
Execution Dispatcher
        ↓
Decision Trace

1. Decision Request Builder

The first step is transforming a Normalized Signal into a Decision Request.

A signal represents an incoming event.

A Decision Request represents an actionable decision candidate.

Example:

{
  "decision_request_id": "dr_001",
  "trace_id": "trace_001",
  "source_signal_id": "sig_001",
  "decision_type": "safety_response",
  "target": "machine_12",
  "requested_action": "evaluate_shutdown_need",
  "context": {
    "location": "factory_line_A",
    "risk_level": "high"
  }
}

The essential transformation is:

Signal
    ↓
Decision Request

2. Priority Evaluator

The Priority Evaluator calculates the execution priority of each Decision Request.

Typical evaluation criteria include:

• Risk level
• Urgency
• Human impact
• Business impact
• Reversibility
• Legal impact
• Confidence
• Source trust score
• Time sensitivity

Example:

{
  "priority": "critical",
  "priority_score": 0.93,
  "reason": [
    "high_risk",
    "human_safety_related",
    "low_reversibility"
  ]
}

An initial implementation only requires four priority levels:

• Critical
• High
• Medium
• Low

3. Policy / Boundary Resolver

The next step determines which boundaries and organizational policies apply to the decision.

Example:

{
  "boundaries": [
    "safety_boundary",
    "operational_boundary"
  ],
  "policies": [
    "factory_shutdown_policy",
    "human_safety_policy"
  ]
}

The resolver determines:

• Whether the decision involves a safety boundary
• Whether legal or regulatory requirements apply
• Whether human approval is mandatory
• Whether automatic execution is permitted
• Whether any stop conditions are triggered

4. Agent Planner

The Agent Planner determines which AI agents should participate in the decision.

Example:

{
  "agent_plan": [
    {
      "agent": "risk_analysis_agent",
      "mode": "sync",
      "timeout_sec": 10
    },
    {
      "agent": "policy_validation_agent",
      "mode": "sync",
      "timeout_sec": 5
    },
    {
      "agent": "human_approval_agent",
      "mode": "async",
      "timeout_sec": 300
    }
  ]
}

The Agent Planner determines:

• Which agents should be invoked
• Whether execution should be synchronous or asynchronous
• Whether agents should execute sequentially or in parallel
• Timeout values
• Retry behavior following failures

5. Human Gate Resolver

The Human Gate Resolver determines whether human approval is required.

Typical decision criteria include:

• High risk score
• Irreversible actions
• Human safety implications
• Medical, financial, or legal consequences
• Potential boundary violations
• Low AI confidence
• Organizational policies requiring human approval

Example:

{
  "requires_human_gate": true,
  "approval_level": "manager",
  "approval_reason": "human_safety_related_action",
  "timeout_sec": 300,
  "on_timeout": "escalate"
}

6. Escalation Controller

The Escalation Controller defines how exceptional situations are handled.

Example:

{
  "escalation_path": [
    "supervisor_agent",
    "human_operator",
    "plant_manager",
    "emergency_stop"
  ],
  "escalation_trigger": [
    "timeout",
    "boundary_violation",
    "agent_conflict",
    "risk_score_above_threshold"
  ]
}

Escalation is conceptually similar to interrupt handling in a conventional operating system.

When normal processing is no longer sufficient, control is transferred to a higher level of authority or to a safer execution path.

7. Decision Queue

Scheduled Decision Requests are placed into execution queues.

Typical queues include:

critical_decision_queue
high_decision_queue
normal_decision_queue
low_decision_queue
human_pending_queue
escalation_queue

Separating queues by priority is essential.

If all decisions are placed into a single queue, high-priority decisions may become delayed behind routine requests.

8. Execution Dispatcher

Finally, the Execution Dispatcher forwards approved decisions to the execution layer.

Example:

{
  "dispatch_target": "execution_layer",
  "execution_mode": "human_approval_required",
  "allowed_actions": [
    "stop_machine",
    "notify_operator",
    "request_additional_inspection"
  ],
  "blocked_actions": [
    "auto_restart_machine"
  ]
}

The Execution Dispatcher ensures that every decision is executed according to the constraints determined by the Decision Scheduler, including approval requirements, boundary conditions, and execution policies.

Decision Request Schema

The following schema represents a practical minimum structure for a Decision Request.

{
  "decision_request_id": "dr_001",
  "trace_id": "trace_001",
  "source_signal_ids": ["sig_001"],

  "decision_type": "safety_response",
  "target": "machine_12",
  "requested_action": "evaluate_shutdown_need",

  "priority": "critical",
  "priority_score": 0.93,

  "risk_score": 0.91,
  "urgency": "high",
  "confidence": 0.86,

  "boundaries": [
    "safety_boundary",
    "operational_boundary"
  ],

  "policies": [
    "factory_shutdown_policy"
  ],

  "agent_plan": [
    "risk_analysis_agent",
    "policy_validation_agent"
  ],

  "requires_human_gate": true,
  "approval_level": "manager",

  "escalation_path": [
    "human_operator",
    "plant_manager",
    "emergency_stop"
  ],

  "status": "scheduled",
  "created_at": "2026-05-26T10:00:00+09:00"
}

This schema captures the minimum information required to schedule, evaluate, and execute a decision within the Runtime OS.

Example Scheduling Rules

An initial implementation does not require sophisticated machine learning.

A rule-based scheduler is sufficient for an MVP.

if risk_score >= 0.9 and human_impact == True:
    priority = "Critical"
    requires_human_gate = True
    escalation_path = "Emergency"

elif risk_score >= 0.7:
    priority = "High"
    requires_human_gate = True

elif confidence < 0.5:
    priority = "Medium"
    agent_plan = "Additional Validation"

else:
    priority = "Normal"

These rules can later evolve into policy-driven or AI-assisted scheduling while preserving the same architectural framework.

MVP Implementation Structure

A practical MVP can be built using FastAPI, PostgreSQL, and Redis Queue.

A recommended project structure is:

scheduler/
    schemas.py
    request_builder.py
    priority_evaluator.py
    boundary_resolver.py
    agent_planner.py
    human_gate_resolver.py
    escalation_controller.py
    dispatcher.py
    service.py

Each module has a single responsibility, making the scheduler easy to extend and maintain.

Data Flow

The overall data flow through the scheduler is as follows:

normalized_signals table
          ↓
scheduler service
          ↓
decision_requests table
          ↓
Redis decision queues
          ↓
Agent / Human / Execution Layer
          ↓
decision_traces table

The scheduler transforms incoming signals into executable decisions while preserving complete traceability.

Example Pydantic Model

A Pydantic model for the Decision Request may look like the following.

from pydantic import BaseModel
from typing import List, Optional
from datetime import datetime

class DecisionRequest(BaseModel):
    decision_request_id: str
    trace_id: str
    source_signal_ids: List[str]

    decision_type: str
    target: str
    requested_action: str

    priority: str
    priority_score: float

    risk_score: float
    urgency: str
    confidence: float

    boundaries: List[str]
    policies: List[str]

    agent_plan: List[str]

    requires_human_gate: bool
    approval_level: Optional[str] = None

    escalation_path: List[str]

    status: str = "scheduled"
    created_at: datetime

This model represents the minimum information necessary for scheduling, policy evaluation, execution planning, and auditability.

Scheduling Workflow

A simplified scheduling process may be implemented as follows:

def schedule_decision(signal):
    decision_request = build_decision_request(signal)

    priority = evaluate_priority(decision_request)
    boundaries = resolve_boundaries(decision_request)
    agents = plan_agents(decision_request)
    human_gate = resolve_human_gate(decision_request, boundaries)
    escalation = build_escalation_path(decision_request, human_gate)

    decision_request.priority = priority["level"]
    decision_request.priority_score = priority["score"]
    decision_request.boundaries = boundaries
    decision_request.agent_plan = agents
    decision_request.requires_human_gate = human_gate["required"]
    decision_request.approval_level = human_gate.get("approval_level")
    decision_request.escalation_path = escalation

    save_decision_request(decision_request)
    enqueue_decision(decision_request)

    return decision_request

This workflow illustrates how the scheduler orchestrates multiple evaluation stages before a decision is allowed to enter the execution pipeline.

Architectural Core

The Decision Scheduler is much more than a component that simply determines execution order.

It serves as the central orchestration engine connecting:

Signal
    ↓
Decision Candidate
    ↓
Boundary Evaluation
    ↓
Human Gate Evaluation
    ↓
Escalation Decision
    ↓
Execution Authorization

The scheduler transforms raw signals into safe, executable decisions by coordinating organizational policies, AI agents, human oversight, and safety constraints.

Design Principle

The Decision Scheduler can therefore be defined as follows:

The Decision Scheduler is the core component of the Runtime OS that transforms multiple incoming signals into Decision Requests enriched with execution priority, safety boundaries, human approval requirements, AI agent execution plans, and escalation conditions, and schedules those requests for safe and coordinated execution throughout the Runtime OS.

With this architecture, the scheduler integrates naturally with the Decision Trace Model (DTM):

Event
    ↓
Signal
    ↓
Decision
    ↓
Boundary
    ↓
Human
    ↓
Log

The Decision Scheduler provides the missing bridge between Signal and Decision, enabling DTM to evolve from a conceptual model into an executable runtime architecture.