Process Optimisation

Map Reality, Model Improvement, Close the Gap.

Make it easy to do the right thing and annoying to do the wrong thing.

Purpose

Build trust in systems that operate more effectively to transform and distribute value through embedded situational wisdom.

• Build Trust
• Better Quality
• Greater Capacity
• Faster Cycles

Principles

This section covers the methods for capturing, measuring, and improving processes. For terminology definitions, see Naming Standards.

Four levels, from strategic to tactical:

STANDARD (Glue)  →  PROCESS (Tacit)  →  PROCEDURE (Explicit)  →  WORKFLOW (Trace)

Level	Term	Concept	Definition
1	Standards	Atoms and Bits of interoperability and composability	The Ontology (Why things relate)
2	Process	Process Knowledge	The Goal (What needs to happen - Tacit)
3	Procedure	Procedural Knowledge	The Rules (Formalized logic - Explicit)
4	Workflow	Decision Trace	The Execution (How it actually happened)

Full definitions: Naming Standards → Operations Hierarchy

---

Processes

Work Charts vs. Workflows, different tools for different questions:

Tool	Question	Maps
Work Chart	Who does what?	Capability → Demand
Workflow	How is it done?	Steps → Outcome

They work together:

1. [Work Charts](/docs/tags/Work Charts) identify WHAT activities exist and WHO does them
2. Workflow documents HOW each activity is performed

---

Process Maturity

Track where each workflow sits:

Status	Symbol	Definition	Next Step
Gap	GAP	No documentation exists	Document the workflow
Draft	D	Documented but not validated	Test with real work
Failing	F	Documented but not working	Diagnose and fix
Approved	A	Validated and approved	Monitor performance
Needs Work	NW	Approved but degrading	Schedule review
Active Review	AR	Currently being improved	Complete review cycle

Audit Questions

For each process, ask:

1. Is this process common to all businesses?
2. What is the current state? (Use symbols above)
3. What triggers the process?
4. Who owns it?
5. How do we know it's working?

---

Triggers

What initiates a workflow?

Trigger Type	Description	Example
Schedule	Time-based recurrence	Weekly content calendar
Event	Something happened	New lead captured
Threshold	Metric crossed a line	Bounce rate > 70%
Request	Someone asked	Customer support ticket

Document triggers in every workflow — if you don't know when to run it, it won't get run.

---

Workflow Structure

Every workflow document should include:

1. Overview

Attribute	Description
Purpose	What outcome does this produce?
Trigger	What initiates this workflow?
Frequency	How often does it run?
Duration	How long does it take?
Owner	Who is responsible?
Output	What gets produced?

2. Prerequisites

• Tools required
• Access requirements
• Knowledge requirements

3. Inputs

What you need before starting.

4. Process

Phased steps with checklists at each phase.

4b. Dependency Verification

Every workflow step that references another step must validate the reference exists before execution begins. Phantom dependencies — steps that reference task-06 when task-06 was never created — produce permanently stuck chains that look active but cannot advance.

Check	When	Action if failed
All blockedBy references resolve to real steps	At plan creation	Warn and list unresolved references
Referenced steps exist in the same plan	Before advancing any step	Block advancement, surface the gap
Circular dependencies absent	At plan creation	Reject the plan

5. Outputs

What gets produced, in what format, delivered where.

6. Success Criteria

How to know it's done right — quality metrics and performance metrics.

7. Failure Modes

Common problems and their solutions.

Reference implementation: Article Copywriting Workflow

---

Improvement Methods

Process Mapping

Visualize the current state before improving.

• See the big picture and the details simultaneously
• Identify bottlenecks, redundancies, gaps
• Create shared understanding across team

More: Process Mapping

Process Modelling

Simulate changes before implementing.

• Test hypotheses about improvements
• Quantify impact of changes
• Reduce risk of failed changes

More: Process Modelling

Quality Assurance

Ensure consistent outcomes.

• Define acceptance criteria
• Build verification into workflows
• Create feedback loops for improvement

More: Quality Assurance

Checklists

The simplest, most powerful improvement tool.

• Reduce errors and oversights
• Improve consistency
• Enable delegation without loss of quality

Types:

• Do-Confirm: Complete tasks from memory, then verify against checklist
• Read-Do: Read each item, then do it (for unfamiliar or high-risk work)

More: Checklists

Reading the Game

The in-play decision cycle. Design pictures in advance, read them at speed, act within scaffolding, debrief the decision flow, compress into mantra. Where the Improvement Loop runs after the game, this loop runs during.

More: Reading the Game

---

The Improvement Loop

DOCUMENT → MEASURE → ANALYZE → IMPROVE → STANDARDIZE
    ↑                                         |
    └─────────────────────────────────────────┘

1. Document — Capture current state as a workflow
2. Measure — Track performance against success criteria
3. Analyze — Identify gaps between actual and desired
4. Improve — Change the workflow to close gaps
5. Standardize — Update documentation, train team

Repeat continuously.

Cycle Speed

The improvement loop has no prescribed cadence — but the wrong cadence kills the loop.

When a defect is found during execution (not during a retrospective), log it immediately where it can be acted on. Waiting for the retrospective to surface a generator bug means every plan between now and then inherits the same defect.

Defect found during...	Log it in...	Fix cycle
Plan execution	The source template's issues/insights file	Same session if possible, next plan at latest
Retrospective	The improvement loop backlog	Next standardization cycle
Production incident	Incident record + template fix	Immediate

The rule: the feedback cycle must be shorter than the defect's blast radius. If the bug affects every plan, waiting for a quarterly retro means N plans ship broken.

---

Process ↔ Context

Process and context shape each other. Neither is primary.

PROCESS (Yang)                    CONTEXT (Yin)
─────────────                     ────────────
How we proceed                    Why this time
Creates movement                  Creates meaning
Repeatable                        Situational
───────────────────────────────────────────────
        ↓                              ↓
   Execution creates              Traces reveal
   decision traces                patterns
        ↓                              ↓
   Traces become                  Patterns improve
   queryable context              process
        └──────────────────────────────┘

Process without context = Bureaucracy. Following steps without knowing why. Context without process = Chaos. Knowing why but no repeatable path.

Example: A support team has a process for escalations. First month, they escalate 40% of tickets—no context on what worked. By month six, decision traces show which escalations resolved fastest. The process tightens. Escalation rate drops to 15%. Context improved process. Process generated better context.

Together they spiral upward. Each cycle adds to the context graph.

---

Pit of Success

Design systems where the right thing is the path of least resistance. Five patterns from production failures.

Pattern	Without It	With It
Name it	Concepts exist across 6 pages but unnamed — can't be taught, referenced, or tested	One named concept in one hub page, cross-linked everywhere
Hub pages route	Index page is a 3-row table — nobody knows where to start	Curated links with commentary. 10-second test: reader knows where to go
Validate links	46 broken references compound for months, nobody notices	Validation runs every push. Broken link = broken chain
Templates reference sources	Template is disconnected from the docs it implements — drift is guaranteed	source_files in every template phase. Template reads from docs. Docs stand alone
Specify the return signal	Feedback loop closer is 2 lines + a link. The most important element is least documented	Trigger, format, receiver, action — all specified inline

Each pattern prevents a class of error, not an instance. The question after every fix: did we prevent the class, or just fix the instance? See Enforcement Hierarchy.

Anti-Patterns

Anti-Pattern	Problem	Solution
Undocumented	Knowledge locked in heads	Document as workflows
Over-documented	Nobody reads 50-page SOPs	Keep workflows scannable
Never updated	Documentation drifts from reality	Review triggers, scheduled audits
No metrics	Can't tell if it's working	Define success criteria upfront
No owner	Nobody responsible for improvement	Assign ownership
Too rigid	Can't adapt to context	Build in decision points
Too loose	Inconsistent outcomes	Add checklists at critical points

---

Dig Deeper

• Checklists — The simplest tool that reduces errors and enables delegation without quality loss
• Process Mapping — Visualize the current state before improving — see bottlenecks, redundancies, gaps
• Process Modelling — Simulate changes before implementing to quantify impact and reduce risk
• Quality Assurance — Deming's 14 points applied to automated and manual output
• Reading the Game — The in-play decision cycle: design pictures in advance, read them at speed, act within scaffolding, debrief the decision flow, compress into mantra

---

Context

• First Principles — Question requirements before optimising them
• Standards — Where improved processes compound into predictability
• Naming Standards — Canonical terminology
• Work Charts — Who does what (capability → demand)
• Marketing Activities — Reference implementation
• BOaaS — Business Operations as a Service
• The Mycelium — Process is the invisible layer that governs visible outcomes
• Scoreboard — The gauge that proves the improvement loop closed
• Play the Game — Where the loops actually run — process improvement is the goal of playing

Questions

Which of your undocumented processes would cause the most damage if the person who knows it left tomorrow?

• Where in the improvement loop are you stuck — documenting, measuring, analyzing, improving, or standardizing?
• What process do you follow religiously that has never been measured against its intended outcome?
• When context and process conflict, which wins in your organization — and what does that cost?
• How long does it take for a defect found during execution to reach the template that caused it — and how many plans ship broken in the gap?