How Should a Runtime OS Be Architected? Comparing Centralized, Central–Edge Cooperative, and Federated CDR Edge Models

🎥 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

When generative AI and AI agents enter enterprise and societal operations, the question is no longer simply, “Which model is the smartest?”

Who finalizes a decision? Who authorizes execution? When an action crosses a boundary, what authority and responsibility are transferred? And can the entire process be reconstructed afterward?

Here, we call the execution infrastructure that addresses these questions a Runtime OS.

The core principle of the Runtime OS is clear:

AI generates Signals. Only the Runtime finalizes Decisions.

An AI output is not a Decision. An Agent proposal is not a Decision. Furthermore, the fact that a Decision has been finalized does not mean that external Execution has been authorized.

This article compares three architectural models for implementing a Runtime OS—a centralized architecture, a cooperative architecture combining a Central Runtime with CDR Edge, and a Federated CDR Edge architecture—and considers how to choose among them.

What the Runtime OS Handles

A Runtime OS is neither merely a Gateway for invoking models nor simply an Orchestrator that runs Agents in sequence.

It is the layer that connects Signals, Context, Policy, Permission, Risk, and human judgment to determine whether an action may proceed.

The basic flow is as follows:

Event / Interaction
  → Structured Signal
  → Context and Policy Evaluation
  → Decision Runtime
  → Boundary Check
  → Human Gate (when required)
  → Execution Permit
  → Execution
  → Decision Trace

Here, interaction-core-v2 functions as the Input / Interaction Layer. It transforms conversations, documents, sensor data, proposals from other Agents, and business events into structured Signals and Evidence. However, it does not finalize Decisions itself.

The same applies to a Multi-Agent Orchestrator.

It can assign research, comparison, planning, and execution preparation to multiple specialized Agents. But conversations or agreements among Agents do not create execution authority.

Only when the Runtime has finalized a Decision and issued a limited Execution Permit can an Agent perform an external action.

Core Components of the Runtime OS

The Enterprise Gateway handles authentication, authorization, model routing, usage management, and audit logging.

Within the Runtime OS, however, it is more than a connectivity component. It becomes a critical Boundary before actions enter the external world.

Architecture 1: Centralized Runtime

The simplest architecture places a single Decision Runtime at the center of the enterprise.

Each Agent, business application, and Gateway sends Signals to the Central Runtime, where Decisions, Human Gates, and Ledger records are handled.

flowchart LR
    I["Interaction / Agents"] --> R["Central Runtime"]
    R --> H["Human Gate"]
    R --> G["Enterprise Gateway"]
    R --> L["Decision Trace Ledger"]

This model makes it relatively easy to establish enterprise-wide Policies, Identity management, auditing, and Human Gates.

It is particularly effective in domains where unified governance and auditability are critical, such as finance, public services, healthcare, and core enterprise operations.

However, it is more vulnerable to network outages and central-system failures. It may also conflict with requirements for real-time local operation and data sovereignty.

An architecture in which every Decision must be sent to the center can become too heavy for domains such as Physical AI, factories, retail stores, and equipment operations.

Architecture 2: Central Runtime and CDR Edge Cooperation

The next stage is to deploy Chinoba Decision Runtime Edge (CDR Edge) close to sites, facilities, devices, or operational environments, while dividing responsibilities between the Edge and the Central Runtime.

CDR Edge processes delegated low- to medium-risk Decisions locally according to signed Policy Bundles and Delegation Contracts.

The Central Runtime handles enterprise-wide Decisions, high-risk processes, policy changes, formal Human Gates, and final Ledger commitments.

flowchart TB
    subgraph Edge["Site / Edge"]
        IC["Interaction Core v2"] --> E["CDR Edge"]
        E --> EG["Local Gateway Adapter"]
        E --> J["Local Trace Journal"]
    end

    subgraph Central["Central"]
        R["Central Runtime"] --> H["Human Gate"]
        R --> L["Decision Trace Ledger"]
    end

    E -->|"escalation / sync"| R
    R -->|"policy / delegation"| E
    J -->|"commit"| L

In this architecture, the central layer is not simply a massive execution server.

Instead, it becomes a Control Plane responsible for Policy, Delegation, auditing, and enterprise-wide optimization.

CDR Edge becomes the Decision Data Plane, where operational Decisions are executed close to where events occur.

For real-world enterprise adoption, this is often the most practical architecture.

It allows organizations to leverage existing investments in Enterprise AI Gateways and Ledgers while gradually increasing the autonomy of Edge environments.

However, if it is unclear whether the Edge or the Central Runtime holds final Decision authority, a form of dual sovereignty can emerge.

The scope, duration, targets, constraints, and revocation procedures of delegated authority must therefore be explicitly defined.

Architecture 3: Federated CDR Edge

For environments that require greater decentralization, every site, organization, or device can operate as a CDR Edge without requiring a Central Runtime.

We call this model a Federated Runtime OS.

Each Edge finalizes Decisions within the data, equipment, and operational domains for which it is responsible.

When work crosses organizational boundaries, one Edge does not directly control another. Instead, coordination occurs through Delegation Contracts and verifiable Decision Traces.

flowchart TB
    A["CDR Edge A\nFactory / Store"] <-->|"delegation"| B["CDR Edge B\nCompany / Division"]
    B <-->|"delegation"| C["CDR Edge C\nPartner / Region"]

    A --> L["Federated Trace Ledger"]
    B --> L
    C --> L

The advantages of this architecture include local availability, data sovereignty, and organizational autonomy.

Even when network connectivity is lost, each Edge can continue operating within its locally delegated authority.

Rather than sending all raw data to a central location, an Edge can share only Trace hashes, summaries, or selectively disclosed Evidence.

The trade-off is greater complexity.

Policy distribution, Identity verification, revocation notifications, conflict resolution between Edges, and Trace consistency all become more difficult.

A fully distributed architecture means that there is no mandatory central Runtime. It must never mean that there is no governance.

Comparing the Three Architectures

Five Principles That Must Survive Distribution

Regardless of which architecture is chosen, the core principles of the Runtime OS remain unchanged.

1. Separate Signals from Decisions

AI outputs, Agent proposals, and sensor values are Signals.

They do not become Decisions unless they have passed through Runtime evaluation.

2. Separate Decisions from Execution

Execution must be performed through a short-lived Execution Permit that limits the target, operation, duration, and number of allowed executions.

3. Make Delegation Explicit

Authority must never be transferred without a contract defining:

• Purpose
• Scope
• Authority
• Constraints
• Expiration
• Responsibility
• Revocation

4. Fail Closed When Verification Is Impossible

If authority, Policy, Identity, or revocation status cannot be verified, cross-boundary Execution must not proceed.

When clarification is required, the Runtime should Ask.

When the situation is unsafe, it should Stop.

5. Preserve Trace in a Shareable Form

Signal, Context, Policy, Candidate, Decision, Human Gate, Execution, and Outcome should be connected through a common Trace ID.

Local logs alone are insufficient to provide accountability across organizational boundaries.

Where Should Implementation Begin?

A good starting point is a minimal architecture in which a single CDR Edge can operate independently.

Interaction Core v2
  → Signal Ingress
  → Decision Kernel
  → Boundary Checker
  → Human Gate Adapter
  → Local Trace Journal
  → Enterprise Gateway Adapter

This can initially run as a single binary or a small set of services.

It should be capable of recording local Decision Traces even without external dependencies.

From there, organizations can gradually add:

Central Ledger
      ↓
Policy Distribution
      ↓
Federated Identity
      ↓
Edge-to-Edge Delegation

With this sequence, the core architecture does not need to be rebuilt regardless of whether the system ultimately evolves toward a Centralized Runtime, a Central–Edge cooperative architecture, or a fully Federated Runtime OS.

Conclusion

The value of a Runtime OS does not lie in bringing all AI into one centralized system.

Its value lies in enabling different AI systems, Agents, humans, organizations, and physical systems to coordinate while preserving their own boundaries and responsibilities.

The Central Runtime is strong at unified Policy, auditing, and Human Gates.

CDR Edge is strong at local responsiveness and autonomy.

Federated CDR Edge is strong in environments where no single sovereign authority can be assumed—such as cross-organizational ecosystems, regional infrastructure, and societal-scale systems.

The essential principle is that the Agent must never become the sovereign decision-maker.

The Agent generates Signals, makes proposals, and executes approved Decisions.

The Runtime finalizes the Decision.

The Boundary protects the limits of authority.

The Human Gate assumes responsibility where human judgment is required.

And the Ledger preserves the process for the future.

That is the role of the Runtime OS: transforming AI from a system that merely generates responses into an explainable, accountable, and trustworthy coordination system.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance