■ Architecture
This page outlines the overall architecture of a
decision-making system based on Decision Trace Model × Multi-Agent Systems.
It explains how each component—Decision Trace, Multi-Agent, DSL, Behavior Tree, Ontology, and GNN—
works together and how the architecture is applied to real-world operations.
■ Core Structure
Decision-making is structured as the following pipeline:
Event → Signal → Decision → Boundary → Human → Log
- Event: Observations or inputs from the environment
- Signal: Predictions, scores, or outputs generated by AI models
- Decision: Explicit rules interpreting signals into actions
- Boundary: Conditions that define when to stop or escalate
- Human: Points of responsibility and intervention
- Log: Immutable records of decisions and their reasoning
Based on this structure,
multiple agents and execution flows (Behavior Trees) coordinate
to control decision-making and execution.
■ Architectural Characteristics
This architecture is fundamentally different from conventional AI systems.
1. From “Model-Centric” to “Decision-Centric”
Traditional AI:
- Focus on improving model accuracy
- Decision logic is implicit (embedded in code or human judgment)
Decision Trace Model:
- Focus on structuring decision-making
- Decision logic is explicit, externalized, and traceable
2. Separation of Concerns
Instead of a monolithic system, responsibilities are clearly separated:
- Signal Layer (LLM / ML models) → generates meaning and predictions
- Decision Layer (DSL / Rules) → defines how signals are interpreted
- Execution Layer (Behavior Tree) → controls flow and branching
- Boundary Layer → defines stop conditions and escalation
- Human Layer → ensures accountability
This separation enables governance, auditability, and flexibility.
3. Explicit Design of “Stop Conditions”
Conventional AI systems rarely define:
- when to stop
- when to defer to humans
In this architecture:
- Stop conditions are explicitly designed as Boundary
- Human intervention is part of the system, not an exception
4. Multi-Agent Coordination
Instead of a single AI model, the system is composed of multiple agents:
- Signal Agent (prediction)
- Decision Agent (proposal)
- Policy Agent (rule validation)
- Risk Agent (risk evaluation)
- Execution Agent (action execution)
These agents are orchestrated through structured flows (Behavior Trees),
not ad-hoc interactions.
5. Decision Trace as a First-Class Artifact
Traditional systems log results.
This architecture logs:
- decisions
- reasoning paths
- applied rules
- boundary conditions
This enables:
- explainability beyond XAI
- reproducibility
- continuous improvement of decision logic
■ Differences in Development Approach
Adopting this architecture changes how systems are built.
Conventional AI Development
- Train models → deploy → evaluate accuracy
- Business logic often remains implicit
- Hard to audit or modify decision processes
Decision Trace × Multi-Agent Development
- Define ontology (what things mean)
- Design decision rules (DSL)
- Structure execution (Behavior Tree)
- Assign roles (Multi-Agent)
- Define boundaries (stop conditions)
- Log and iterate (Decision Trace)
This shifts development 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 —
- 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
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 —
- Increasing Model Size Does Not Improve Decision Quality — Rethinking the Scaling Myth —
Why decision externalization is necessary
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
■ GitHub
The following repositories provide reference implementations and architectural components of the Decision Trace Model ecosystem:
- Decision Trace Model
Concept, schema, and core architecture definition - Decision Trace Engine
Execution engine for decision workflows (DSL + Behavior Tree) - Decision Trace Studio
UI / visualization tools for designing and analyzing decision flows - Decision Trace Platform
Integrated platform combining orchestration, agents, and decision infrastructure