Unit X: Evidence-Based Progression
Designing steps, defining proof, and governing support without chaos
Unit Intent
This unit teaches how to:
- break real processes into valid steps
- define where steps start and end
- identify what data and artifacts prove completion
- redesign steps based on evidence, not opinion
- handle support work and tickets without creating chaos
- decide when not to break things into steps
- design macro flows and micro flows correctly
This unit is required before:
- KPI design
- automation
- scale
- SmartOps
Core Principle
A step does not exist unless it produces verifiable evidence.
Evidence means:
- structured data
- tangible artifacts
- a decision that can now be made
Effort, activity, or ticket closure alone do not count.
Section 1 — Identifying the Real Process
What a Process Is (FlowOps definition)
A process exists to:
- move value forward
- change state
- enable a decision
Processes are not:
- job titles
- departments
- tools
How to Identify a Real Process
Ask:
- What triggers this work?
- What decision are we trying to make?
- What state is different when it’s done?
If you cannot answer all three, you do not have a process.
Section 2 — Defining Step Start and End Conditions
Every step must have:
Start Condition
- observable
- loggable
- specific
Examples:
- intake record created
- ticket classified
- drawings received
- status changed
End Condition
- proven by data or artifact
- enables the next step or decision
Examples:
- validated intake record
- approved scope document
- completed takeoff file
- routed task inside a primary flow
If the end condition is vague, the step is invalid.
Section 3 — Defining Evidence for Step Completion
For each step, define three things only:
1. Required Data Points
Structured fields that must exist.
Examples:
- due date
- category
- priority
- scope type
- owner
Each data point must have:
- definition
- capture rule
- validation rule
2. Required Artifacts
Something tangible that now exists.
Examples:
- document
- record
- checklist
- approval log
- task created in a primary flow
3. Ownership
One owner accountable for completion.
Multiple contributors are allowed.
Multiple owners are not.
Section 4 — The Finished Product Test
For every step, ask:
“When this step is complete, what exists that did not exist before?”
If the answer is:
- “clarity”
- “progress”
- “we worked on it”
The step is not real.
Section 5 — Fixing Bad Steps (Combine, Split, Remove)
Combine Steps When:
- no decision exists between them
- they produce the same artifact
- data is duplicated
Split Steps When:
- ownership changes
- different artifacts are produced
- one step blocks another
Remove Steps When:
- no unique evidence is produced
- they exist only to “check in”
- they add friction without control
Section 6 — Support Work Without Chaos (Critical)
The Problem
Support work often becomes:
- arbitrary
- disconnected
- measured by volume instead of outcome
- a bypass around primary flows
The Rule
All support must terminate into an existing primary flow.
Support is a router, not a primary operating system.
Support Outcome Classification (Required)
Every support item must end as one of the following:
- Resolved (single-touch)
- Routed to a primary flow
- Escalated for decision
- Deflected (FAQ / self-serve)
- Closed as invalid
If a support system cannot enforce this classification, it will drift into chaos.
Section 7 — When NOT to Break Things Into Steps
The Step Cost Rule
If the cost of tracking steps is higher than the value of insight gained, do not break it down.
For simple work:
- use one-step intake
- capture minimum data
- resolve or route immediately
FlowOps is not about complexity — it is about control with efficiency.
Section 8 — Macro Flows vs Micro Flows
Macro Flows (Primary)
- revenue-driving
- completion-driving
- long-lived
- deeply measured
Examples:
- sales
- delivery
- estimating
- onboarding
- finance
Micro Flows (Support / Repeatable)
- small
- repeatable
- max 3–5 steps
- always terminate into a macro flow or resolution
Micro flows do not create new systems.
They exist to prevent chaos.
Template A — Macro Flow Design Template
Macro Flow Name:
Primary Outcome:
Trigger:
Step Inventory
|
Step Name |
Start Condition |
End Condition |
Evidence Produced |
Owner |
Required Data (Global)
- core identifiers
- priority / status
- owner
- timestamps
KPIs Enabled
- throughput
- completion rate
- cycle time
- rework
Flow Termination
- completed outcome
- handoff to next macro flow
Template B — Micro Flow Template (Support / Repeatable)
Micro Flow Name:
Used For:
Trigger:
Classification
☐ Tier 1 (single-touch)
☐ Tier 2 (repeatable)
☐ Tier 3 (route to macro flow)
Required Fields (Minimum)
- category
- outcome type
- owner
Steps (Max 5)
|
Step |
Evidence Required |
Completion Definition
☐ resolved
☐ routed (macro flow + step)
☐ escalated
☐ deflected
Destination
Primary Flow:
Receiving Step:
Section 9 — Validation Questions (Must Answer “Yes”)
- Can someone verify completion without asking a person?
- Does this step enable a decision?
- Does support resolve into a primary flow?
- Are micro flows limited and reusable?
- Are simple tasks kept simple?
If any answer is “no,” redesign the step.
Unit Outputs (What Must Exist)
By completing this unit, the reader produces:
- A defined process inventory
- Clear step start/end conditions
- A Step Evidence Matrix
- Identified macro and micro flows
- Support routing rules
- Reduced arbitrary work
- Evidence-based readiness for advancement
Positioning Note (End of Unit)
FlowOps maturity is not about mapping everything.
It is about knowing what matters, proving it exists, and routing everything else correctly.