Forem: Takuya Niioka

Prioritizing Multiple Options: Switching Criteria by Context

Takuya Niioka — Thu, 27 Nov 2025 03:06:25 +0000

When Advancing Multiple Initiatives as a Team, Where Do You Start?

In the previous article ([@drawing-decision-boundaries]), I explained the importance of clarifying the boundaries of "what you should decide." As a system architect, defining the scope of judgment that you—not your boss, not your juniors—should make is the first step.

However, just because the boundaries are clear doesn't mean decisions become easy. Rather, new questions emerge.

"There are multiple initiatives the team should pursue. What should we propose, and in what order?"

In ADAS development work, we face this question daily.

AEB performance improvement
LKA adverse weather response
ACC comfort improvement in traffic jams
Next-generation sensor technology research
ISO 26262 compliance
Cost reduction initiatives
Development process improvement
Technical debt resolution
New employee training system establishment
Documentation maintenance

All of these are "important." But we can't do everything simultaneously. Choosing something means abandoning something else.

And what's most difficult is that this prioritization changes depending on who you're explaining to and what the current situation is.

The points you emphasize differ between internal team discussions and proposals to management
Priorities change between normal times and crisis situations
Options change between when resources are abundant and when they're limited

This article systematizes prioritization techniques learned from practical experience. In particular, I'll explain a practical approach that many textbooks don't discuss: "switching judgment criteria by considering who the decision is for and what the current situation is."

Why Is Prioritization Difficult?

The Essential Difficulty of Prioritization

Prioritization is difficult for the following reasons.

Reason 1: Everything appears "important"

In practice, things that "don't need to be done" don't make it onto the list. Everything on the list is important to someone.

Sales: "New features are top priority"
Quality Assurance: "Stability is top priority"
Finance: "Cost reduction is top priority"
Engineers: "Resolving technical debt is top priority"

Everyone is right. But we can't do everything at once.

Reason 2: Multiple judgment criteria exist

What makes something "high priority"? There isn't just one criterion.

Urgency (by when is it needed)
Importance (how much value does it have)
Feasibility (can we do it now)
Strategic importance (how does it connect to the future)

And these criteria sometimes contradict each other. Things that are urgent but not important. Things that are important but not urgent. Prioritization is about resolving these contradictions.

Reason 3: When the situation changes, the answer changes too

What's even more troublesome is that the "correct priority" changes depending on the situation.

Priorities change between this week and next month. Judgment criteria change between normal times and crisis situations. The points you emphasize change between internal team discussions and reports to management.

It's not a one-time decision but requires constant review. This is the essential difficulty of prioritization.

Common Failure Patterns

Here are three failure patterns commonly seen in practice.

Failure Pattern 1: Fixating on a single criterion

If you judge only by "urgency," you end up only responding to immediate problems. Things that are important but not urgent (strategic investment, personnel development, technology research) get postponed, and before you know it, you've fallen behind competitors.

If you judge only by "customer value," technical debt accumulates. Internal improvements that users don't notice are always postponed, and one day suddenly, the system collapses.

A single criterion is easy to understand. But reality is more complex.

Failure Pattern 2: Inconsistent judgment criteria

Monday: "Let's prioritize customer value"
Wednesday: "No, emergency response comes first"
Friday: "Isn't cost reduction important?"

When judgment criteria aren't consistent, the team becomes confused. They don't know what to believe and act on. As a result, no one can make decisions, and decision-making becomes paralyzed.

Failure Pattern 3: The loudest voice wins

Without clear judgment criteria, decisions become political.

The opinion of someone who loudly insists "This feature is absolutely necessary!" wins. Decisions are made by emotion, not data. As a result, decision-making becomes inconsistent, and later you can't explain "why we did this."

Conditions for Functional Prioritization

So what's needed for functional prioritization?

Condition 1: Clear judgment criteria
Articulate the criteria for what makes something "high priority."

Condition 2: Clarify who the decision is for
For customers? For the company? For your own career? Make the beneficiary clear.

Condition 3: Situational awareness
Is it normal times or crisis times? Are resources sufficient or limited? Correctly recognize the situation.

Condition 4: Visualize trade-offs
Doing this = not doing that. Make explicit what you're abandoning.

Condition 5: Flexibility
When the situation changes, change priorities too. It's not over once you decide.

This article proposes a practical framework that satisfies these five conditions.

Five Basic Prioritization Patterns

There are multiple "patterns" for prioritization. It's not that one is correct, but rather it's important to use them appropriately depending on the situation.

First, I'll introduce five basic patterns based on the axes of "for whom" and "what to emphasize."

Pattern 1: Urgency × Importance Matrix

Philosophy: "Consider both time constraints and importance"

The most famous is the Eisenhower Matrix. This is essentially a triage technique, judging where to allocate limited resources.

        Importance
        High  |  Low
    ─────────┼─────────
High |  ①   |  ③
Urgency    |      |
Low  |  ②   |  ④

①: Urgent and important → Do now
②: Important but not urgent → Schedule (most important!)
③: Urgent but not important → Delegate
④: Neither urgent nor important → Don't do

ADAS development example:

①: Emergency response to quality issues (regulatory violation risk)
②: Next-generation technology research (needed in 1 year)
③: Regular meeting material preparation
④: Organizing unread emails

When to use:

Personal task management
Short-term resource allocation
"What to do today" level decisions

Advantages:

Simple and easy to implement
Easy to explain
Easy to debug and test

Limitations:

Definition of "importance" is ambiguous (for whom? from what perspective?)
Insufficient for medium to long-term strategic decisions
Doesn't consider the situation

Pattern 2: Business Value Priority

Philosophy: "Maximize value for the company"

Judge by how much this initiative contributes to the company.

Evaluation criteria:

Contribution to revenue
Cost reduction
Risk mitigation
Competitive advantage

ADAS development example:

High Priority:
- Regulatory compliance (risk of not being able to sell)
- Major customer requirement response (directly linked to sales)
- Feature development with competitive advantage

Low Priority:
- Technically interesting but unclear market needs
- Will be needed eventually but not right now

When to use:

Proposals to management
Allocation of limited budget
"Which project to invest in" decisions

Advantages:

Easy to explain to executives
Can be quantified by ROI (return on investment)
Easy to get budget approval

Limitations:

Tends to favor short-term profits
Innovation gets postponed
Risk of decreased engineer motivation

Pattern 3: Customer Value Priority

Philosophy: "Maximize value for end users"

Judge by value to users.

Evaluation criteria:

User experience improvement
Safety improvement
Convenience improvement
Pain point resolution

ADAS development example:

High Priority:
- LKA performance improvement in adverse weather (many user complaints)
- AEB false positive reduction (damages user experience)
- ACC comfort improvement in traffic jams

Low Priority:
- Internal improvements users don't notice
- Important from engineer perspective but no experience change

When to use:

Determining product development direction
When user feedback is clear
"What should we build" decisions

Advantages:

High user acceptance
Directly linked to market evaluation
Increases team motivation

Limitations:

Technical debt accumulates
Regulatory compliance gets postponed
Internal improvements don't progress
What users say they "want" isn't necessarily right

Pattern 4: Career Priority

Philosophy: "Maximize value for your own career"

Judge by value for your career.

Evaluation criteria:

Skill acquisition (new experience)
Achievement building (results you can communicate externally)
Network expansion
Market value improvement

ADAS development example:

High Priority:
- New technology (LiDAR) project participation
- Results presentable at conferences
- Collaboration with global teams
- Leading next-generation system design

Low Priority:
- Routine work (familiar tasks)
- Coordination-heavy with unclear results
- Legacy system maintenance

When to use:

Personal career strategy
Choosing between multiple projects
"Which work to take on" decisions

Advantages:

Can accelerate personal growth
Increases motivation
Market value improves

Limitations:

Risk of divergence from organizational goals
If you only choose "interesting work," the team can't function
Favors long-term career over short-term results

Pattern 5: Strategic Balance (Portfolio Thinking)

Philosophy: "Balance multiple perspectives"

Judge comprehensively across multiple perspectives rather than a single criterion.

Four evaluation axes:

Urgency (by when is it needed)
Business value (importance to the company)
Customer value (impact on users)
Strategic importance (investment in the future)

ADAS development example:

Initiative	Urgency	Business Value	Customer Value	Strategic Importance	Overall Judgment
ISO 26262 compliance	High	High	Low	Medium	High
Next-gen sensor research	Low	Medium	Low	High	Medium
LKA adverse weather performance	Medium	Medium	High	Low	Medium-High

Weighting example:

Situation A: Regulatory compliance deadline approaching
→ Urgency 40%, Business value 30%, Customer value 20%, Strategy 10%

Situation B: New product development phase
→ Urgency 20%, Business value 20%, Customer value 40%, Strategy 20%

When to use:

Medium to long-term roadmap development
Resource allocation optimization
Stakeholder coordination

Advantages:

Can integrate multiple perspectives
Can visualize trade-offs
Can fulfill accountability

Limitations:

Complex implementation
Need rationale for weighting
Analysis takes time

Three Supplementary Patterns

The five basic patterns judge by "for whom" and "what to emphasize." However, in practice, another perspective is needed: "execution constraints."

The following three supplementary patterns are used in combination with the basic patterns.

Pattern 6: Dependency Priority

Philosophy: "Clear what's blocking others first"

If you prioritize without considering dependencies, rework occurs later.

Evaluation criteria:

What else stops if this task isn't completed
How many tasks depend on this

ADAS development example:

High Priority:
- Common interface design for sensor data
  → Multiple feature developments are waiting for this
- Test environment setup
  → All quality verification depends on this

Low Priority:
- Independent improvement initiatives (don't affect others)

When to use:

Team development with many parallel tasks
Technical debt is blocking other development
Timing decisions for infrastructure setup

Advantages:

Increases overall team productivity
Prevents rework
Enables parallel work

Limitations:

Takes time to understand dependencies
Risk of "non-blocking" tasks being postponed forever

Pattern 7: Risk Priority

Philosophy: "Validate high-uncertainty items first"

If you postpone high-risk tasks, the impact becomes larger when it's too late.

Evaluation criteria:

Technical feasibility is unknown
High external dependencies (third parties, regulatory changes, etc.)
Large impact if it fails

ADAS development example:

High Priority:
- Feasibility validation of new sensor technology
  → If found impossible, need to revise entire plan
- Regulatory trend research
  → Delayed response means can't sell

Low Priority:
- Implementation of features certain to be realized
- Improvements with known technology

When to use:

Considering introduction of new technology
Early stages of high-uncertainty projects
Want to validate hypotheses early in long-term projects

Advantages:

Can discover failures early
Minimize rework costs
Can reduce uncertainty

Limitations:

Definition of "risk" is subjective
Certain tasks get postponed, making results less visible
Team may become unstable

Pattern 8: Quick Win Priority

Philosophy: "Start with things that show results quickly to build momentum"

Large results take time. However, by accumulating small successes, you can boost team morale and gain stakeholder trust.

Evaluation criteria:

Small effort (hours to days)
Visible effects
Leads to improved team morale

ADAS development example:

High Priority:
- Build time reduction (2 hours of work cuts it in half)
- Common bug fixes (30 minutes improves customer satisfaction)
- Documentation maintenance (1 day halves new hire onboarding time)

Low Priority:
- Large-scale architecture changes (takes months to see effects)

When to use:

Early in project when you want to build trust
Team morale is down
Want to show early results to stakeholders

Advantages:

Can show results early
Team morale improves
Gain stakeholder trust

Limitations:

Essential problem-solving gets postponed
Risk of only doing "easy things" and avoiding difficult challenges
Too focused on short-term results

How to Combine Basic and Supplementary Patterns

Supplementary patterns function as "constraints" on basic patterns.

Combination examples:

Basic: Developing with Pattern 3 (Customer Value Priority)
  ↓ However...
Constraint: Consider Pattern 6 (Dependencies)
  → First set up common interface, then individual feature development

Basic: Investment decision with Pattern 2 (Business Value Priority)
  ↓ However...
Constraint: Consider Pattern 7 (Risk)
  → First validate technical feasibility, then full investment

Basic: Annual plan with Pattern 5 (Balance)
  ↓ However...
Constraint: Consider Pattern 8 (Quick Wins)
  → Accumulate some small successes initially, then move to major initiatives

Important principle:
Supplementary patterns don't replace basic patterns, they complement them

Trade-off Comparison Table for 8 Patterns

What do you gain and what do you sacrifice when choosing each pattern? Here's a summary table of the overall picture.

[Basic Patterns: For Whom, What to Emphasize]

Pattern	What You Gain	What You Sacrifice	Suitable Situations
Pattern 1: Urgency×Importance	✓ Quick decisions ✓ Simple implementation ✓ Easy to explain	✗ Lack of strategic perspective ✗ Medium to long-term investment postponed ✗ Ambiguous definition of "importance"	Short-term decisions Personal task management Crisis response
Pattern 2: Business Value Priority	✓ Executive support ✓ Easy to get budget approval ✓ Can quantify by ROI	✗ Favors short-term profits ✗ Innovation postponed ✗ Decreased engineer motivation	Management proposals Budget allocation Investment decisions
Pattern 3: Customer Value Priority	✓ Improved user satisfaction ✓ Directly linked to market evaluation ✓ Improved team motivation	✗ Technical debt accumulates ✗ Regulatory compliance postponed ✗ Internal improvements don't progress	Product development Feature prioritization User-focused
Pattern 4: Career Priority	✓ Accelerated personal growth ✓ High motivation ✓ Improved market value	✗ Divergence from organizational goals ✗ Impact on team operations ✗ Short-term results less visible	Personal career strategy Project selection Self-investment decisions
Pattern 5: Strategic Balance	✓ Integration of multiple perspectives ✓ Visualization of trade-offs ✓ Can fulfill accountability	✗ Complex implementation ✗ Need rationale for weighting ✗ Analysis takes time	Medium to long-term roadmap Resource allocation Stakeholder coordination

[Supplementary Patterns: Execution Constraints]

Pattern	What You Gain	What You Sacrifice	Suitable Situations
Pattern 6: Dependency Priority	✓ Improved overall team productivity ✓ Prevents rework ✓ Enables parallel work	✗ Takes time to understand dependencies ✗ Independent tasks postponed forever ✗ Risk of only infrastructure work	Parallel development Technical debt blocking Infrastructure setup timing
Pattern 7: Risk Priority	✓ Discover failures early ✓ Minimize rework costs ✓ Can reduce uncertainty	✗ Subjective definition of risk ✗ Certain tasks postponed ✗ Results less visible	New technology introduction Early stages of high-uncertainty projects Hypothesis validation
Pattern 8: Quick Win Priority	✓ Can show results early ✓ Improved team morale ✓ Gain stakeholder trust	✗ Essential problems postponed ✗ Risk of avoiding difficult challenges ✗ Favors short-term results	Early in project Morale is down Trust building needed

Important insight:

What this table shows is that there is no "perfect pattern." All patterns have advantages and limitations, and you need to use them appropriately depending on the situation.

Basic pattern usage examples:

In crisis, respond quickly with Pattern 1, postpone strategy
In normal times, emphasize customer value with Pattern 3
For budget approval, emphasize business value with Pattern 2 to gain executive support
For annual planning, balance multiple perspectives with Pattern 5

Supplementary pattern combination examples:

Pattern 3 + Pattern 6: Emphasize customer value while resolving technical debt through dependencies
Pattern 2 + Pattern 7: Make investment decisions by business value while prioritizing risk validation
Pattern 5 + Pattern 8: Plan with balance while building trust with quick wins initially

How to Switch Patterns

So far I've introduced 8 patterns (5 basic + 3 supplementary). However, what's most important is "which pattern to use when."

The essence of prioritization isn't the patterns themselves, but being able to switch patterns according to the situation.

Four Triggers for Pattern Switching

Prioritization patterns need to be switched based on the following four triggers.

Trigger 1: Crisis Occurrence

Normal times: Developing with Pattern 3 (Customer Value)
         ↓
Crisis:   Quality issue discovered (regulatory violation risk)
         ↓
Response:   Immediately switch to Pattern 1 (Urgency×Importance)
         ↓
Action:   Invest all resources in problem resolution
         ↓
After recovery: Return to Pattern 3 (Customer Value)

Signs:

Regulatory violation risk
Quality issue discovery
Delivery deadline crisis
Budget overrun warning

Switching judgment criteria:

"If we continue as is, will it affect business continuity?"
→ YES → Immediately switch to risk priority

ADAS development example:

Normal times:
Priority 1: LKA adverse weather performance (customer value)
Priority 2: ACC comfort improvement (customer value)
Priority 3: Next-generation technology research (strategy)

After quality issue discovery:
Priority 1: Quality issue resolution (urgency×importance)
Priority 2: Recurrence prevention implementation
Priority 3: Everything else frozen

After problem resolution:
Return to Priority 1

Trigger 2: Time Horizon Change

Short-term (this week/month) → Pattern 1 (Urgency×Importance)
Medium-term (this quarter)   → Pattern 3 (Customer Value) or 2 (Business Value)
Long-term (this year onward) → Pattern 5 (Balance) + strategy emphasis

Signs:

Quarter transitions
Project phase transitions
Roadmap review timing

Switching judgment criteria:

"On what time horizon should this decision produce effects?"
→ Short-term → Urgency, effort
→ Medium-term → Customer value, business value
→ Long-term → Strategy, balance

ADAS development example:

Weekly level (short-term):
Pattern 1 (Urgency×Importance)
→ This week's task priorities

Quarterly level (medium-term):
Pattern 3 (Customer Value)
→ Next feature development priorities

Annual level (long-term):
Pattern 5 (Balance)
→ Roadmap development

Trigger 3: Stakeholder Change

Personal judgment        → Pattern 4 (Career)
  ↓
Team proposal      → Pattern 3 (Customer Value)
  ↓
Management approval → Pattern 2 (Business Value)

Signs:

Change in reporting line
Review meetings
Budget approval process

Switching judgment criteria:

"Who are you explaining to?"
→ Self → Career
→ Team → Customer value
→ Management → Business value
→ Multiple → Balance

ADAS development example:

Personal level (your own judgment):
"Should I join the LiDAR project?"
→ Judge with Pattern 4 (Career Priority)
→ New technology acquisition, achievement building, market value improvement

Team level (feature development proposal):
"Which feature should we develop next?"
→ Propose with Pattern 3 (Customer Value Priority)
→ User complaint resolution, experience improvement

Management level (budget approval):
"Why should we invest in this feature?"
→ Explain with Pattern 2 (Business Value Priority)
→ Revenue contribution, competitive advantage, risk reduction

Important insight:

Even for the same feature development, the points you emphasize change depending on who you're explaining to. This isn't lying, it's simply changing how you communicate to match the values the other party emphasizes.

Trigger 4: Resource Change

Abundant resources → Pattern 5 (Balance) with multiple parallel initiatives
  ↓ Budget cuts
Insufficient resources → Narrow to Pattern 2 (Business Value) or Pattern 3 (Customer Value)
  ↓ Further cuts
Minimal resources → Pattern 1 (Urgency×Importance) narrow to minimum

Signs:

Budget cut notification
Personnel transfers
Schedule compression requests

Switching judgment criteria:

"Are available resources sufficient?"
→ Sufficient → Balance type (reconcile multiple objectives)
→ Insufficient → Narrow down (business value or customer value)
→ Minimal → Minimum (urgency×importance)

ADAS development example:

When resources are abundant:
- Regulatory compliance + new feature development + technology research in parallel
→ Pattern 5 (Balance)

After budget cuts:
- Narrow to regulatory compliance + major features
→ Pattern 2 (Business Value Priority)

Further cuts:
- Regulatory compliance only
→ Pattern 1 (Urgency×Importance)

Five Questions for Pattern Selection

When actually choosing a pattern, you can select the appropriate pattern by answering the following five questions.

Question 1: Who is this prioritization for?

Prioritization always has beneficiaries. Clarifying who they are determines the pattern.

Beneficiary examples:

Customers → Pattern 3 (Customer Value Priority)
Company → Pattern 2 (Business Value Priority)
Self → Pattern 4 (Career Priority)
Team → Consider feasibility
Regulators → Compliance priority
Multiple beneficiaries → Pattern 5 (Balance)

Even for the same project, beneficiaries change depending on the situation. In normal times, prioritize customers; in crisis times, prioritize the company (business continuity). Such switching is necessary.

Question 2: What's the current situation?

Situational awareness is key to pattern selection.

Situation diagnosis:

Question	Answer	Recommended Pattern
Is there a crisis?	Yes	Pattern 1 (Urgency×Importance)
Time horizon?	Short-term (this week/month)	Pattern 1
	Medium-term (this quarter)	Pattern 2 or 3
	Long-term (this year onward)	Pattern 5
Who are you explaining to?	Self	Pattern 4
	Team	Pattern 3
	Management	Pattern 2
Resources?	Abundant	Pattern 5
	Insufficient	Pattern 2 or 3
	Minimal	Pattern 1

Example: ADAS feature development team

Situation diagnosis:
- Crisis: None
- Time horizon: Medium-term (this quarter)
- Stakeholder: Team-level judgment
- Resources: Somewhat insufficient

→ Recommended pattern: Pattern 3 (Customer Value Priority)
  Reason: Not a crisis, team-level judgment,
        to achieve medium-term goals

Question 3: What's the rationale for this pattern?

Pattern selection needs rationale.

Types of rationale:

Data: Market research, customer feedback, experimental results
Regulatory requirements: Criteria defined by law, industry standards
Management policy: Company strategy, annual goals
Resource constraints: Budget, personnel, time constraints
Past experience: Success/failure cases from similar projects

By making the rationale explicit, you can explain "why we chose this pattern." This is also important when reviewing later.

Question 4: What are the trade-offs?

We can't achieve everything simultaneously. Make explicit what gets sacrificed when you prioritize something.

Trade-off examples:

Choosing Pattern 3 (Customer Value Priority):
✓ User satisfaction improves
✓ Market evaluation increases
✗ Technical debt accumulates
✗ Regulatory compliance gets postponed

Choosing Pattern 2 (Business Value Priority):
✓ Easy to get executive support
✓ Easy to secure budget
✗ User experience may be sacrificed
✗ Risk of decreased engineer motivation

By visualizing trade-offs, you can recognize "what you're abandoning."

Question 5: Can you change the pattern when the situation changes?

This is the most important question.

Don't fixate on a pattern once decided; you need the flexibility to change patterns when the situation changes.

Flexibility check:

Q: If a crisis occurs, can you immediately change the pattern?
Q: When the quarter changes, is there a process to review priorities?
Q: When new information comes in, can you revise the judgment?
Q: Can the entire team share the reason for pattern switching?

To ensure flexibility, it's important to define pattern switching triggers in advance.

Practical Examples

Let's look at these concepts through three specific scenarios.

Scenario 1: Normal Product Development

Situation:

- Regulatory compliance completed
- No particular fires burning
- Considering how to prioritize next features

Things to do (5 items):

LKA adverse weather performance improvement
ACC traffic jam comfort improvement
AEB false positive reduction
Next-generation sensor technology research
Documentation maintenance

Step 1: Situation Diagnosis

Crisis occurrence: None
Time horizon: Medium-term (this quarter)
Stakeholder: Team-level judgment
Resources: Somewhat insufficient

Step 2: Pattern Selection

Recommended pattern: Pattern 3 (Customer Value Priority)

Reason:
- Not a crisis, so urgency priority unnecessary
- Normal operations, so should emphasize customer value
- However, strategic investment also needed, so complement with Pattern 5

Step 3: Priority Determination

1. LKA adverse weather performance improvement
   Customer value: High (many user complaints)
   Strategic importance: Medium (leads to differentiation)
   → Priority 1

2. AEB false positive reduction
   Customer value: High (damages experience)
   Strategic importance: Medium
   → Priority 1

3. ACC traffic jam comfort improvement
   Customer value: Medium (nice to have)
   Strategic importance: Low
   → Priority 2

4. Next-generation sensor technology research
   Customer value: Low (not yet manifested)
   Strategic importance: High (needed in 3 years)
   → Priority 2 (allocate some resources)

5. Documentation maintenance
   Customer value: None
   Strategic importance: Low
   → Priority 3 (if there's capacity)

Step 4: Monitor Switching Triggers

Trigger 1 (Crisis occurrence): None → Maintain status quo
Trigger 2 (Time horizon): Medium-term (this quarter) → Customer value priority
Trigger 3 (Stakeholder): Team level → Customer value priority
Trigger 4 (Resources): Somewhat insufficient → Need to narrow down

→ Conclusion: Based on Pattern 3 (Customer Value),
       complement with Pattern 5 (Balance)

First focus on 1, 2
When capacity allows, invest in 4
Postpone 3, 5

Scenario 2: Regulatory Compliance Deadline Approaching

Situation:

- ISO 26262 certification in 6 months
- Delayed response means can't sell
- Other tasks also piling up

Things to do (5 items):

ISO 26262 compliance (ASIL decomposition review)
LKA adverse weather performance improvement
Cost reduction initiatives
Development process improvement
New employee training system establishment

Step 1: Situation Diagnosis

Crisis occurrence: Yes (regulatory violation risk)
Time horizon: Short-term (6 months)
Stakeholder: Regulators, executives
Resources: Limited

Step 2: Pattern Selection

Recommended pattern: Pattern 1 (Urgency×Importance)

Reason:
- Deadline approaching → Urgency is most important
- High risk → Directly linked to business continuity
- Others can be postponed

Step 3: Priority Determination

1. ISO 26262 compliance
   Urgency: High (6 months)
   Importance: High (can't sell)
   → Priority 1 (concentrate resources)

2. LKA adverse weather performance improvement
   Urgency: Low
   Importance: Medium
   → Priority 3 (start after ISO completion)

3. Cost reduction initiatives
   Urgency: Medium (management request)
   Importance: Medium
   → Priority 2 (minimal response)

4, 5. Others
   → Priority 4 (freeze)

Step 4: Detect Switching Triggers

Trigger 1 (Crisis occurrence): Regulatory violation risk → Crisis mode
Trigger 2 (Time horizon): Short-term (6 months) → Urgency priority
Trigger 3 (Stakeholder): Regulators → Compliance priority
Trigger 4 (Resources): Limited → Narrow down

→ Conclusion: Switch to Pattern 1 (Urgency×Importance)

Full effort on ISO 26262
Cost reduction at minimum
Others completely postponed

6 months later, regulatory compliance completed:
Trigger 1 (Crisis resolved) → Return to normal mode
→ Switch to Pattern 3 (Customer Value)

Scenario 3: Career Turning Point

Situation:

- System engineer, 6th year
- Can choose from multiple projects
- Struggling with which work to take on

Options (4 items):

Legacy system maintenance (stable, but routine)
New architecture design (challenging, high risk)
Large project lead (management experience)
Collaboration project with overseas sites (global experience)

Step 1: Situation Diagnosis

Decision maker: Individual (your own career judgment)
Time horizon: Long-term (future career formation)
Resources: Time and energy are limited

Step 2: Pattern Selection

Recommended pattern: Pattern 4 (Career Priority)

Reason:
- Personal career judgment
- Not organizational requirement, but your own choice
- Considering future career formation

Step 3: Priority Determination

Your goals:
- Want to acquire more advanced technical expertise
- Also want to gain management experience
- Want to increase market value

1. Legacy system maintenance
   Skill acquisition: Low (already can do)
   Achievement building: Low (few growth opportunities)
   Market value: Low
   → Don't choose

2. New architecture design
   Skill acquisition: High (new technology)
   Achievement building: High (can demonstrate expertise)
   Market value: High (high market demand)
   → Top priority candidate

3. Large project lead
   Skill acquisition: Medium (management)
   Achievement building: Medium (leadership experience)
   Market value: Medium
   → Priority candidate

4. Overseas collaboration
   Skill acquisition: Medium (global experience)
   Achievement building: Low (limited technical depth)
   Market value: Medium
   → Hold

Step 4: Decision

Choice: 2 (New architecture design)

Reason:
- Strengthening technical expertise
- Market value improvement
- Greatest growth opportunity

3 (Project lead) is also attractive, but
prioritize establishing technical foundation first

However, if a crisis occurs (Trigger 1):
Prioritize team/company priorities over personal career

Summary - The Essence of Adaptive Prioritization

The essence of prioritization isn't the patterns themselves, but being able to switch judgment criteria according to the situation.

Three core principles:

1. Clarify who the decision is for

Even for the same initiative, value changes depending on whose perspective you view it from.

Value to customers
Value to the company
Value to your own career
Team feasibility

By clarifying the beneficiary, the rationale for prioritization becomes clear.

2. Recognize the current situation

When the situation changes, the criteria you prioritize also change.

Four switching triggers:

Crisis occurrence (normal times → emergency response mode)
Time horizon change (short-term → medium-term → long-term)
Stakeholder change (team → management)
Resource change (abundant → insufficient → minimal)

Constantly monitor these, and when the situation changes, change the pattern too.

3. Visualize trade-offs

We can't achieve everything simultaneously.

What gets sacrificed when you prioritize something. By making this explicit, you can make realistic judgments. And when reviewing later, you understand "why we made this decision."

Conclusion: Switching Judgment Criteria Is the Essence

There is no "single correct answer" for prioritization.

What's important is:

Knowing multiple patterns (5 basic + 3 supplementary)
Clarifying who the decision is for
Recognizing the current situation
Being able to switch patterns according to the situation
Designing triggers for switching

The 8 patterns introduced in this article each have appropriate use cases. And what's most important is "switching patterns by considering who the decision is for and what the current situation is."

Next time, I'd like to address "how to execute after deciding priorities" and "how to course-correct when things don't go according to plan."

[@drawing-decision-boundaries]
[@when-to-switch-decision-triggers]
[@stagnation-is-the-worst-decision]

[Disclaimer]

The content of this article represents the personal views of the author and does not represent the official views of any affiliated organization. The specific examples in the article are simplified models for explanation purposes and may differ from actual product implementations.

Between Safety and Value: Defining 'Correctness' Through Nine Years of Journey

Takuya Niioka — Sun, 23 Nov 2025 14:28:23 +0000

[Disclaimer]

The content of this article represents the author's personal views and does not reflect the official position of any organization. It does not refer to any specific projects or products.

Prologue: The "Why" I Almost Lost in Technology

For nine years as a professional, I've been involved in developing systems where safety is paramount. These were years spent constantly facing evolving technology while pondering what lies behind it: "What is safety?" and "What is the relationship between technology and people?"

When I first joined the company, I was eager to absorb as much knowledge as possible. I devoured specialized books on requirements engineering and system design, studied modeling techniques, and immersed myself in structuring and understanding complex requirements.

Every day was a struggle with new knowledge. I read through standards documents, tried to understand design methodologies, and wrestled with architectural thinking.

However, gradually through that learning, I came to feel that "why we build it" is a far more difficult question than "what to build."

For example, imagine a situation where you need to determine the operating range of a function. The specification says, "Under condition A, execute process B." That's understandable. But why that condition? Why not a different condition? What criteria is that decision based on?

When answering such questions, technical knowledge alone is insufficient.

Period of Challenge and Exploration (Years 1-4)

In the early days, I was overwhelmed by the depth of technology, yet proceeded with projects through trial and error. I believed without question that accurately meeting each requirement was "good work."

A Moment of Concrete Struggle:

On one project, I needed to determine the timing of a warning system. Too early and it would be disliked as a false alarm; too late and it wouldn't serve its purpose.

What's the system's detection accuracy?
What's the user's reaction time?
How do environmental conditions affect it?
What do the requirements specify?

I gathered these data points, plugged them into formulas, and derived the "optimal solution." But during actual verification, I realized: The mathematically optimal solution and the timing where people feel "secure" don't necessarily align.

No matter how much I designed according to requirements, there were moments when I couldn't tell if it was "truly contributing to safety" or "creating a meaningful experience for users."

At this time, I realized: The meaning of the word "safety" is not merely risk avoidance. It's directly connected to whether people and systems can build a trusting relationship—that is, whether people feel they can "trust and rely on" the system.

The Duality of Safety:

Objective Safety: Statistical metrics, physical performance, system reliability
Subjective Security: The sense of trust users feel, understanding of the system, predictability

Development involving safety must satisfy both. No matter how statistically excellent, if users feel "anxious" and don't use the system, that technology might as well not exist.

Pursuing safety means not just removing people's anxiety but also creating security. This realization determined the direction of my subsequent career.

Period of Reexamining Value (Years 5-7)

As I gained experience, I had more opportunities to observe industry trends and other companies' initiatives.

Different Approaches Observed in the Industry:

Approaches prioritizing rapid market entry
Approaches emphasizing thorough verification
Approaches using phased releases for learning

When I first observed these differences, I felt anxious. "Is our approach correct?" "Wouldn't a different approach be better?"

However, I gradually came to understand: Each approach has its own values. And I realized that defining and embodying those "values" is the most important work as an engineer.

Contrasting Values:

Approach A:
"Launch to market first, improve with feedback"
→ Advantage: Fast market learning
→ Risk: Initial quality issues

Approach B:
"Launch only after thorough verification"
→ Advantage: High quality and reliability
→ Risk: Delayed market entry

Which is correct? The answer is "both are correct."

What matters is clearly defining "which values we choose" as an organization. And maintaining consistency in that choice.

+----------------------+------------------------------+
|  Technical Focus     |      Meaning Focus           |
+----------------------+------------------------------+
| How does it work?    | Why realize it?              |
| (Function)           | (Value)                      |
+----------------------+------------------------------+
| Define development   | Define value criteria        |
| goals                |                              |
| "Specification"      | "Correctness"                |
+----------------------+------------------------------+

This diagram represents the contrast I became most acutely aware of during this period.

The left side, "Technical Focus," is the domain most engineers excel in. Reading specifications, writing design documents, implementing, and executing tests. These have clear procedures and relatively clear criteria for good or bad.

However, the right side, "Meaning Focus," is different. "Why is this function necessary?" "What value does it deliver to users?" "What do we really want to achieve?"—These questions have no single correct answer.

For Example: Decisions About a Control Function

Technical Perspective:

At what timing should it operate?
What level of detection accuracy is needed?
Within how many milliseconds should processing delay be kept?

Value Perspective:

Is this function to prevent users' "carelessness"?
To what extent should the system intervene so it doesn't feel "overprotective"?
How do we balance false positives with user experience?

The former is measurable, but the latter is a value judgment. And without clarifying the latter, you cannot determine the numbers for the former.

Stage of Integration (Years 8-9)

Around my eighth year, I finally understood where my interests lie. It's "the structure of value judgment" more than technology itself.

Any development has multiple "correct answers." If you prioritize cost, one design becomes correct; if you prioritize comfort, a different answer emerges. In other words, technology is always subordinate to value judgment¹.

Example of Value Judgment: Settings for a Function

Values	Setting	Reason	Trade-off
Safety First	Conservative	Allows for operational margin	Users may feel inconvenience
Convenience Focus	Aggressive	Emphasizes user experience	Smaller safety margin
Balanced	Variable	Adjusts to situations	Complex logic, harder to predict

Which to choose? That's nothing other than defining "our correctness."

What I felt in this process was that those who can clearly articulate "what is our correctness" are the ones who can truly lead engineering.

The Importance of Verbalization:

Engineers often tend to think "they'll understand without words." However, when operating as an organization, ambiguity is fatal.

Even if you say "prioritize safety," interpretations differ among people
Even saying "value user experience," there are countless priorities
Saying "don't compromise quality," it's unclear what's acceptable

Therefore, verbalizing values, sharing them within the organization, and making them function as decision criteria is necessary.

Even with technology to protect safety, you'll lose direction if you misidentify what to protect. That's why defining values—articulating as an organization "what safety means"—becomes the starting point of everything.

What I Learned:

Excellent engineering leaders are not just proficient in technology but are people who continuously ask "why" and can define "correctness."

They ask "what are we really trying to achieve?" in the midst of technical discussions. Before diving into specification details, they confirm "what value does this function deliver to users?"

And above all, they maintain consistency in decisions. They verbalize, share, and practice values so that decision criteria don't change between today and tomorrow.

Three Lessons Learned

1. Not "Searching for Correctness" but "Defining Correctness"

In real development, there's no single correct answer. Therefore, we need to clarify what values we prioritize and make decisions based on those criteria.

Concrete Approach:

Step 1: Verbalize Values

Example values in development:
1. Safety: Prioritize protecting human life
2. Reliability: Provide systems users can use with confidence
3. Transparency: Enable users to understand system behavior
4. Continuous Improvement: Constantly evolve through feedback

Step 2: Translate into Decision Criteria

Criteria for adding features:
- Does this feature enhance safety? (Value 1)
- Can users predict system behavior? (Value 3)
- Does it compromise reliability? (Value 2)

Step 3: Maintain Consistency

Don't easily change values once defined. When changing, discuss organization-wide and share clear reasons.

More than technical correctness, value consistency generates trust.

This applies not only to user trust but also to trust within the organization. When a leader's decision criteria are consistent, team members can confidently delegate decisions.

2. Safety is Not a "Function" but a "Relationship"

Safety is not the completeness of a system but the result of a trusting relationship with people. No matter how sophisticated the control, if users cannot "believe in it," it's not safe.

Case Study: When System Behavior Isn't Understood

Even when technically operating correctly, situations occur where users feel "I don't understand why it acted that way."

System's Judgment:

Detected situation
Calculated risk
Operated because threshold was exceeded

User's Perception:

"I don't understand why it acted that way"
"The system malfunctioned"
"I'll turn it OFF because I can't trust it"

In this case, the system was operating "correctly." However, the perception gap with the user damaged trust.

Solutions:

Visualize the system's reasoning
Provide information at timing users can understand
Clearly communicate system limitations

Safety is the "quality of relationship" born at the intersection of design philosophy and human understanding.

Importance of Human-Centered Design:

In system development involving safety, we need to place how humans feel at the center of design, not just technical performance.

Is system behavior predictable?
Is information provision timing appropriate?
Is there room for user intervention?
Are system limitations clearly communicated?

These are domains not directly addressed by standards, yet they're essential elements for actual safety.

3. Knowledge is a Tool, Thinking is the Axis

Modeling techniques, requirements definition, design documents—these are all tools to structure thinking. What matters is using tools to clarify "the logic of thinking."

Concrete Example: Utilizing Modeling

Modeling is a technique to visualize system structure and behavior. However, being able to use modeling techniques and being able to do good system design are different things.

Purpose of Using Modeling:

Visualize complex systems
Facilitate communication among stakeholders
Discover requirement gaps or contradictions early

However, judging what should be modeled is done by humans, not tools.

Having an Axis of Thinking:

What is good design?
↓
Not just meeting requirements, but flexibly responding to future changes
↓
Which parts are likely to change, which are stable?
↓
Abstract changeable parts and separate with interfaces
↓
Visualize structure with models and verify through reviews

Tools are the final step. The initial thought process is the essential work of engineers.

The ability to give form to thinking is what I now feel is an engineer's true fundamental strength.

Importance of Mental Models:

Experienced engineers have "patterns of good design" in their minds. These are mental models learned from past successes and failures.

What structure is maintainable?
What design has high extensibility?
What decisions won't lead to regret later?

It's important to express these mental models using tools and share them with the team.

Toward the Next Ten Years

What I learned over these nine years was an attitude of asking "what is safety?" beyond technology. Safety is not completion but a value that continues to be updated.

Future of System Development:

Increased complexity from full-scale introduction of AI/machine learning
Transition to advanced automation
Growing importance of security
Progress in coordinated control
Implementation of ethical judgments

Technology continues to evolve. However, the fundamental question of "how to build relationships between people and technology" remains unchanged.

Over the next ten years, more than polishing technology, I want to explore "mechanisms where people and technology can grow together." In that process, I want to develop "the power to define correctness" to an even higher dimension.

My Next Challenges:

Framework Value Judgment: Systematize the process of defining "correctness" as an organization
Acquire Global Perspective: Learn how safety is perceived in different cultures
Nurture Next Generation Engineers: Root a culture of asking "why" in the organization
Academic Exploration: Organize practical experience theoretically and disseminate it

If this article can be a light for someone who continues thinking between safety and value while lost daily, that would be my "correctness."

Finally: A Message to Readers

What is the "question without an answer" you're facing now?

In engineering fields, we're pressed for decisions every day. Many of them are questions not found in textbooks.

At that time, what are your decision criteria?

If you're not yet clear, I hope this article becomes a trigger for thinking.

And if you already have your own "correctness," please verbalize and share it. The engineering community evolves through such exchanges of knowledge.

With gratitude for nine years.

Value judgment is the act of articulating what results an organization or individual considers good. Design philosophy and product philosophy are its concrete forms. ↩

When to Switch Decision Criteria: Trigger Design for System Engineers

Takuya Niioka — Fri, 14 Nov 2025 07:47:18 +0000

In system development, we need to design behaviors that can change decision criteria depending on the situation and achieve different objectives, even for the same function. However, "when" and "what should trigger" the switch in behavior and objectives is a challenge many designers face.

In Advanced Driver Assistance Systems (ADAS) development, we confront this question daily. For example, consider driver monitoring in systems with partial driving assistance capabilities.

The system simultaneously holds two objectives: "ensure the driver monitors driving" and "intervene when the driver cannot monitor." The system must switch decision criteria between these two objectives.

Phase 1: Warning Mode (Objective: Prompt return to driving)

Detection: Gaze diverted from forward
Behavior: Warning sound, display notification
Decision criterion: "Driver can recover"

Phase 2: Escalation Mode (Objective: Forceful attention-getting)

Detection: 10 seconds elapsed ignoring warning
Behavior: Increased warning sound, steering wheel vibration
Decision criterion: "Driver can recover but requires force"

Phase 3: Emergency Intervention Mode (Objective: Minimize secondary damage)

Detection: No response for 30+ seconds + possible vital sign abnormality
Behavior: Safe stop, hazard lights, emergency call
Decision criterion: "Driver cannot recover, emergency response needed"

This raises an important question: Why switch to Phase 2 at 10 seconds and Phase 3 at 30 seconds? What philosophy lies behind these thresholds?

In system design, when incorporating multiple objectives into a single function, we frequently face the problem of blurred decision criteria. Trying to judge contradictory objectives like "prompt driving monitoring" and "intervene in emergencies" with a single threshold makes both half-hearted.

This article proposes "explicitly switching decision criteria." For functions with multiple objectives, we can prevent blurred judgment by preparing decision criteria for each objective and explicitly switching them according to the situation.

This article systematizes knowledge gained from ADAS development experience about designing "triggers" that switch decision criteria.

Three Elements of Trigger Design

Triggers that switch decision criteria consist mainly of three elements.

Element 1: Observable (Detectable State Changes)

What should be detected to trigger a switch?

For a system to change decision criteria, it must first be able to observe state changes. However, not all states can be measured by sensors.

ADAS development faces challenges such as:

Directly observable: Gaze direction, steering operation, speed, lane position
Requires estimation: Driver attention level, fatigue, intent
Difficult to observe: Consciousness level, cognitive load, sudden health changes

For example, the state "driver has lost consciousness" cannot be directly measured. It must be estimated from multiple indirect evidence: eye movement, blink frequency, posture collapse, abnormal steering operation.

Therefore, trigger design requires careful consideration of "what is observable" and "is the risk of false detection acceptable?"

Element 2: Threshold

At what level should the switch occur?

Once observable indicators are determined, we must decide "at what value to switch." This threshold setting always requires justification.

Threshold justifications include:

Ergonomic data: Human cognitive and physical capability limits
Statistical analysis: Data from experiments and field tests
Regulatory requirements: Standards defined by law or industry
Risk analysis: Worst-case scenarios from FMEA¹ etc.
Medical knowledge: Physiological and neurological research findings

For example, the threshold "how many seconds after gaze diversion to issue warning" can be determined based on ergonomic research data (visual attention duration averages 2-3 seconds).

However, not all thresholds have clear scientific basis. In many cases, engineers select "the most reasonable value" from limited data and experience, then adjust through validation testing.

Element 3: Consequence (Purpose and Result of Switching)

Why is the switch performed, and what changes?

When decision criteria switch, system behavior changes. However, understanding only "what changes" is insufficient. Documenting "why change" is key to designing appropriate triggers and behaviors.

Points to clarify when designing switches:

Change in objective: What decision criteria are we switching to prioritize?
- Phase 1 (Warning Mode): Respect driver autonomy
- Phase 2 (Forced Warning): Prioritize safety
- Phase 3 (Emergency Intervention): Prioritize minimizing secondary damage
Reversibility: Can we return to the previous state?
- If reversible, early intervention is possible
- If irreversible, more careful judgment is needed
Impact assessment:
- User experience impact: Will it cause discomfort or distrust?
- Safety impact: Will secondary risks occur?
- Legal responsibility: Is this switch legally acceptable?

For example, when ADAS switches from Phase 1 to Phase 2, the system's objective changes from "alert while respecting driver autonomy" to "intervene forcefully prioritizing safety." Clarifying this objective change also clarifies the threshold justification.

Furthermore, switching to Phase 3 changes the judgment to prioritize "minimizing harm to others" over "driver autonomy." This irreversible operation carries rear-end collision risk, requiring clear justification for "why switch objectives at this point."

Three Approaches to Trigger Design

There are three main philosophical approaches to trigger design. Each has advantages and disadvantages, requiring selection based on system characteristics.

Comparison of Three Approaches

Approach	What to Observe (Observable)	How to Determine Threshold	When to Use
Time-based	Duration of specific state	Fixed value (e.g., 2 sec, 10 sec)	When universal physical/physiological limits exist
State-based	System or driver state	Change threshold according to state	When priority objectives change by situation
Evidence accumulation-based	Integrate multiple observations	Score and make comprehensive judgment	When false detection is high with single indicator

Approach 1: Time-based

Philosophy: "Human cognitive and physical capabilities have physical limits"

Time-based triggers are the simplest and easiest to implement. They set clear rules like "switch after a state continues for X seconds."

ADAS example:

Gaze diverted for 2 seconds → Start warning
No response for 10 seconds after warning → Forced warning
No response for 30 seconds after forced warning → Safe stop

Why these values?

2 seconds: NHTSA guidelines² show that forward inattention exceeding 2 seconds significantly increases crash risk
3 seconds: Euro NCAP³ defines gaze diversion over 3 seconds as "prolonged distraction"
10 seconds: Line distinguishing intentional ignoring from temporary inattention (empirical threshold based on experimental data)
30 seconds: Time when loss of consciousness is physiologically likely

Advantages:

Clear and easy to implement
High explainability (easy regulatory compliance)
Easy debugging and testing

Disadvantages:

Doesn't consider situation (same criteria for highway or traffic jam)
Doesn't consider individual differences
Prone to over-intervention or under-intervention

Time-based approaches are effective in domains with universal human capability limits. For example, in fatigue management functions like "prompt rest after 2 hours continuous driving," time is the most important indicator.

Approach 2: State-based

Philosophy: "System objectives change depending on context"

State-based triggers change what to observe (Observable) and post-switch objectives (Consequence) according to situation. While time-based judges by "time as a single indicator," state-based observes "system or driver state" and switches the decision criteria themselves according to that state.

Relationship with three elements:

Observable: System operational state, estimated driver state, sensor reliability
Threshold: Dynamically adjust decision criteria according to state (not fixed values)
Consequence: Priority objectives change according to situation

ADAS example:

Situation	State to Observe	Priority Objective	Decision Criteria
Normal driving	System normal, driver alert	Respect driver autonomy	Longer to Phase 2 (15 sec from warning)
System abnormality	Sensor failure detected	Early safety assurance	Shorter to Phase 2 (5 sec from warning)
Driver fatigue	Fatigue signs present	Gradual arousal support	Repeat Phase 1 (delay Phase 2)

Essence of this approach:

In time-based, it's a fixed rule "switch after 10 seconds," but in state-based, "if the system is operating normally and driver fatigue signs are detected, prioritize repeating warnings to promote arousal" - switching the objective itself according to situation.

Why is it explainable:

To the question "why 5 seconds in this situation?", we can explain "because the system is in abnormal state and driver state estimation reliability is low, we're making an early decision toward the safe side." This is simply changing the three elements (Observable, Threshold, Consequence) according to situation, which is logically explainable.

Advantages:

Situation-specific optimization possible
Can reduce unnecessary intervention (improved user acceptance)
Can change objective priorities according to situation

Disadvantages:

Implementation becomes complex
State definition and detection required
Test cases increase

State-based approaches are powerful in systems where environmental and system state changes are large and priority objectives change according to situation.

Approach 3: Evidence Accumulation-based

Philosophy: "Judge by integrating multiple evidence, not a single indicator"

Evidence accumulation-based triggers integrate multiple observations (Observable) into a score, switching when that score exceeds a threshold. While state-based "changes decision criteria according to situation," evidence accumulation-based is an approach to "calculate confidence from multiple evidence."

Relationship with three elements:

Observable: Collect multiple observations simultaneously (gaze, steering operation, speed variation, etc.)
Threshold: Integrated score threshold (comprehensive judgment of multiple evidence, not single value)
Consequence: Gradually switch objectives according to score

ADAS example:

Evidence Score =
  Gaze-off time × 0.4 +
  Abnormal blink frequency × 0.2 +
  Unnatural steering operation × 0.3 +
  Speed variation instability × 0.1

if Evidence Score > 0.3:
    Warning Mode
elif Evidence Score > 0.6:
    Forced Warning Mode
elif Evidence Score > 0.8:
    Emergency Intervention Mode

Difference from state-based:

Approach	What to Judge	How to Determine Criteria	Example
State-based	Which state currently	Change threshold according to state	"System abnormal" → intervene early
Evidence accumulation-based	How confident	Integrate multiple evidence into score	Judge by total of gaze+operation+speed

Why this approach?

Single indicators alone lead to many false detections. For example, "gaze diverted" alone cannot distinguish mirror checking from distraction. However, if gaze is diverted AND steering operation is unnatural AND speed is unstable, distraction probability is high.

Advantages:

Can significantly reduce false detection
Can handle gray zones (quantify "somewhat suspicious")
Good compatibility with machine learning

Disadvantages:

Difficult to explain weighting rationale
Prone to black-boxing
Complex parameter adjustment

Evidence accumulation-based approaches have high affinity with modern machine learning technology and are expected to become increasingly important. However, ensuring explainability remains a challenge.

Trigger Design in Practice: Five Design Questions

When actually designing triggers, answering the following five questions can improve design quality.

Question 1: Who is this decision criteria switch for?

Decision criteria switches always have beneficiaries. Clarifying who they are reveals priorities.

Driver protection: Prioritize personal safety
Other vehicle protection: Minimize harm to surroundings
Pedestrian protection: Protect most vulnerable traffic participants
Manufacturer risk avoidance: Manage legal liability and reputation risk

Even in the same system, beneficiaries change by situation. Normally prioritize driver convenience, in emergencies prioritize surrounding safety - such switches are necessary.

Question 2: What are the timing tradeoffs for switching?

Decision criteria switches always have timing tradeoffs. Both too early and too late carry risks, and which to emphasize is the core of trigger design.

Risks of Switching Too Early

Example: Safe stop initiated immediately when driver temporarily checks mirror

Risk Type	Specific Impact
Secondary damage	Rear-end collision risk from following vehicles
User experience	Driver confusion, system distrust
Operational issues	System turned OFF as result (counterproductive)

Over-intervention from false detection significantly damages user acceptance. This results in a vicious cycle where the system isn't used when truly needed.

Risks of Switching Too Late

Example: Emergency intervention mode entered only after 60 seconds when driver lost consciousness

Risk Type	Specific Impact
Life danger	Driver life danger, collision risk with other vehicles/pedestrians
Serious accidents	Accidents that should have been prevented occur
Legal liability	Regulatory violations, litigation risk
Corporate credibility	Media criticism, recalls, social credibility loss

Switching too late negates the purpose of having triggers. In worst cases, serious accidents cannot be prevented, questioning the system's very existence.

Worst-Case Scenario of Not Switching

From a risk management perspective, we must also consider the option "not having switch triggers at all."

Example: No trigger exists for switching to emergency intervention mode

System only continues issuing warnings forever
Cannot respond even if driver loses consciousness
Legal and social responsibility for "why intervention function wasn't implemented"

From this scenario, the necessity of triggers themselves is derived.

Judgment Guidelines for Tradeoffs

Judgment Aspect	Choose Earlier Switch	Choose Later Switch
Reversibility	Operation is reversible (warnings etc.)	Operation is irreversible (safe stop etc.)
Safety importance	Safety is top priority (medical, transportation)	User experience also valued (general apps)
False detection cost	False detection cost is low	False detection cost is high
Miss cost	Miss cost is high	Miss cost is low

General judgment criteria:

In most cases, we must weigh "too early risk" against "too late risk" and decide which to emphasize. Generally, in safety-related systems, "too late risk" is judged more serious, and somewhat earlier thresholds are adopted.

However, for irreversible operations (transition to Phase 3 etc.), caution is required. This judgment balance is the essential challenge of engineering.

Question 3: What is the basis for this threshold?

When determining thresholds, the following justifications must be clarified:

Ergonomic data: Citations from academic papers, ISO standards, etc.
Statistical analysis: Analysis results from experimental data
Regulatory requirements: Standards defined by law or guidelines
Competitive benchmarking: Analysis of other companies' product behavior
Risk analysis: Worst-case scenarios and acceptable risk settings

Thresholds with unclear justification become problematic later. Especially from regulatory compliance and litigation risk perspectives, documenting design decision rationale is important.

Question 4: How much should individual and situational differences be considered?

Ideally, triggers optimized for all users and all situations are desirable. However, in reality, there are the following tradeoffs:

Apply same threshold to everyone:

Advantages: Simple, easy to explain, fair
Disadvantages: Ignores individual differences, not optimal

Individual optimization:

Advantages: Optimal for each user
Disadvantages: Learning period needed, privacy concerns, difficult to explain

For example, young and elderly drivers differ in reaction time. However, changing thresholds by age may invite criticism of "age discrimination."

Most systems take an approach of starting with fixed thresholds and gradually introducing individual optimization.

Question 5: Can we return after switching?

Trigger reversibility is the most important factor determining the tradeoff between early intervention and careful judgment. Reversible operations have low false detection cost enabling early intervention, but irreversible operations require careful judgment as false detection is fatal.

Reversibility	Threshold Setting	Evidence Requirement Level	Risk
Reversible	Early/loose	Single evidence acceptable	False detection → poor user experience
Irreversible	Late/strict	Multiple evidence required	Miss → serious accident

Examples of reversible triggers:

Issue warning sound, change screen display
Phase 1 → Phase 2 (can return anytime)
Strategy: Intervene early and observe user response

Examples of irreversible triggers:

Safe stop, forced system shutdown
Phase 2 → Phase 3 (cannot return)
Strategy: Accumulate multiple evidence, execute after high confidence

Hysteresis⁴ design:

Irreversible triggers need mechanisms to prevent frequent switching:

Condition to enter Phase 3: Evidence Score > 0.8
Condition to exit Phase 3: Evidence Score < 0.4

→ Maintain state between 0.4-0.8 (prevent chattering)

By setting the "exit threshold" lower than the "entry threshold," once emergency mode is entered, it doesn't immediately return, allowing return to normal mode only after safety is confirmed.

Case Study: Driver Monitoring System Design Process

Let's examine an actual driver monitoring system trigger design process integrating the concepts so far.

Step 1: Hierarchize Objectives

First, hierarchize the multiple objectives the system has.

Level 1 objective: Have driver monitor driving
Level 2 objective: Intervene if monitoring impossible
Level 3 objective: Minimize harm to others

Step 2: Priority for Each Level

Priorities change by situation.

Normal: Level 1 > Level 2 > Level 3
Emergency: Level 3 > Level 2 > Level 1

Normally, prioritize letting the driver continue driving. However, in emergencies (driver definitely cannot monitor), minimizing harm to surroundings becomes top priority.

Step 3: Design Switch Triggers

Phase 1 → Phase 2 Trigger

Observable: Forward gaze rate < 50% continues for 5 seconds
Threshold: Why 5 seconds?
- Human attention recovery averages 3 seconds (research data)
- Add 2-second margin = 5 seconds
Consequence: Warning sound/display → Small user experience impact

At this stage, we still judge the driver can recover. Warnings are reversible intervention, so can be executed relatively early.

Phase 2 → Phase 3 Trigger

Observable:
- (Forward gaze rate < 30% continues for 20 seconds) AND
- (No steering operation OR abnormal operation)
Threshold: Why 20 seconds?
- Line distinguishing intentional ignoring from loss of consciousness (based on experimental data and medical knowledge)
- At 10 seconds, temporary intentional ignoring is likely
- At 30 seconds, intervention may be too late
- 20 seconds is the balance point
Consequence: Safe stop → Irreversible, following vehicle risk exists

At this stage, we judge the driver cannot recover and enter emergency intervention mode. Since safe stop is irreversible with secondary risks, more stringent conditions are set.

Step 4: Document Tradeoffs

Document design decision rationale.

Risks of too-early Phase 3 transition:
- Possibility of rear-end collision from false intervention
- User trust loss, resulting system OFF
- Excessive alert fatigue[^6]

Risks of too-late Phase 3 transition:
- Driver serious accident
- Regulatory violation (Ministry of Land guidelines)
- Recalls, litigation, corporate credibility loss

After comparing both, judged "too late risk" more serious, adopted somewhat earlier threshold (initially 30 sec → finally 20 sec)

By documenting such decision processes, when design changes are needed later, modifications can be made understanding the original intent.

Meta-Framework: Design Patterns for Judgment Switching

Judgment switching patterns are common across various systems. Here we introduce three representative patterns.

Pattern 1: Gradual Escalation

When state deteriorates continuously, gradually tighten decision criteria.

Level 1 (mild) → Level 2 (moderate) → Level 3 (severe)

Examples:

ADAS: Warning → Forced warning → Safe stop
Hospital triage: Observation → Priority treatment → Emergency treatment
Server monitoring: Log recording → Alert → Auto-restart

When to use:

When state deteriorates continuously
When early intervention enables recovery
When gradual response is effective

This pattern's advantage is giving users "advance notice." Rather than immediately taking final measures, gradually raising warning levels gives users opportunity to respond themselves.

Pattern 2: Binary Switch

When intermediate states are meaningless, instantly switch decision criteria.

Mode A (normal) ⇔ Mode B (abnormal)

Examples:

ADAS: Comfort Mode ⇔ Emergency Mode
Data center: Normal operation ⇔ Failover
Security system: Permit mode ⇔ Lockdown mode

When to use:

When intermediate states are meaningless
When instant switching is necessary
When hesitation in gray zones is dangerous

For example, when a data center primary server goes down, an intermediate state of "half-switching to backup" is meaningless. Immediate failover to secondary server is necessary upon detection.

Pattern 3: Conditional Branch Tree

When situations are complex and single indicators cannot judge, branch on multiple conditions. This pattern dynamically changes thresholds themselves according to situation.

Decision Structure by Decision Tree

This pattern can be expressed as nested if-else structure (decision tree):

                   [System Reliability]
                   /              \
              High /                \ Low
                 /                    \
    [Driver State Estimation Confidence]     [Multiple Sensor Abnormality?]
        /        \                 /         \
    High/          \Low        Yes/           \No
       /            \            /             \
  Standard(20s)  Long(40s)  Short(10s)    Careful(30s)

Implementation example in code:

if System_Reliability == High:
    if Driver_State_Estimation_Confidence == High:
        Emergency_Intervention_Threshold = Standard (20 sec)
        # Reason: Both system and driver estimation reliable, standard judgment
    else:
        Emergency_Intervention_Threshold = Long (40 sec)
        # Reason: Driver state unclear, judge carefully
elif System_Reliability == Low:
    if Multiple_Sensor_Abnormality_Detected:
        Emergency_Intervention_Threshold = Short (10 sec)
        # Reason: System abnormal, estimation inaccurate, early safe-side decision
    else:
        Emergency_Intervention_Threshold = Careful (30 sec)
        # Reason: Single sensor abnormal, wait for additional confirmation from other sensors

Situations Where This Pattern is Effective

Condition	Description
Multiple observations affect	Optimal threshold cannot be determined by single indicator alone
High context dependency	Road type, weather, traffic conditions affect judgment
Priority objectives differ by situation	Prioritize "early safety assurance" during system abnormality, "user experience" normally

Difference from Approach 2 (State-based)

Pattern 3 can be considered an implementation pattern of Approach 2 (state-based), but handles more complex conditional branches:

Feature	State-based (Simple)	Conditional Branch Tree (Complex)
Number of states	About 3-5	Many from situation combinations
Judgment complexity	Determine state by single condition	Determine by multiple condition combinations
Implementation method	if-elif-else (flat)	Nested if statements (tree structure)

Caution: Controlling Complexity

While this pattern is highly flexible, excessive complexity makes testing and maintenance difficult:

Bad example (overly complex):

if (System_Reliability == High) and (Driver_State == Alert) and (Weather == Good) and (Road_Type == Highway) and (Speed > 80):
    Threshold = 15 sec
elif (System_Reliability == High) and (Driver_State == Alert) and (Weather == Good) and (Road_Type == Highway) and (Speed <= 80):
    Threshold = 20 sec
# ... dozens of conditional branches continue

Good example (appropriate abstraction):

# First branch on main judgment axis
if System_Reliability == High:
    Base_Threshold = 20 sec
    # Fine-tune according to situation
    if Highway_Driving:
        Base_Threshold -= 5 sec  # Intervene earlier
else:
    Base_Threshold = 10 sec  # Err on safe side

Design principles:

Maximum 3 judgment axis levels (more is incomprehensible)
Branch in order of importance
Document reason for each branch (comments mandatory)

Conclusion: Trigger Design is Technology for Resolving Value Conflicts

The essence of system design is how to mediate contradictory objectives.

Driver autonomy vs. safety
Convenience vs. risk avoidance
Early intervention vs. false intervention avoidance

Designing decision criteria switch triggers means documenting "at what point, which value to prioritize."

Just as flight attendants change behavior between normal and emergency situations, systems must also change decision criteria according to situation. Engineers are required to precisely design the timing and conditions of those switches through engineering.

Characteristics of excellent trigger design are these three points:

Observability: Switch conditions are clear and measurable
Explainability: Can explain why that threshold, with justification
Adaptability: Functions appropriately according to situation changes

Most importantly, having a framework where the entire team can share that trigger design philosophy.

Everyone being able to answer questions like "why this threshold?" and "why switch at this timing?" in the same language. That becomes the foundation for realizing sophisticated system design.

Decision criteria switching is not merely a technical implementation issue. It is a fundamental design philosophy issue of how to mediate contradictory values.

Beyond System Design: Application to Organizational Strategy

The trigger design concepts introduced in this article are a general framework applicable not only to system design but also to organizational and team strategy formulation.

Essence of "Mode Switching" in Organizations

The questions organizations face are "what mode are we in now?" and "what conditions should trigger switching to the next mode?"

Like system design, organizations have multiple objectives:

Startup growth strategy: "Short-term revenue" vs. "Long-term market share"
Product development: "Adding new features" vs. "Resolving technical debt"
HR strategy: "Short-term results" vs. "Talent development"

However, trying to pursue these simultaneously blurs decision criteria. What's important is explicitly declaring "what mode now" and making decisions with decision criteria appropriate to that mode.

Application Example to Organizational Strategy: Startup Phase Switching

Mode	Priority Objective	Example Decision Criteria	Switch Trigger
Phase 1: Market Validation Mode	Prioritize hypothesis validation	Don't worry about Customer Acquisition Cost (CAC)	PMF⁵ achieved (retention rate > 40%)
Phase 2: Growth Mode	Prioritize scale	Growth rate > profitability	Monthly growth rate slows for 3 consecutive months
Phase 3: Monetization Mode	Prioritize profit	Profitability > growth rate	Market share saturates

Problems this framework solves:

"Why invest in growth even at a loss now?" → Because in growth mode
"When should we pivot to monetization?" → When trigger conditions are met
"Each member's decision criteria vary" → Everyone shares the same mode

Applying Five Design Questions to Organizational Strategy

The five questions introduced in this article are also effective for organizational decision criteria design:

Who is this switch for? → Prioritize shareholders, customers, or employees?
What are early/late risks? → Monetization before PMF (too early) vs. missing growth opportunity (too late)
What's the threshold basis? → 40% retention rate is PMF indicator (industry data)
Individual/situational differences? → Different triggers needed for B2B vs B2C
Can we return? → Returning from monetization mode to growth mode is difficult

Specific application methods to organizational strategy will be detailed in future articles.

What's important is that decision criteria switching is a universal technology needed in all decision-making situations. By expanding thinking methods cultivated in system design to broader domains, more precise strategic design becomes possible.

Related articles:

[@decision-making-under-uncertainty-70-percent-rule]
[@defining-correctness-nine-years-journey]

[Disclaimer]

The content of this article represents the author's personal views and does not represent the official views of any affiliated organization. Specific examples in the article are simplified models for explanation and may differ from actual product implementations.

FMEA (Failure Mode and Effects Analysis) - Method for systematically analyzing potential failure modes and their effects in systems ↩
NHTSA (2013). "Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devices" ↩
Euro NCAP (2024). "Driver Monitoring Systems Assessment Protocol" ↩
Hysteresis - Design technique that adds history effects to state change thresholds to prevent frequent switching ↩
PMF (Product Market Fit) - State where product fits market needs ↩

Value-Oriented Engineering: The Power to Define What We Consider Good

Takuya Niioka — Tue, 11 Nov 2025 15:00:10 +0000

The Engineer's Dilemma — Why "Good Work" Doesn't Always Get Recognized

Many engineers believe that "if you build something technically excellent, it will be recognized."

However, reality doesn't always reward effort or quality proportionally.

Behind this lies a structural problem: the absence of shared criteria for "what makes something good."

In environments with limited time and resources, prioritization decisions are constantly required.

These decisions, whether explicit or implicit, are always based on values.

Even technically correct solutions can be judged as "not a priority for us right now."

It's not "we should do it because it's good,"

but rather "we do it because it aligns with the values we prioritize most"

When you understand this difference, the way you frame technology begins to change.

Learning from Experience — "Technology Without Clear Value" Is Unsustainable

A development project I was involved in once collapsed in a short period.

The cause was simple: no one could clearly articulate "what we were aiming for" or "why we were doing it now."

Even technically meaningful initiatives become fragile when "which values guide our work" remains ambiguous.

Without a shared axis of value, decisions drift toward convenience and short-term logic.

Value is not about "what is good" but about expressing "what we consider good."

Whether you can articulate this clearly determines the direction of your team.

The Difference Between Features and Value — "What It Can Do" vs. "What It Means"

Engineers are accustomed to talking about "what can be done."

However, features are not substitutes for value.

Aspect	Feature	Value
Content	What it can do	Why we do it
Subject	Creator/Provider	Our own philosophy
Evaluation	Technical utility	Meaning, consistency, resonance

The value here is not about the total amount of societal "happiness."

Rather, resonance emerges as a result of embodying what we prioritize.

Resonance is a result, not a goal.

Value is a compass for direction, and the clarity of that compass generates trust.

Value 3 Framework — Three Steps to Define and Articulate Value

Step 1: Define Your Value Focus

Not "for whom" but "what do we consider good?"

Then discover "who resonates with this way of thinking."

Reversing this order leads to being pulled by others' expectations and losing your own values.

Step 2: Articulate as a Story

Value cannot be conveyed through abstract ideals alone.

Share as a narrative: "what we aim for," "what we avoid," "why this represents us."

By expressing it as a story connecting past, present, and future, value becomes embedded in organizational culture.

Step 3: Distill into Clear Language

Ultimately, value must be expressed in concise language.

Rather than vague ideals, having "a one-sentence guideline for decisions" is crucial.

This becomes the common language supporting daily decision-making.

Organizations with a clear statement don't waver.

Organizations with only vague words spend time in endless debate.

Values Shape Strategy

Even with the same goals, different underlying values produce entirely different strategies.

One organization prioritizes "precision," while another centers on "speed" or "flexibility."

It's not about which is superior—what you prioritize becomes your organization's identity.

With clear values, decisions remain consistent.

Conversely, organizations with ambiguous values see priorities shift with circumstances, leading to drift.

That's why expressing value criteria in a few words is not merely slogan-making—

it's an act that sharpens decision-making precision.

The Power to Articulate Value and Your Career

The ability to articulate value is not just communication skill.

It's the thinking ability to clarify "what criteria guide my decisions and what future I envision."

People with this ability provide direction regardless of their position.

Meanwhile, no matter how technically skilled, those who cannot articulate value find their influence limited—

their reasoning doesn't reach others.

I believe the power to articulate value will become increasingly important.

Not as a global trend, but because in this complex era, we're increasingly asked "what do we rely on?"

In times of uncertainty, what guides people and organizations is not technology but clarity of value criteria.

Common Ground and Differences with Design Thinking

Value thinking often overlaps with design thinking.

Both share the process of exploring better solutions through empathy, concretization, and validation.

However, they differ in focus.

Aspect	Design Thinking	Value Thinking
Starting Point	Empathy with others (their challenges)	Our own values (what we consider good)
Purpose	Creating solutions	Clarifying decision criteria
Result	Prototypes, ideas	Decision consistency, culture formation

While design thinking focuses on "finding better solutions,"

value thinking is the act of "defining what makes something good."

In other words, design thinking is a "creative process," while value thinking is "establishing philosophy."

Both complement each other, forming two wheels for organizational and individual maturation.

Conclusion — Technology Is "A Means to Live Our Values"

Technology is not the goal but the means to embody value.

When we have clear criteria for what we consider good and what we aim for,

technology becomes not just a deliverable but a mirror reflecting "who we are" to society.

Value is not about conforming to others.

Rather, it's about being able to quietly say, "this is the path we choose."

It's this stance that earns resonance and trust.

While honing technical skills, also hone the ability to articulate value.

This is the new intelligence required of engineers navigating an era of change.

Why Safety During Manual Driving Matters More Than During Autonomous Driving

Takuya Niioka — Wed, 05 Nov 2025 23:48:53 +0000

The ADAS Paradox ― "Essense" Beyond Automation

It has been over five years since autonomous driving became a hot topic. Autonomous taxi trials are underway in various countries, advanced driver assistance on highways continues to evolve, and news outlets increasingly report that "the era of autonomous driving is near."

However, I'd like to revisit a crucial question:

Do we really want "autonomous driving"?

If your car could drive itself, how much would you be willing to pay for it?
If that autonomous driving were overly cautious, prioritizing safety above all, or frequently required manual intervention, would you still want to use it?

The truth is, the value of "automation" varies greatly depending on what is automated, to what extent, and for what purpose.

And regardless of the level of automation, we cannot avoid the challenges of cost and responsibility allocation.

In this article, as an engineer with eight years of experience in ADAS development, I'll explore from a field perspective why improving the safety of "Level 0 (manual driving)" is crucial for society as a whole.

SAE Automation Level Framework

First, let's briefly review the automation levels based on the international standard SAE J3016.

Level	Name	Description
Level 0	No Driving Automation	Driver performs all tasks. May include warnings and momentary interventions.
Level 1	Driver Assistance	Assists with either steering OR acceleration/deceleration. Example: ACC.
Level 2	Partial Driving Automation	Controls both, but driver retains monitoring responsibility.
Level 3	Conditional Driving Automation	System performs all tasks under specific conditions. Human intervenes when requested.
Level 4	High Driving Automation	Full automation under specific conditions (no human intervention required).
Level 5	Full Driving Automation	System drives under all conditions. Steering wheel unnecessary.

Reference: SAE J3016 Automated Driving Levels

Critically, responsibility first shifts to the system at Level 3.

This boundary dramatically increases the difficulty across development, regulation, and social acceptance.

Reality: Technical and Institutional Barriers Facing Level 3

1. ODD (Operational Design Domain) Constraints

Level 3 systems must strictly define "under what conditions they function (ODD)".

Outside this domain, the system cannot guarantee safety.

For example, conditions like "highway only," "low-speed only," or "good weather" are set to clearly define the range where safety can be reliably ensured.

However, since real-world traffic conditions change frequently, designing and managing ODD boundaries becomes the most challenging issue.

2. Legal and Social Challenges

Autonomous driving legislation varies by country and region, with most nations having laws premised on "human driving."

Since Level 3 places responsibility on the manufacturer during system operation, careful institutional design is required for legal liability in accidents, take-over design, and risk mitigation when drivers don't intervene.

3. Cost and Scalability

Level 3 systems combining high-reliability sensors, redundant control ECUs, and high-precision maps incur additional costs of hundreds of thousands of yen per vehicle.

Consequently, deployment in mass-production vehicles remains limited, and cost recovery is challenging.

In contrast, Level 0-2 driver assistance technologies can be widely deployed, offering high cost-effectiveness from a societal safety improvement perspective.

Level 0 Safety Is Also Steadily Evolving

Recent "Level 0" technologies—safety assistance functions premised on driver responsibility—have been steadily advancing.

AEB (Automatic Emergency Braking)

Detection of pedestrians and cyclists, nighttime capability
Collision avoidance assistance at intersections during turns
Early warnings linked with DMS (Driver Monitoring Systems)

These advances have led to approximately 50% reduction in frontal collision accidents, according to US IIHS research.

Lane Keep Assist / Blind Spot Detection / Cross Traffic Alert

Prevention of lane departure, side collisions, and intersection accidents
Automatic intervention during drowsiness or distraction via DMS integration
Detection of approaching vehicles when exiting, and other safety measures rooted in daily scenarios

These features are already becoming standard equipment in many new vehicles.

Global Regulatory Trends

EU GSR (General Safety Regulation) Phase 2: Mandates AEB, LKA, DMS, etc. from 2024
China C-NCAP 2024: Introduces pedestrian/cyclist detection AEB and DMS evaluation
US NHTSA Proposal: Phased mandatory AEB implementation for all vehicles by 2029

These trends demonstrate that "safety technology in every vehicle" has become an international consensus.

Reflections from Nine Years in Development

Early in my career, I held a strong aspiration for achieving "fully autonomous driving."

However, working in mass production development revealed realities such as:

"Automation doesn't necessarily mean safety": It can create new risks like driver overreliance and reduced attention
Rather than technical sophistication, "safety technology accessible to everyone" has greater societal impact

Ultimately, I realized the obvious truth: saving as many lives as possible comes from the steady accumulation of modest, solid technology.

Manual Driving Safety Is What Changes Society

While "autonomous driving" is an attractive concept, from the perspective of reducing accidents across society, Level 0-2 safety technologies are currently delivering the greatest impact.

Comparison Axis	Level 0~2	Level 3
Adoption Rate	Tens of millions/year	Thousands/year
Additional Cost	Tens of thousands of yen	Hundreds of thousands of yen
Societal Impact	◎ Widely adopted with significant accident reduction	△ Expensive, operates only under limited conditions

Looking toward "the future of autonomous driving" is important.

But right now, at this very moment, what's saving lives around the world is Level 0 safety technology.

What I Want to Convey as an Engineer

Behind the glamorous headlines, there are people making steady improvements every day.

To prevent even one more accident, to save even one more life, they continue refining each sensor, each line of control logic.

The true value of the automotive industry lies not in flashy demos or headlines, but in "the power to make society as a whole safer".

Improving Level 0 safety is at the forefront of that mission.

References

Key Literature

SAE International, "J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles" (2021)
Euro NCAP, "2024 Test Protocol – Safety Assist"
IIHS, "Real-world benefits of crash avoidance technologies" (2024)
UNECE, "UN Regulation No. 157 - Automated Lane Keeping Systems (ALKS)" (2021)
European Commission, "General Safety Regulation (EU) 2019/2144"
NHTSA, "Automatic Emergency Braking Systems" (2024)
AAA Foundation for Traffic Safety, "Advanced Driver Assistance Technology Names" (2023)

Building an Automated Bilingual Blog System with Obsidian: Going Global in Two Languages

Takuya Niioka — Tue, 04 Nov 2025 14:57:10 +0000

Introduction: Why I Built This System

For 9 years since joining the company, I've worked as an engineer in the AD/ADAS field. While I accumulated expertise, I felt it was a career risk that my work wasn't visible outside the company and had zero recognition in the global market.

Expertise might as well not exist if it isn't visible.

Then I realized: Nothing will change unless I put myself out there.

However, I faced the following challenges:

Lack of time: With a full-time job, I couldn't dedicate 10 hours per week to blogging
Difficulty maintaining: Manual posting is cumbersome and leads to quick abandonment
Global reach: Japanese-only content has limitations; English content is also necessary

In this article, I'll introduce the bilingual automated blog posting system I built that costs only $10.18 per year to operate.

What This System Can Achieve

Key Features

Write article (Obsidian) → One button → Distribute worldwide

Specifically:

Write in Japanese → Auto-generate English version via AI translation
Automatic SEO optimization
Auto-publish to custom domain blog
Auto-generate LinkedIn posts
Prepare for distribution to Medium, Dev.to, etc.
Automatic Google Analytics tracking

Time required: Within 5 minutes (excluding article writing)
Annual cost: $10.18 (domain fee only)

Challenges Solved

Before (Pre-System Build)

3 hours to publish one article:

Writing in Obsidian: 2 hours
Manual HTML conversion: 20 minutes
Image optimization: 15 minutes
SEO configuration: 15 minutes
GitHub push: 10 minutes
Deploy verification: 10 minutes
LinkedIn post creation: 30 minutes
English translation: 1 hour (outsourced or self-translated)

Total: 4-5 hours
→ Impossible to publish 2 articles per week
→ Gave up

After (Post-System Build)

1 hour to publish one article:

Writing in Obsidian: 50 minutes
Run automation script: 5 minutes → AI translation → SEO optimization → Image optimization → Automatic GitHub push → Automatic Cloudflare deployment → Auto-generate LinkedIn post
Final check: 5 minutes

Total: 1 hour
→ Possible to publish 2 articles per week
→ Sustainable

System Architecture

Overall System Diagram

graph TD
    subgraph Writing["Writing Environment (Obsidian)"]
        A[Write Articles in Markdown] --> B[Core Vault]
        B --> C[Blog Vault]
    end

    subgraph Automation["Automation Layer (Python + AI)"]
        C --> D[AI Translation<br/>Claude API]
        D --> E[SEO Optimization<br/>Auto Description Generation]
        E --> F[Quality Check<br/>AI Analysis]
        F --> G[Hugo Static Site Generation]
    end

    subgraph Deploy["Deployment & Delivery"]
        G --> H[GitHub Repository]
        H --> I[Cloudflare Pages<br/>Auto Build]
        I --> J[Custom Domain Blog<br/>CDN Delivery]
    end

    subgraph SNS["Social Media Distribution"]
        G --> K[LinkedIn Post Generation]
        K --> L[LinkedIn API Posting]
        G --> M[Medium/Dev.to<br/>Distribution Prep]
    end

    subgraph Analytics["Analytics"]
        J --> N[Google Analytics GA4]
    end

    J --> O((Readers))
    L --> O
    M --> O

    style A fill:#DCE7FF,stroke:#333
    style D fill:#FFE6CC,stroke:#333
    style E fill:#FFE6CC,stroke:#333
    style F fill:#FFE6CC,stroke:#333
    style I fill:#ADD8E6,stroke:#333
    style J fill:#90EE90,stroke:#333
    style O fill:#FFB6C1,stroke:#333

Technology Stack

Category	Technology	Role	Cost
Writing	Obsidian	Markdown article creation, knowledge production core	Free
SSG	Hugo	Static site generation (Markdown→HTML)	Free
AI	Claude API	Translation, quality check, SEO optimization	$5-10/month
Hosting	Cloudflare Pages	Auto deployment & CDN delivery	Free
Version Control	GitHub	Source control & CI/CD	Free
Domain	NameCheap	Custom domain	$10.18/year ✅
DNS	Cloudflare	DNS management & email forwarding	Free
SNS API	LinkedIn API	Auto posting	Free
Analytics	Google Analytics	Access tracking	Free

Total Annual Cost: $10.18 + API usage $60-120 = $70.18-130.18 (approximately ¥10,000)

Core Implementation: 5 Stages

Stage 1: Draft

Purpose: Review and modify articles locally

draft.bat

# Or include English translation simultaneously
draft_translate.bat

Process:

Retrieve articles from Obsidian (Core Vault)
Automatically convert to Hugo format
Save with draft: true (private)
Auto-launch Hugo server
Open http://localhost:1313 in browser

At this stage:

No GitHub push
Multiple revisions and previews possible
Completely local process

AI Translation Feature:

# translate_article.py (excerpt)
def translate_with_claude(japanese_text):
    """Translate Japanese to English using Claude API"""
    prompt = f"""
    Please translate the following technical article to English:
    - Use appropriate technical terms
    - Natural, readable English
    - Preserve Markdown formatting

    {japanese_text}
    """
    # Call Claude API
    response = call_claude_api(prompt)
    return response

Stage 2: Quality Check

Purpose: Perform AI-based article quality analysis

check.bat

Check Items:

Detection of omitted subjects (Japanese-specific issue)
Detection of logical gaps
Abstract-to-concrete correspondence
Detection of ambiguous expressions
Accuracy of technical terms
SEO improvement suggestions

Output Example:

# Quality Report

## Subject Omission (3 places)
- Line 45: "Built the system" → Who did?
  Suggestion: "I built the system"

## Logic Gaps (2 locations)
- Line 78-82: Gap between Step 2 and Step 3
  Suggestion: Add intermediate steps

## Ambiguous Expressions (5 locations)
- Line 92: "quite fast" → what are the specific numbers?
  Suggestion: "3 times faster (7h → 2h)"

## Overall Rating: 85/100
Can improve to: 90/100

Stage 3: Pre-Publish Optimization

Purpose: Perform SEO optimization and Description auto-generation

# Automatically executed when publish.bat runs

Execution Details:

1. Description Auto-generation (Claude API)

def generate_description(article_text):
    """Generate SEO-optimized summary automatically"""
    prompt = f"""
    Please generate an SEO-optimized summary from the following article.

    Requirements:
    - 120-160 characters
    - Naturally include keywords
    - Capture reader interest
    - Convey article core message

    {article_text}
    """
    description = call_claude_api(prompt)
    return description

2. Automated SEO Check

seo_checks = {
    'title_length': Within 60 characters?,
    'h1_exists': Has H1 tag?,
    'description': Between 120-160 characters?,
    'images': Has alt attributes?,
    'word_count': Minimum 1,500 words?,
    'tags': Has 3-5 tags?,
    'internal_links': Has internal links?
}

3. H1 Handling (Important)

Issue: Hugo theme outputs title as H1
     → Duplicates with H1 in Markdown
     → Bad for SEO

Solution: 
1. Comment out H1 in Markdown
2. Hide with CSS
3. Keep in HTML (for SEO)

Stage 4: Publish

Purpose: Actually publish the article

publish.bat

Execution Flow:

def publish_workflow():
    # 1. Generate description
    description = generate_description(article)

    # 2. SEO automatic check
    seo_result = check_seo(article)
    if not seo_result.passed:
        print("SEO issues found:", seo_result.issues)
        if not confirm("Publish anyway?"):
            return

    # 3. Convert to Hugo format (draft: false)
    convert_to_hugo(article, draft=False)

    # 4. Save Japanese and English versions
    save_bilingual_articles(article_ja, article_en)

    # 5. Automatic Git push
    git_push_with_message(f"Publish: {article.title}")

    # 6. Generate LinkedIn posts
    generate_linkedin_posts(article)

    print("✅ Publishing complete!")
    print(f"Japanese: https://takuyaniioka.com/ja/posts/{slug}/")
    print(f"English: https://takuyaniioka.com/posts/{slug}/")

Post-publish Auto-deployment:

GitHub Push
    ↓ (Webhook)
Cloudflare Pages Detection
    ↓
Hugo Auto-build (about 30 seconds)
    ↓
CDN Distribution
    ↓
Blog Published

Stage 5: Social Media (LinkedIn)

Purpose: Automatically generate LinkedIn posts from articles

linkedin_post.bat

This system can automatically generate LinkedIn posts from articles. We plan to modify the design in the future to allow manual editing and posting as needed.

Stage 6: Analytics

Google Analytics GA4 Integration:

# BlogVault/config.toml
[params]
  googleAnalytics = "G-XXXXXXXXXX"

Tracking Data:

Real-time access
Traffic sources (LinkedIn, Medium, Google etc.)
Popular article rankings
Device and region statistics
Time on site and bounce rate

Design Philosophy: Why This Architecture?

1. Obsidian-Centric Approach

Reasons:

Second Brain: Core of my intellectual productivity
Unified Management: Articles and notes, all managed in Obsidian
Prevent Thought Fragmentation: Information is not scattered

Structure:

Obsidian/
├── Core Vault/          # Private & intellectual production
│   ├── Daily Notes/
│   ├── Projects/
│   └── Articles/        # Article drafts
│
└── Blog Vault/          # Public & blog-specific
    ├── content/
    ├── static/
    └── config.toml

Reasons for Separation:

Core Vault is private (personal notes & confidential information)
Blog Vault is public (pushed to GitHub)
Maintains clear boundaries

2. AI Utilization Philosophy

AI is "Augmentation" not "Replacement"

[Wrong Usage]
Let AI write everything
→ Zero originality
→ Zero value

[Correct Usage]
Human: Write core insights & experiences
AI: Automate translation, SEO, quality checks

→ Humans focus on intellectual production
→ AI handles repetitive tasks

Concrete Examples:

✅ AI Translation: Think deeply in Japanese, AI translates to English
✅ SEO Optimization: AI auto-generates descriptions
✅ Quality Check: AI provides objective review
❌ Article Writing: Written by humans (AI assists only)

3. Staged Workflow

Why Split into 5 Stages:

Reason 1: Safety

Gradual verification instead of immediate publication
Detect and fix issues at each stage

Reason 2: Flexibility

Can pause at any point
Can resume from any stage

Reason 3: Debuggability

Clear identification of where problems occur
Logs provide immediate clarity

Implementation Details: Core Features

Feature 1: Article Format Conversion

Challenge:

Obsidian format (EvolutionVault)
Hugo format (BlogVault)
Different formats

Solution:

def convert_evolution_to_hugo_format(source_file, draft_mode=True):
    """EvolutionVault format → Hugo format"""

    # 1. Parse YAML frontmatter
    with open(source_file, 'r', encoding='utf-8') as f:
        content = f.read()

    # Separate frontmatter and body
    if content.startswith('---'):
        parts = content.split('---', 2)
        frontmatter = parts[1]
        body = parts[2] if len(parts) > 2 else ""

    # 2. Convert for Hugo
    hugo_frontmatter = convert_frontmatter(frontmatter)
    hugo_frontmatter['draft'] = draft_mode

    # 3. Save
    output_path = get_hugo_path(source_file)
    save_hugo_file(output_path, hugo_frontmatter, body)

Feature 2: Automated SEO Optimization

Challenge:

Manual description writing is time-consuming
Easy to miss SEO checks

Solution:

def optimize_seo(article):
    """Automated SEO optimization"""

    # 1. Auto-generate description (Claude API)
    description = generate_description_with_ai(article.content)
    article.description = description

    # 2. SEO checklist
    checks = [
        check_title_length(article.title),
        check_description_length(article.description),
        check_h1_tag(article.content),
        check_image_alt_tags(article.content),
        check_word_count(article.content),
        check_tags(article.tags),
        check_internal_links(article.content)
    ]

    # 3. Warning if issues found
    issues = [c for c in checks if not c.passed]
    if issues:
        print("⚠️ SEO issues:")
        for issue in issues:
            print(f"  - {issue.message}")

    return article

Feature 3: Bilingual Support

Challenge:

Managing Japanese and English separately is complex
Separate URLs needed

Solution:

Utilizing Hugo's multilingual features:

Japanese:
https://takuyaniioka.com/ja/posts/article-slug/

English:
https://takuyaniioka.com/posts/article-slug/

Automatic switching:
- Detects browser language settings
- Japanese browser → /ja/
- English browser → /

Implementation:

# config.toml
[languages]
  [languages.en]
    languageName = "English"
    weight = 1
    contentDir = "content"

  [languages.ja]
    languageName = "日本語"
    weight = 2
    contentDir = "content"

[params]
  defaultContentLanguage = "en"
  defaultContentLanguageInSubdir = false

Results: What This System Delivered

Quantitative Results

Metric	Before	After	Improvement
Writing Efficiency	5 hours/article	1 hour/article	5x faster
Weekly Posts	0-1 posts	2 posts	2x+
Annual Articles	10-20 (including dropouts)	60+ (achievable target)	3-6x
Cost	Outsourced translation $50-100/article	$10.18/year + API $10/month	95% reduction

How to Build This System

Construction Steps (Overview)

Step 1: Environment Setup (1 hour)

Install Obsidian
Install Hugo
Install Git
Install Python
Create GitHub account
Create Cloudflare account

Step 2: Domain Acquisition (15 minutes)

Get custom domain from NameCheap ($10.18/year)
Configure DNS in Cloudflare
Set up email forwarding (optional)

Step 3: Hugo Setup (30 minutes)

Create Hugo site
Select theme (Hugo Clarity recommended)
Configure config.toml
Set up bilingual settings

Step 4: Cloudflare Pages Setup (15 minutes)

Create GitHub repository
Link to Cloudflare Pages
Configure build settings (Hugo)
Set up custom domain

Step 5: Automation Script Setup (1 hour)

Install Python dependencies
Deploy automation scripts
Create .bat files
Configure Claude API
Run tests

Step 6: First Post Publication (30 minutes)

Write article in Obsidian
Run draft.bat
Check preview
Run publish.bat
Complete publication

Total time required: About 4 hours

Summary: The Essence of This System

Time reduction: 5 hours → 1 hour
Cost reduction: 95% reduction
Multilingual support: Japanese-English automatic
Social media deployment: Automated

Resources

Reference Links

GitHub Repository

While it's not currently public, I'm open to considering making it public upon request. The content is expected to include the following structure:

Automation scripts
Setup guide
Troubleshooting
FAQ

Forem: Takuya Niioka

Prioritizing Multiple Options: Switching Criteria by Context

When Advancing Multiple Initiatives as a Team, Where Do You Start?

Why Is Prioritization Difficult?

The Essential Difficulty of Prioritization

Common Failure Patterns

Conditions for Functional Prioritization

Five Basic Prioritization Patterns

Pattern 1: Urgency × Importance Matrix

Pattern 2: Business Value Priority

Pattern 3: Customer Value Priority

Pattern 4: Career Priority

Pattern 5: Strategic Balance (Portfolio Thinking)

Three Supplementary Patterns

Pattern 6: Dependency Priority

Pattern 7: Risk Priority

Pattern 8: Quick Win Priority

How to Combine Basic and Supplementary Patterns

Trade-off Comparison Table for 8 Patterns

How to Switch Patterns

Four Triggers for Pattern Switching

Trigger 1: Crisis Occurrence

Trigger 2: Time Horizon Change

Trigger 3: Stakeholder Change

Trigger 4: Resource Change

Five Questions for Pattern Selection

Question 1: Who is this prioritization for?

Question 2: What's the current situation?

Question 3: What's the rationale for this pattern?

Question 4: What are the trade-offs?

Question 5: Can you change the pattern when the situation changes?

Practical Examples

Scenario 1: Normal Product Development

Scenario 2: Regulatory Compliance Deadline Approaching

Scenario 3: Career Turning Point

Summary - The Essence of Adaptive Prioritization

1. Clarify who the decision is for

2. Recognize the current situation

3. Visualize trade-offs

Conclusion: Switching Judgment Criteria Is the Essence

Related Articles

Between Safety and Value: Defining 'Correctness' Through Nine Years of Journey

Prologue: The "Why" I Almost Lost in Technology

Period of Challenge and Exploration (Years 1-4)

Period of Reexamining Value (Years 5-7)

Stage of Integration (Years 8-9)

Three Lessons Learned

1. Not "Searching for Correctness" but "Defining Correctness"

2. Safety is Not a "Function" but a "Relationship"

3. Knowledge is a Tool, Thinking is the Axis

Toward the Next Ten Years

Finally: A Message to Readers

Related Articles

When to Switch Decision Criteria: Trigger Design for System Engineers

Three Elements of Trigger Design

Element 1: Observable (Detectable State Changes)

Element 2: Threshold

Element 3: Consequence (Purpose and Result of Switching)

Three Approaches to Trigger Design

Comparison of Three Approaches

Approach 1: Time-based

Approach 2: State-based

Approach 3: Evidence Accumulation-based

Trigger Design in Practice: Five Design Questions

Question 1: Who is this decision criteria switch for?

Question 2: What are the timing tradeoffs for switching?

Risks of Switching Too Early

Risks of Switching Too Late

Worst-Case Scenario of Not Switching

Judgment Guidelines for Tradeoffs

Question 3: What is the basis for this threshold?

Question 4: How much should individual and situational differences be considered?

Question 5: Can we return after switching?

Case Study: Driver Monitoring System Design Process

Step 1: Hierarchize Objectives

Step 2: Priority for Each Level

Step 3: Design Switch Triggers

Phase 1 → Phase 2 Trigger

Phase 2 → Phase 3 Trigger

Step 4: Document Tradeoffs