Chinoba — Runtime Society and Coordination Systems
https://chinoba.org

Just as traditional operating systems provide a foundation for safely coordinating computational resources such as CPUs, memory, and processes, Runtime OS can be viewed as a foundation for safely coordinating intelligence, humans, rules, organizations, and the physical world.

While conventional operating systems manage:

the coordination of CPUs, memory, and processes,

Runtime OS manages:

the coordination of decisions, agents, boundaries, responsibilities, and human approval.

From this perspective, the structure of Runtime OS exhibits surprisingly strong parallels with traditional operating system architectures.

The Signal Input Layer corresponds to device drivers.

The Decision Scheduler corresponds to the CPU scheduler.

The Decision Runtime Kernel plays the role of the kernel itself.

The Boundary Layer corresponds to permission and protection mechanisms.

As AI systems increasingly interact with humans, organizations, sensors, APIs, and other agents, decision-making systems are gradually evolving into structures that resemble operating systems.

In this series, we explore each layer of the Runtime OS architecture.

In this article, we focus on one of its most important components:

Signal Normalization Layer

If the Signal Input Layer serves as the gateway through which diverse information enters the system, the Signal Normalization Layer serves as the abstraction layer that transforms heterogeneous inputs into a common representation that the Runtime OS can process.

Importantly, this layer is not merely a data transformation layer.

Its essence is:

transforming information into meaningful, decision-ready signals.

In this article, we examine the design principles, internal structure, common signal schema, and implementation approach of the Signal Normalization Layer.

The Role of Signal Normalization Layer — The Semantic Abstraction Layer Inside the Kernel

If the Signal Input Layer is the entry point that receives various inputs from the external world, the Signal Normalization Layer is responsible for converting those inputs into a common representation that can be handled inside the Runtime OS.

Traditional operating systems do not expose device-specific differences directly to applications.

Keyboards, mice, USB devices, Bluetooth devices, file systems, and network interfaces all have different internal structures and communication mechanisms.

Yet the OS absorbs these differences and presents them uniformly as:

• Input events
• File operations
• Network communication

Runtime OS follows the same principle.

Passing raw differences directly into the Decision Runtime Kernel would make stable decision-making impossible.

The inputs flowing into Runtime OS are highly diverse:

• LLM outputs
• Computer vision detections
• Sensor values
• API responses
• Human comments
• Enterprise system logs
• Decisions produced by other agents

These inputs differ in format, granularity, and reliability.

An LLM may output:

“There may be an anomaly.”

A sensor may return:

temperature = 98

A human operator may report:

“The machine sounds louder than usual.”

An API may return a JSON status code.

If these inputs are handled as they are, Runtime OS cannot make consistent decisions.

This is precisely why the Signal Normalization Layer is necessary.

Its role is to convert heterogeneous inputs into common signals that the Runtime OS can understand.

For example:

{
  "signal_id": "sig_001",
  "source": "camera_agent",
  "source_type": "ai_agent",
  "signal_type": "risk_detection",
  "confidence": 0.82,
  "risk_level": "medium",
  "timestamp": "2026-05-26T10:00:00+09:00",
  "payload": {
    "detected_object": "worker_near_machine",
    "area": "factory_line_A"
  }
}

However, the objective is not simply to normalize everything into JSON.

The real purpose is to transform inputs into meaningful signals.

Consider:

temperature = 98°C

This is merely a number.

What matters to Runtime OS is not the value itself, but what the value means.

For example:

• Is it outside the normal operating range?
• Is it temporary noise?
• Could the sensor itself be malfunctioning?
• Does it affect worker safety?
• Should the machine be stopped?
• Should the signal be forwarded to Human Gate?
• Does it require immediate escalation?

These meanings are what matter.

Thus, Signal Normalization Layer transforms raw data into units that Runtime OS can reason about.

Instead of handling:

{
  "temperature": 98
}

it produces:

{
  "signal_type": "temperature_anomaly",
  "value": 98,
  "unit": "celsius",
  "confidence": 0.94,
  "risk_level": "high",
  "requires_attention": true,
  "source": "temperature_sensor_12",
  "timestamp": "2026-05-26T10:00:00+09:00"
}

This transformation enables Runtime OS to treat inputs from AI, humans, sensors, and APIs as common decision objects.

Five Major Functions of Signal Normalization Layer

1. Format Normalization

LLM outputs, API responses, sensor values, human reports, and logs are converted into a common Signal Schema.

2. Semantic Labeling

Inputs are assigned Signal Types such as:

• risk_detection
• anomaly_report
• approval_request
• policy_violation
• user_intent
• system_failure

3. Reliability Assignment

Different sources have different levels of trust.

High-precision sensors, unverified LLM outputs, subjective human observations, and external APIs cannot be treated equally.

Therefore, signals receive:

• confidence
• source_trust_score

4. Source and Timestamp Identification

Every signal records:

• when it occurred
• where it came from
• which system generated it

This becomes the foundation for Decision Trace.

5. Context Binding

A signal by itself is often insufficient.

It gains meaning only when connected to:

• asset IDs
• locations
• processes
• historical records
• related signals

Semantic Abstraction Layer

Signal Normalization Layer is not merely a data formatting layer.

It is the:

Semantic Abstraction Layer

of Runtime OS.

Just as the abstraction layers in traditional operating systems allow heterogeneous devices to be treated as unified I/O interfaces, Signal Normalization Layer enables inputs from:

• Humans
• AI systems
• Sensors
• APIs
• Agents

to be treated as unified decision signals.

Only because this layer exists can:

• Decision Scheduler prioritize signals,
• Boundary Layer evaluate safety boundaries,
• Human Gate determine whether human approval is required,
• Execution Layer verify executability,
• Decision Trace record the reasoning process.

Ultimately, the most important thing in Runtime OS is not collecting information.

What matters is:

transforming information into decision-ready signals.

That is the essence of the Signal Normalization Layer.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance