DTM Application Example 1: How to Handle Weak Signals, Ambiguity, and Human Gates — A Practical Decision Trace Model Case Study Through a Thermal Instability Scenario —

As generative AI, RAG, and multi-agent systems continue to spread across enterprises, a new class of problems is emerging.

Organizations are increasingly facing situations where:

• AI produces plausible answers
• Historical data can be searched
• Similar past cases can be retrieved

Yet ultimately:

“Can we really approve this case?”

cannot be confidently answered.

This “ambiguity at the decision boundary” becomes critically important in industries such as:

• Manufacturing
• Healthcare
• Finance
• Infrastructure

The following scenario is a typical example of this problem.

1. Scenario Overview

In this case:

• Voltage becomes slightly unstable under high-temperature conditions
• The threshold is not exceeded
• Similar historical cases exist
• But the outcomes differed

In other words:

• It may become a real failure
• Or it may simply be noise

Both possibilities exist simultaneously.

This is the key point.

This is not merely a “search problem.”

This is a problem of:

Decision Ambiguity

---

2. Before:Traditional Meetings / Simple RAG Architecture

Pattern A:

Human-Only Meetings

In traditional design reviews, decisions are often driven by:

• Veteran experience
• Memory of past incidents
• Departmental power balance
• Meeting atmosphere

As a result:

Why the decision was made

is often poorly preserved.

For example:

• QA strongly objected, so the release was stopped
• Management was in a hurry, so approval was granted
• Similar cases caused no issue before, so it was accepted

These situations happen frequently.

However:

Decision Trace

does not remain.

Pattern B:

Simple RAG + LLM

A common modern approach is:

Jira
Confluence
PDFs
Past failures
QA reports

searched through RAG,
with the LLM answering:

“There are similar historical cases.”

However, this also has limitations.

RAG can perform:

Information Retrieval

But it cannot properly handle:

• Contradictions between similar cases
• Failure / non-failure conflicts
• Safety boundaries
• Human escalation
• Conditional holds

In other words:

It can process Signals,
but not Decisions.

That is the core issue.

3. Actual Conversation and DTM Flow Step 1:Weak Signal Detection

<Conversation>

[Aiko]
This component shows slight voltage instability
under high-temperature conditions.

It still appears to be within the normal range,
but there are subtle fluctuations at peak load.

<Internal System Flow>

Sensor Data
   ↓
Signal Detection
   ↓
Risk Scoring
   ↓
Semantic Classification

<Runtime Internal State>

Signal Detected:
- Thermal Risk
- Voltage Instability
- Potential Safety Concern

Risk Score: 0.38

What Matters Here

In a typical RAG system,
this stage would likely end with:

Still within threshold → no issue

However, in DTM:

Weak Signal

is preserved.

Meaning:

Not yet a failure,
but not something that should be ignored.

4. Historical Knowledge Retrieval

<Conversation>

[Aiko]
It is still within the threshold,
but have we seen similar cases before?

<System Flow>

Runtime
   ↓
Knowledge Retrieval
   ↓
Failure Trace Search
   ↓
Decision Ledger Search
   ↓
QA Notes Search

<Actual Retrieval Sources>

Sources:
- Failure Trace
- Validation Reports
- Jira
- QA Notes
- Decision Ledger

What Matters Here

A normal RAG system performs:

Document Retrieval

But DTM performs:

Decision Retrieval

Meaning the system searches not only:

• What happened

but also:

• How decisions were made
• Why escalation occurred
• Why approval was granted

5. Similar Case Conflict

<Runtime Output>

Case A:
2025 Thermal Instability
→ Escalated to QA
→ Additional shielding added

Case B:
2024 Voltage fluctuation
→ Judged acceptable
→ No field issue observed

Confidence Conflict Detected.

<Internal System Flow>

Similarity Engine
   ↓
Case Comparison
   ↓
Outcome Conflict Detection
   ↓
Confidence Instability

The Critical Point

In normal RAG:

“There are similar cases.”

is the end of the process.

But in reality:

Similar cases can contradict each other.

This creates:

Knowledge Conflict

What matters here is not the search result itself,
but the ambiguity created by conflicting interpretations.

6. Approaching the Boundary

<Runtime State>

Decision ambiguity detected.

Risk Score adjusted: 0.52

<System Flow>

Conflict Detection
   ↓
Risk Recalculation
   ↓
Boundary Evaluation

What Is Happening Here

In DTM:

Conflicting information itself becomes a risk signal.

Meaning:

• Failure similarity exists
• Counterexamples exist
• Root cause remains unresolved

DTM explicitly handles:

uncertainty itself

7. Knowledge Holder Invocation and Boundary Escalation

<Initial State:Runtime Detects Ambiguity>

After retrieving historical cases,
the Runtime detected both:

• Failure cases
• Non-failure cases

Meaning:

Similar symptoms,
but different historical decisions.

At this point,
the Runtime detects:

Decision Ambiguity

<Additional Inquiry from Aiko>

[Aiko]
Even with similar symptoms,
the responses were different...

Is there anyone who remembers the historical context
or directly handled similar failures?

<Runtime>

[Runtime]
Searching for additional validation sources...

Candidate Knowledge Holders:
- Mina (QA Thermal Validation)
- Ken (Field Failure Analysis)

<System Flow>

Conflict Detection
   ↓
Organizational Graph Search
   ↓
Expert Routing
   ↓
Knowledge Holder Selection
   ↓
Human Knowledge Retrieval

What Matters Here

In ordinary RAG:

Knowledge = Documents

But in real organizations:

• The person who witnessed the failure
• The reviewer who stopped the release
• The engineer who analyzed the field issue
• The expert who remembers why the decision changed

are often more important than documents themselves.

Knowledge does not exist only inside PDFs.

<Knowledge Retrieval from Mina>

[Mina]
In the 2025 case,
temperature increase accelerated during continuous charging.

At first, the fluctuations were minor,
but the condition rapidly deteriorated during long-duration testing.

QA judged that
the initial symptoms were highly similar.

<Runtime State Update>

[Runtime]
Evidence correlation increased.

Thermal similarity score: 0.84

Risk Score: 0.68

Boundary Status:
NEAR_THRESHOLD

<Internal System Activity>

Human Knowledge Input
   ↓
Evidence Correlation
   ↓
Similarity Recalculation
   ↓
Risk Score Update
   ↓
Boundary Re-evaluation

<Counter-Evidence from Ken>

[Ken]
However, in the 2024 case,
similar fluctuations occurred,
but they never resulted in field failures.

The cause was sensor noise.

At the time,
it was treated as an overreaction.

<Runtime Internal State>

[Runtime]
Conflicting interpretation detected.

Current State:
- Failure similarity exists
- Counterexample also exists
- Root cause unresolved

Decision confidence unstable.

<Aiko’s Understanding>

[Aiko]
So both possibilities still exist:

- A truly dangerous early warning sign
- Or simply noise.

<Internal System Activity>

Human Knowledge Input
   ↓
Evidence Correlation
   ↓
Counterexample Detection
   ↓
Interpretation Conflict
   ↓
Decision Confidence Instability
   ↓
Boundary Re-evaluation

<Boundary Escalation>

[Runtime]
Boundary escalation condition detected.

Reason:
- Safety-related ambiguity
- Conflicting historical interpretations
- Insufficient causal certainty

Human Review Required.

Runtime Status:
WAITING_HUMAN_REVIEW

What Matters Here

A normal RAG system would stop at:

“There are similar cases.”

But DTM maintains:

• Failure-oriented evidence
• Non-failure-oriented evidence
• Human knowledge
• Interpretation conflict
• Causal uncertainty

as part of the:

Runtime State

The important question is not:

Which interpretation is correct?

The important question is:

Is it safe to approve this while ambiguity remains?

What DTM Truly Treats as Knowledge

In DTM:

Knowledge = Documents + Human Knowledge + Interpretation Conflict

Therefore the system goes beyond:

• PDF retrieval
• Similarity search
• Vector search

It also structures:

• Who interpreted the situation
• Why opinions diverged
• Why the Boundary was approached
• Why Human Review was triggered

This is the decisive difference
between ordinary RAG and DTM.

---

8. Human Gate Activation

<Runtime>

[Runtime]
Boundary escalation condition detected.

Reason:
- Safety-related ambiguity
- Conflicting historical interpretations
- Insufficient causal certainty

Human Review Required.

Runtime Status:
WAITING_HUMAN_REVIEW

<System Flow>

Boundary Threshold
   ↓
Escalation Trigger
   ↓
Human Gate
   ↓
Reviewer Assessment
   ↓
Decision Finalization
   ↓
Ledger Recording

<Reviewer Judgment>

[Reviewer]
I reviewed the case.

At this stage,
there is insufficient evidence
to conclusively determine danger.

However,
the similarity to previous failures is high,
and this involves a safety-critical domain.

Approving without additional thermal analysis
would be risky.

The following actions are required:

- Long-duration thermal test
- Sensor noise isolation
- Additional QA validation

Design approval will remain on hold
until the additional validation is completed.

<Runtime Decision Finalization>

[Runtime]
Decision Recorded.

Decision:
HOLD_WITH_ADDITIONAL_VALIDATION

Reason Trace:
- Weak thermal instability signal
- Historical conflict detected
- Failure similarity high
- Counterexample existed
- Human escalation triggered

Decision Trace Written to Ledger.

<Organizational Memory Update>

[Runtime]
Organizational Memory Updated.

Future signals involving:
- thermal instability
- ambiguous voltage fluctuation
- conflicting historical precedent

will reference this decision trace.

<Internal System Activity>

Interpretation Conflict
   ↓
Boundary Detection
   ↓
Human Escalation
   ↓
Safety-oriented Review
   ↓
Conditional Decision
   ↓
Decision Trace Generation
   ↓
Organizational Memory Update

The Core Point

AI can produce:

similarity

But it cannot bear:

responsibility

In this case:

• Failure similarity existed
• Counterexamples existed
• Root cause remained unresolved
• Safety implications existed

This was an:

ambiguous and incomplete situation

The goal is not:

finding the “correct answer”

The goal is:

handling dangerous ambiguity safely

What Happens Inside the Human Gate

The reviewer is not simply:

“approving AI output”

Instead, the reviewer evaluates:

• Signal strength
• Failure similarity
• Counterexamples
• Safety impact
• Causal uncertainty
• Validation cost
• Misjudgment risk

This is:

social decision-making

Another Critical Point

The final decision is neither:

APPROVE

nor:

REJECT

DTM allows:

HOLD_WITH_ADDITIONAL_VALIDATION

which represents:

an intermediate decision state

This is extremely important.

Real-world systems cannot operate solely through:

• Complete approval
• Complete rejection

Reality contains many intermediate states:

• Hold
• Conditional approval
• Additional validation
• Escalation
• Partial approval

DTM is designed to handle:

real-world ambiguity

inside the Runtime itself.

Why the Ledger Matters

Most importantly:

this decision is stored inside:

Organizational Memory

Meaning that future cases involving:

• thermal instability
• voltage fluctuation
• ambiguity conflict

can reference not merely:

FAQ knowledge

but:

how the organization previously decided

At this point,
the organization begins to develop:

Decision Memory

This is the essence of DTM.

9. Final Decision

<Runtime>

Decision:
HOLD_WITH_ADDITIONAL_VALIDATION

<System Flow>

Human Review
   ↓
Decision Finalization
   ↓
Ledger Write
   ↓
Organizational Memory Update

<Ledger Record>

Reason Trace:
- Weak thermal instability signal
- Historical conflict detected
- Failure similarity high
- Counterexample existed
- Human escalation triggered

10. Example OSS-Based System Architecture

<Minimal Architecture>

[ Sensor / Test Data ]
            ↓
      Kafka / Redpanda
            ↓
      Runtime Engine
     (Python / FastAPI)
            ↓
 ┌───────────────┐
 │ Signal Analyzer │
 │ Risk Scoring    │
 │ Similarity      │
 └───────────────┘
            ↓
      Vector DB
   (Qdrant / Weaviate)
            ↓
 Knowledge Sources
 - Jira
 - QA Notes
 - Failure Reports
 - Ledger
            ↓
      LLM Agent
(OpenAI / Ollama / vLLM)
            ↓
 Boundary Engine
(rule / threshold)
            ↓
 Human Gate UI
(React / Next.js)
            ↓
 Decision Ledger
(PostgreSQL / XTDB)

11. What DTM Actually Changes

The important thing is not:

higher AI accuracy

What truly changes is:

how ambiguity is handled

In this case:

It may be dangerous,
but we cannot conclude with certainty.

Traditional systems tend to reduce this into:

• Approve
• Reject

However, DTM can handle:

HOLD_WITH_ADDITIONAL_VALIDATION

as a legitimate intermediate decision.

12. DTM Is Not “AI Adoption”

DTM is not:

an LLM deployment methodology

It is:

a structure for transforming AI
into socially executable decisions

Most importantly,
DTM can explicitly handle:

• Ambiguity
• Exceptions
• Boundaries
• Responsibility
• Conditional holds
• Escalation
• Competing interpretations

In other words,
DTM is not:

a system where AI produces answers

It is:

a system that transforms
AI, humans, organizations,
and boundaries
into socially executable decisions
through structured decision flow.

Chinoba — Runtime Society and Coordination Systems:
chinoba.org