Process Optimisation

Map Reality, Model Improvement, Close the Gap.

Make it easy to do the right thing and annoying to do the wrong thing. Build trust in systems that operate more effectively to transform and distribute value through embedded situational wisdom.

Levels

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

---

Methods

Method	Question	What it does
Process Mapping	What is current reality?	Visualize flows to expose bottlenecks, redundancies, and gaps
Process Modelling	What would improve it?	Simulate changes before implementing — quantify impact, reduce risk
Checklists	How do we hold the standard?	Reduce errors, enable delegation without quality loss
Quality Assurance	Is the output good enough?	Define acceptance criteria, build verification into workflows
BPR	Is it worth fixing — or scrapping?	Radical redesign when incremental improvement won't close the gap

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

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

Work Charts identify WHAT activities exist and WHO does them. Workflows document HOW each activity is performed.

---

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

For each process, ask: What triggers it? Who owns it? How do we know it's working?

---

Workflow Template

Every workflow document needs:

Section	Content
Purpose	What outcome does this produce?
Trigger	What initiates this workflow? Schedule · Event · Threshold · Request
Frequency	How often does it run?
Owner	Who is responsible?
Output	What gets produced, in what format, delivered where?
Success Criteria	Quality metrics and performance metrics
Failure Modes	Common problems and their solutions

Dependency rule: Every blockedBy reference must resolve to a real step. Phantom dependencies look active but cannot advance — catch them at plan creation, not mid-execution.

Reference implementation: Article Copywriting Workflow

---

Improvement Loop

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

Process without context = Bureaucracy. Context without process = Chaos. Each cycle adds to the context graph — decision traces become patterns, patterns improve process.

The feedback cycle must be shorter than the defect's blast radius.

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

---

Pit of Success

Design systems where the right thing is the path of least resistance.

Pattern	Without It	With It
Name it	Concepts exist across 6 pages but unnamed — can't be taught or tested	One named concept in one hub page, cross-linked everywhere
Hub pages route	Index is a 3-row table — nobody knows where to start	Curated links with commentary, 10-second test passes
Validate links	46 broken references compound for months, nobody notices	Validation runs every push. Broken link = broken chain
Templates reference sources	Template disconnected from docs it implements — drift guaranteed	source_files in every template phase
Specify return signal	Feedback loop closer is 2 lines + a link	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

---

Context

• Process Optimisation — The parent hub: questioning, problem solving, decisions, method
• First Principles — Question requirements before optimising them
• Standards — Where improved processes compound into predictability
• Work Charts — Who does what (capability → demand)
• Scoreboard — The gauge that proves the improvement loop closed
• Reading the Game — The in-play decision cycle: runs during, not after, the loop

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?