Before modifying processes, surface their embedded schemas — distinguish hard-won lessons from obsolete assumptions
When modifying organizational processes, surface embedded schemas first to distinguish processes encoding hard-won lessons (whose removal reintroduces risk) from processes encoding obsolete assumptions (whose removal reduces waste).
Why This Is a Rule
G.K. Chesterton's fence principle states: before removing a fence, understand why it was built. Processes encode knowledge — sometimes hard-won lessons from past failures, sometimes obsolete assumptions from past conditions. Removing a process without understanding which type of knowledge it encodes is a coin flip: you might eliminate waste (good) or reintroduce a risk that the process was silently preventing (catastrophic).
The diagnostic step — surfacing embedded schemas — asks: "What does this process assume about how things work, and is that assumption still valid?" A process that requires three approvals for purchases over $1,000 embeds the schema "purchase decisions at this level need multiple perspectives to prevent waste." If that schema is still valid (purchase errors remain costly), the process encodes a hard-won lesson. If the schema is obsolete (you now have automated spend analysis that catches anomalies), the process encodes an outdated assumption and can be safely streamlined.
Without this diagnostic, process modification is either recklessly aggressive (removing protective processes that encode lessons) or paralyzingly conservative (keeping obsolete processes because "they might be there for a reason"). The schema-surfacing step provides the information needed to distinguish between the two.
When This Fires
- Before modifying, removing, or streamlining any established organizational or personal process
- When someone says "we should just get rid of this bureaucratic process" without knowing why it exists
- When a process seems wasteful but has been in place for a long time — it may encode invisible protections
- Complements Before retiring an agent, map its three dependency types: output consumers, enforced constraints, and masked failures (dependency mapping before agent retirement) at the process level
Common Failure Mode
Removing processes that feel bureaucratic without understanding their protective function: "This approval step slows everything down — let's remove it." The approval step was installed after a $50,000 unauthorized purchase five years ago. Removing it feels like efficiency; it's actually removing the prevention mechanism for a known failure mode.
The Protocol
(1) Before modifying any process, ask: "What schema does this process encode? What does it assume about how things work?" (2) Investigate the process's origin: why was it created? What problem was it solving? Ask people who were present at its creation if possible. (3) Classify the embedded schema: Still valid (the risk or condition the process addresses still exists) → the process encodes a hard-won lesson. Modify carefully; don't remove the protective function. Obsolete (the risk or condition no longer exists, or a better solution now handles it) → the process encodes an outdated assumption. Safe to remove or streamline. (4) For valid schemas: modify the implementation while preserving the protection. "We still need purchase oversight, but automated spend analysis can replace the manual approval step." (5) For obsolete schemas: remove and monitor briefly (Remove agents gradually — reduce frequency before elimination, monitoring for hidden dependencies during the transition graduated approach) to verify the assumption was truly obsolete.