Principle 9:
Time Must Be Explicit

Plain-English Summary

Whenever progression depends on time, that time must be explicitly represented. In OneRoute, time is never implied—it is modeled using Wait, Standby, or Process.

 

What this Principle Means

Time is one of the most common sources of hidden complexity. If a step cannot complete immediately, OneRoute requires that the time dependency be made visible so it can be understood, measured, and governed.

​​​

Why Explicit Time Matters

Implicit time hides delays, creates false expectations, and misattributes responsibility. By forcing time to be explicit, OneRoute separates effort from latency and execution from physics.

 

Ways Time Appears in OneRoute

• Wait: a defined pause until a time condition is met

• Standby: readiness maintained while awaiting a trigger

• Process: passive transformation occurring over time

​

Concrete Examples

Human process: Waiting 24 hours for approval, holding a ticket in queue.

Observed reality: Work pauses overnight while a system runs.

Natural phenomena: Cooling, growth, decay, fermentation.

​

Mini Case: The Invisible Delay

A process claims same-day turnaround. Mapping reveals a 12-hour Wait that was never documented. The issue was not speed—it was hidden time.

 

How to Apply This Principle

1. Ask whether the step completes immediately.

2. If not, identify whether the delay is time-based, readiness-based, or transformation-based.

3. Use Wait, Standby, or Process accordingly.

4. Never allow time to exist without an operator.

​

Common Misunderstandings

• Treating waiting as inactivity

• Collapsing time into action steps

• Assuming time is obvious and doesn’t need modeling

​

Quick Diagnostic Questions

• Does this step complete instantly?

• What happens if no one intervenes during this time?

• Is the delay governed by time, readiness, or transformation?

​

If You Only Remember One Thing

If time matters, it must be explicit.

​

Canonical Statement

Time in OneRoute is always explicit and never implied.