The Minimum Architecture for Decision-Capable AI — Light DTM Starter Kit Released

Introduction

AI is already sufficiently intelligent.

It can classify.
It can predict.
It can generate text.

And yet, in real-world operations, one thing has not changed:

“In the end, humans are still making the decisions.”

The reason is simple.

What AI produces is only Signal (input for judgment),
while what is actually needed in practice is Decision.

For example, in customer support, AI can:

• Classify inquiries
• Estimate urgency
• Generate response candidates

However, in real operations, what comes next is critical:

• Should we auto-reply?
• Should this be handed over to a human?
• Should it be held temporarily?
• Should it be escalated to a higher-priority queue?

These are decisions.

Because this layer does not exist as a structured system, we see the following problems:

• Results vary even with the same AI
• Decisions differ by operator
• It is unclear why a decision was made
• Decisions cannot be reproduced or improved

The core issue is not AI accuracy.
It is the absence of decision structure.

The simplest approach to solving this is:

Separating Signal and Decision.

The Light DTM Starter Kit we released is a minimal, runnable implementation of this idea.

As described in the README, it is a lightweight decision pipeline:

Signal extraction → YAML rule evaluation → structured Decision → Trace logging

👉 GitHub
https://github.com/masao-watanabe-ai/light-dtm-starter-kit-cs

What This Starter Kit Does

This Starter Kit is a minimal decision pipeline for customer support inquiries.

Given an input inquiry, the system processes it as follows:

Event (inquiry)
→ Preprocess
→ Signal (urgency, confidence, risk flags)
→ Decision (YAML rules)
→ Human (only when necessary)
→ Log (trace recording)

More concretely:

• The inquiry is converted into a structured signal
• The signal is matched against rules
• A decision is generated
• The entire process is recorded as a trace

The key design principles are:

• AI generates Signal
• Decision is defined as rules
• Human intervention is explicit and minimal
• Everything is recorded as a trace

This is not about letting AI make decisions directly.

It is about placing a decision structure on top of AI outputs.

Implementing “Signal ≠ Decision”

Instead of making decisions directly from raw text,
this system first extracts a structured signal.

The signal includes:

• urgency
• confidence
• risk_flags (e.g., complaint, legal, pii, system_error, critical, security)

Then, YAML-based rules are applied to produce a decision.

Each decision consists of three dimensions:

route (where it goes)

• auto
• human
• hold

action (what to do)

• reply
• assign_queue
• escalate
• none

decision_state (status)

• completed
• requires_human
• waiting

This separation enables:

• Decisions based on structured data instead of raw text
• Readable and maintainable rules
• Easy replacement of signal extraction with LLMs
• Full traceability from signal to decision

Running with Docker

To try this system, the easiest way is to run it with Docker.

1. Clone the repository

git clone https://github.com/masao-watanabe-ai/light-dtm-starter-kit-cs.git
cd light-dtm-starter-kit-cs

2. Create .env (optional)

cp .env.example .env

Defaults are sufficient for initial use.

Recommended minimal setup:

• Signal: heuristic (no LLM required)
• Decision: local rules
• Trace: file-based

LLM_ENABLED=false
DECISION_MODE=local
TRACE_MODE=file

3. Start the system

docker compose up --build

Available endpoints:

• App: http://localhost:8000
• Swagger UI: http://localhost:8000/docs
• Demo: http://localhost:8000/demo

Trace logs are written to:

./traces/

What to Check First

1. Health check

GET /health

{"status": "ok"}

2. Demo UI

http://localhost:8000/demo

You can:

• Enter inquiry text
• Set priority
• Add risk flags
• Execute decision

The result shows:

• route
• action
• decision state
• applied rule
• reason
• confidence
• trace ID

3. API (Swagger)

http://localhost:8000/docs

Test:

POST /api/decision/run

Example Usage

Input

{
  "id": "inq-001",
  "text": "Our payment system stopped responding 10 minutes ago.",
  "category": "technical",
  "priority": 7
}

Output

{
  "route": "auto",
  "action": "escalate",
  "decision_state": "completed",
  "applied_rule": "critical_risk_escalate",
  "reason": "High-risk flags detected...",
  "confidence": 0.95
}

What matters is not just the result, but that we can see:

• Which signal was generated
• Which rule was applied
• Why the decision was made
• What action was taken

Where Decisions Are Defined

Decisions are not embedded in code.

They are defined in:

app/rules/decision_rules.yaml

Example:

- name: critical_risk_escalate
  condition:
    risk_flags_any: ["system_error", "critical", "security"]
  route: auto
  action: escalate

This means:

If high-risk flags exist → automatically escalate.

Because of this design:

• Rules can be changed without code changes
• Decision logic is transparent
• Behavior is testable and auditable

How to Explore the System

Step 1: Normal inquiry

• Expect: auto + reply + completed

Step 2: High-risk case

• Add system_error
• Expect: escalate

Step 3: Ambiguous input

• Low confidence → hold or human

Step 4: Inspect traces

Check:

traces/traces.jsonl
traces/exports/*.json

You will see the full decision path:

preprocess → signal_extract → rule_match → execute

This is the essence of Decision Trace.

Before / After

Before

• AI output used directly
• Decision criteria implicit
• Operator-dependent
• Not explainable
• Not improvable

After

• AI used as Signal
• Decision explicitly structured
• Human intervention controlled
• Fully traceable
• Continuously improvable

Why This Matters

This Starter Kit is important because:

It works with the minimum structure.

DTM can scale to:

• Ontology
• Multi-Agent
• Behavior Trees
• Orchestrators
• Ledgers

But most real environments cannot start there.

Instead:

Start small.
Separate Signal and Decision.
Then expand.

Each layer can be replaced independently:

• Signal → LLM
• Executor → Orchestrator
• Trace → Ledger

Conclusion

AI is already powerful.

Yet automation stops in practice because:

Decision structure is missing.

Light DTM Starter Kit provides:

• Signal extraction
• Rule-based decision
• Human control points
• Full trace logging

—all in a minimal, runnable form.

You do not need a large system to begin.

Start small.

Place Decision on top of AI.

From there, a true decision system begins.