Architecture

■ Architecture

This page presents the overall architecture of a decision system based on
Decision Trace Model × Multi-Agent Systems.

This architecture is not just a conceptual model.
It is implemented as:

a Decision Trace Ecosystem composed of multiple OSS components

It shows how key technologies such as:

• Decision Trace
• Multi-Agent Systems
• DSL (Domain-Specific Language)
• Behavior Trees
• Ontology
• Graph Neural Networks (GNN)

work together and are applied in real-world operations.

■ Overall Structure

Decisions are structured as the following flow:

• Event: Input or fact from the environment
• Signal: Predictions, scores, or generated outputs from AI models
• Decision: Rules that interpret signals and convert them into actions
• Boundary: Stop conditions and escalation rules
• Human: Responsibility and intervention points
• Log: Records of decisions and their reasoning

This diagram illustrates the decision-making flow based on the Decision Trace Model,
as well as the correspondence between each layer (Signal / Decision / Boundary / Human / Log) and the OSS components.

From left to right:
decision flow → execution components → recording and visualization

Within this architecture, the component that actually controls the decision flow is the Multi-Agent Orchestrator.

It integrates signals generated by multiple agents and executes the decision-making flow based on Decision Contracts and Behavior Trees.

■ Architectural Characteristics

This architecture is fundamentally different from conventional AI systems.

1. From “Model-Centric” to “Decision-Centric”

Conventional AI:

• Focus on improving model accuracy
• Decision logic is implicit in code or human judgment

Decision Trace Model:

• Treats decision structure itself as a design target
• Externalizes decision logic explicitly
• Makes decisions reusable and controllable

2. Separation of Concerns

Responsibilities are clearly separated:

• Signal Layer (LLM / ML): meaning generation and prediction
• Decision Layer (DSL / Rules): definition of decision logic
• Execution Layer (Behavior Tree): control of execution flow
• Boundary Layer: stopping and escalation control
• Human Layer: responsibility and final decision

This enables:

governance, auditability, and flexibility

3. Explicit Design of Boundaries

In conventional AI, it is unclear:

• Where to stop
• When to escalate to humans

In this architecture:

Boundaries are explicitly defined
Human intervention is built into the system by design

4. Role-Based Multi-Agent Structure

Instead of a single model, the system is composed of multiple agents:

• Signal Agent (prediction)
• Decision Agent (decision proposal)
• Policy Agent (rule validation)
• Risk Agent (risk evaluation)
• Execution Agent (execution)

These agents are orchestrated structurally using Behavior Trees.

5. Accumulation of Decision Trace

Conventional systems record only results.

This architecture records:

• decision content
• applied rules
• branching paths
• boundary conditions

This enables:

• explainability beyond XAI
• reproducibility
• continuous improvement

■ Decision Trace Ecosystem (Implementation Mapping)

This architecture is not just conceptual.
It is implemented as OSS components on GitHub.

Concept → Implementation

1. Decision Structure

Definition of concepts, schema, and core architecture
Decision Trace Model
https://github.com/masao-watanabe-ai/decision-trace-model

2. Orchestration

Multi-agent decision control
Multi-Agent Orchestration Core
https://github.com/masao-watanabe-ai/multi-agent-orchestrator-core

3. Logging

Append-only ledger for recording and replaying decision processes
Decision Trace Ledger Core
https://github.com/masao-watanabe-ai/Decision-Trace-Ledger-Core

4. Execution

Execution engine for decision workflows (DSL + Behavior Tree)
Decision Trace Engine
https://github.com/masao-watanabe-ai/decision-trace-engine

5. Visualization

Interface for visualizing decision flows
Decision Trace Viewer
https://github.com/masao-watanabe-ai/decision-trace-viewer

6. Design / Debug

Environment for designing, inspecting, and analyzing decision flows
Decision Trace Studio
https://github.com/masao-watanabe-ai/decision-trace-studio

■ Development Approach

This architecture fundamentally changes how systems are developed.

Conventional AI Development

• Train models → deploy → evaluate accuracy
• Business logic is implicit
• Hard to modify or audit decision processes

Decision Trace × Multi-Agent Development

• Define meaning using Ontology
• Design decision rules using DSL
• Define execution structure using Behavior Trees
• Assign roles using Multi-Agent systems
• Design boundaries explicitly
• Accumulate and improve through Decision Trace

This represents a shift:

from “building models”
to “designing decision systems”

■ Technical Components

• Decision Trace Model
• Multi-Agent Systems
• Ontology
• DSL (Decision Rules)
• Behavior Tree
• Graph Neural Networks (GNN)

■ Related Articles

This architecture is composed of multiple technical components and design principles.
The following articles provide a deeper explanation of each element.

Overall Architecture & Design Philosophy

• Architecture of AI Orchestrator — A Decision OS for Controlling Multi-Agent AI —
• Blueprint of AI Systems — Decision Architecture Based on Event / Signal / Decision / Boundary / Human / Log —
• Orchestrating Multi-Agent AI with Decision Trace Model — Distributed Decision-Making and Its Control Structure —

Start here to understand the overall structure

Decision Trace / Decision Infrastructure

• Decision Ledger — Infrastructure for Recording AI Decision Histories —
• Why AI Can’t Make Decisions — The Reason We Built Decision Trace Ledger Core
• Where Should Stop Conditions Be Defined? — Externalizing Boundaries and Designing Return-to-Human —

How decisions are recorded and controlled

Multi-Agent / Orchestration

• Integrating LLM Agents into an AI Orchestrator — Using Generative AI Within Decision Structures —
• How to Design an AI Orchestrator — Implementing Decision Structures with GNN, Ontology, DSL, and Behavior Trees —

Coordination and control of multiple agents

Semantics, Rules, and Execution (Ontology / DSL / Behavior Tree)

• How to Build Ontology, DSL, and Behavior Trees Efficiently and Accurately — A Practical Approach to Designing Decision Structures —
• Externalizing Decision Logic — A Decision-Oriented Signal Platform with Ontology / DSL / Behavior Trees —
• What Is DSL? A Design for Adding Rigor to Prompts and the Decision Trace Model

Core technologies for making decisions designable

GNN / Learning Decision Structures

• GNN Design for Decision Trace Model — Making Decision Structures Learnable —
• Graph Neural Networks: A Technology Between Continuous Approximation and Semantic Discontinuity — Can AI Get Closer to Meaning?

Modeling relationships, propagation, and optimization of decisions

LLM Limitations & Design Philosophy

• LLMs Do Not Have “Decision” — Claude Code, Prompts, and the Concept of Externalizing Judgment —
• Creativity as Variation — The Essence of Human Creativity Revealed by LLMs and the Design of Controllable Creativity —
• Increasing Model Size Does Not Improve Decision Quality — Rethinking the Scaling Myth —

Why decision externalization is necessary

Simulation /Reinforcement learning/Decision Engineering

• How Does AI Make Decisions Without Data? — The Potential of Decision Systems in Medical Triage
• What is Cognitive Orchestration? — A Cognitive Architecture of Stability × Creativity × Variation Extending Reinforcement Learning

Combination with simulation

Design Patterns & Practical Implementation

• Treat Cold Start as a Contract — Turning Data Scarcity into a Design Problem —
• Externalizing Decision in Machine Learning Systems — The Design Philosophy of a Decision-Oriented Signal Platform —

Practical approaches to system design and implementation