Runtime OS の詳細検討 Signal Input Layerについて

🎥 The YouTube version is also available:

Runtime OS: The Missing Infrastructure for Autonomous AI | Beyond AI Agents

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

Just as a conventional operating system provides 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, people, rules, organizations, and the physical world.

Where a conventional OS coordinates:

CPUs, memory, and processes,

a Runtime OS coordinates:

decisions, agents, boundaries, accountability, and human approval.

From this perspective, the architecture of a Runtime OS has a strong correspondence with conventional OS architecture. The Signal Input Layer corresponds to device drivers; the Decision Scheduler to the CPU scheduler; the Decision Runtime Kernel to the kernel; and the Boundary Layer to access control. AI-era decision systems can increasingly be understood through this OS-like structure.

This section examines the Signal Input Layer in detail.

Overview

A conventional operating system must first receive information from the outside world.

Examples include:

• Keyboard input
• Mouse actions
• Network traffic
• Sensor data
• Disk I/O

An OS does not pass these inputs directly to applications. Between the physical input and the application are mechanisms such as:

• Device drivers
• I/O control
• Interrupt handling
• Input abstraction

Consider a keyboard. Manufacturers and communication protocols vary, but the OS absorbs these differences and exposes them in a unified form as “key input events.”

In other words, the I/O layer of a conventional OS is:

A layer that transforms the complexity of the physical world into a form that can be handled inside a computer.

The Runtime OS faces the same fundamental problem.

In the AI era, however, the inputs are far more complex. They include:

• LLM-generated outputs
• Sensor data
• API events
• Human inputs
• Notifications from other agents
• Social-media posts
• Log data
• Monitoring-system alerts
• IoT device state changes
• Updates from business systems
• Responses from external services

A Runtime OS therefore receives signals continuously from:

AI, people, organizations, and the external world.

The important point is that these inputs are not merely “data.”

For example:

Temperature: 98°C

This value alone does not tell us whether it is dangerous.

For a Runtime OS, what matters is whether it represents:

• An anomaly in manufacturing equipment
• A medical risk
• A sensor malfunction
• Temporary noise
• A situation requiring an emergency shutdown

The Input Layer of a Runtime OS is therefore not merely a layer that receives data. It is:

A layer that receives signals with meaning.

Equally important, the very concept of a “device” changes in a Runtime OS.

In a conventional OS, devices are hardware such as:

• Keyboards
• Mice
• GPUs
• Network interface cards
• Sensors

In a Runtime OS, however, the sources of input include:

• AI agents
• People
• External APIs
• IoT devices
• Robots
• Social-media platforms
• Business systems
• Organizations themselves

In other words:

In a Runtime OS, “devices” are AI, people, and the external world itself.

In manufacturing, for example, the following signals may arrive at the Runtime OS at the same time:

• A temperature sensor detects an anomaly
• An AI inspection agent identifies a potential defect
• A frontline worker submits an incident report
• A quality-management system raises an alert
• An ERP system reports an inventory anomaly

The Runtime OS should not treat these simply as logs. It should handle them as semantic signals that include:

• Severity
• Trustworthiness
• Priority
• Source
• Context
• Historical record

Only then can they be passed to the next layers, such as:

• The Decision Scheduler
• The Boundary Layer
• The Human Gate
• Escalation mechanisms

The Signal Input Layer is therefore:

The point of contact between a Runtime OS and the real world.

It is the entry point that transforms the large volume of signals flowing from AI, people, society, sensors, and organizations into a form that can support decisions.

A Concrete Design

The Signal Input Layer should not be designed as a simple input endpoint. It should be designed as:

The entry point that converts data arriving from the external world into signals that the Runtime OS can evaluate and act upon.

Its basic structure can be represented as follows:

External Sources
  ↓
Input Adapter
  ↓
Signal Parser
  ↓
Signal Normalizer
  ↓
Context Enricher
  ↓
Trust / Risk Scorer
  ↓
Signal Queue
  ↓
Decision Scheduler

1. Input Adapter

First, provide an adapter for each type of input source.

For example:

LLM Adapter
Sensor Adapter
API Adapter
Human Input Adapter
Agent Adapter
Log Adapter
Social Media Adapter
Database Adapter

The role of an adapter is to absorb differences among input formats.

LLM outputs, sensor readings, API events, and human comments all have very different structures. Rather than handling them directly, an adapter receives each input and passes it into a form that can be handled internally by the Runtime OS.

2. Signal Parser

Next, parse the received data.

For example:

{
  "raw_input": "temperature=98",
  "source": "sensor_01",
  "input_type": "temperature_reading"
}

At this stage, the input is still close to raw data.

The parser extracts attributes such as:

• Source
• Input type
• Timestamp
• Value
• Unit
• Location
• Related IDs

3. Signal Normalizer

Next, convert every input into a common Signal Schema.

For example:

{
  "signal_id": "sig_001",
  "source": "temperature_sensor_01",
  "source_type": "sensor",
  "signal_type": "temperature_anomaly",
  "value": 98,
  "unit": "celsius",
  "confidence": 0.91,
  "timestamp": "2026-05-26T10:00:00+09:00"
}

The key is to standardize the format.

Inside the Runtime OS, LLM outputs, sensor readings, and human inputs should all be treated as Signals.

4. Context Enricher

A signal in isolation often has limited meaning, so context must be added.

“Temperature: 98°C” alone is not enough to make a decision.

The system should enrich it with information such as:

• Which asset is involved?
• What is the normal temperature range?
• Has the same event occurred before?
• What process is currently running?
• Are nearby sensors also abnormal?
• Is there a related report from a person?
• Does it match past Decision Traces?

For example:

{
  "context": {
    "asset_id": "machine_12",
    "location": "factory_line_A",
    "normal_range": "40-70",
    "recent_history": "similar anomaly occurred twice in the last 24 hours",
    "related_signals": ["sig_0007", "sig_0008"]
  }
}

This is critical.

A Runtime OS should not operate on data alone. It should operate on context-enriched signals.

5. Trust / Risk Scorer

Next, assess the trustworthiness and risk of the signal.

For example:

{
  "trust_score": 0.86,
  "risk_score": 0.74,
  "urgency": "high",
  "requires_human_review": true
}

The scoring model should consider factors such as:

• Source trust: Is the source reliable?
• Confidence: How accurate is the detection or interpretation?
• Risk: What is the impact of leaving the event unaddressed?
• Urgency: Does it require immediate handling?
• Reversibility: Can the resulting action be reversed later?
• Human impact: Does it affect people directly?
• Legal or safety impact: Does it relate to regulation or safety standards?

6. Signal Queue

Evaluated signals should not always be passed directly to a decision process. They should first enter a queue.

Critical Queue
High-Priority Queue
Normal Queue
Low-Priority Queue
Audit Queue

This enables the Decision Scheduler to determine processing order.

For example:

• Risk to human life → Critical
• Risk of a factory shutdown → High Priority
• Routine logs → Normal
• Reference information → Low Priority
• Records retained for audit → Audit

7. Basic Signal Schema

A Runtime OS should establish a common schema early.

The following is a sufficient minimum structure:

{
  "signal_id": "sig_001",
  "source": "camera_agent",
  "source_type": "ai_agent",
  "signal_type": "risk_detection",
  "payload": {},
  "confidence": 0.82,
  "risk_score": 0.67,
  "urgency": "medium",
  "context": {},
  "requires_human_review": false,
  "timestamp": "2026-05-26T10:00:00+09:00",
  "trace_id": "trace_001"
}

8. A Practical MVP

There is no need to make the first implementation overly complex. These five components are enough to begin:

1. Input Adapter
2. Signal Normalizer
3. Context Enricher
4. Risk / Trust Scorer
5. Signal Queue

An initial implementation can be structured as:

FastAPI
  ↓
Pydantic Signal Schema
  ↓
PostgreSQL / Redis
  ↓
Risk Scoring Service
  ↓
Decision Scheduler

The Core Design Principle

The essence of the Signal Input Layer is not receiving input. It is converting input into signals that can support decisions.

Its design principle can therefore be expressed in one sentence:

The Signal Input Layer of a Runtime OS transforms diverse inputs from AI, people, and the external world into common signals enriched with context, trust, risk, and priority, then delivers them to the Decision Scheduler.

With this definition, it also connects naturally to the DTM flow:

Event → Signal → Decision → Boundary → Human → Log