Principle 17:
Mapping Is Descriptive Before It Is Evaluative

Plain-English Summary

OneRoute first records what actually happens, not what should happen. Evaluation, judgment, and optimization only occur after the route is fully and accurately described.

​

What this Principle Means

Many mapping efforts fail because they mix description with opinion. OneRoute separates these phases. The route must reflect reality—even when that reality is uncomfortable—before it can be improved.

​

Why Description Comes First

Judging a system before understanding it leads to surface fixes and misplaced blame. Accurate description reveals the true structure that produces outcomes.

​

What Descriptive Mapping Looks Like

• Steps are labeled using operators only

• Branches, loops, waits, and cues are included

• No commentary on quality, intent, or performance

​

​​Concrete Examples

Human process: Recording repeated approval loops without labeling them as inefficiency.

Observed reality: Capturing actual delays rather than expected timelines.

Natural phenomena: Documenting cycles without assigning purpose or optimization.

​

Mini Case: Fixing the Wrong Problem

A team optimizes a step they believe is slow. Mapping reveals the delay occurs elsewhere. Descriptive accuracy prevents wasted effort.

 

How to Apply This Principle

1. Map the route exactly as observed.

2. Use operators without commentary.

3. Validate the map against reality.

4. Only then introduce evaluation or redesign.

​

Common Misunderstandings

• Treating mapping as a critique session

• Omitting steps that ‘shouldn’t happen’

• Mixing goals into structural description

​

Quick Diagnostic Questions

• Does this map match reality exactly?

• Are opinions separated from structure?

• Could two observers agree on this map?

​

If You Only Remember One Thing

You cannot improve what you refuse to describe.

​

Canonical Statement

OneRoute mapping is descriptive before it is evaluative.