If integration requires reshaping one schema to fit another, it's Procrustean — abandon it and keep schemas separate or find a higher-order framework
When an attempted integration between two schemas forces you to reshape one schema to fit the other rather than discovering a higher-order structure that accommodates both unchanged, you are executing Procrustean integration—abandon the attempt and either maintain the schemas separately or search for a genuinely encompassing framework.
Why This Is a Rule
Procrustes was the mythical innkeeper who stretched short guests and amputated tall ones to fit his one-size bed. Procrustean integration does the same to schemas: when two frameworks don't naturally fit, you distort one to make it compatible with the other. The result looks like integration but is actually the destruction of one schema's integrity to serve the other's structure.
Genuine integration discovers a higher-order structure that accommodates both schemas unchanged — like discovering that Newtonian mechanics and thermodynamics are both instances of energy conservation. Neither schema was reshaped; a broader framework was found that contains both. Procrustean integration, by contrast, forces one schema into the other's categories: "Well, if we redefine 'feedback' in psychology to match the engineering definition..." The redefinition destroys what made the psychological concept useful.
The diagnostic signal is effort direction: are you discovering a structure that naturally accommodates both schemas, or are you editing one schema's definitions to make it compatible? The first produces genuine understanding; the second produces a Frankenstein framework that works worse than either original.
When This Fires
- When you're trying to integrate two frameworks and finding yourself redefining terms in one to match the other
- When the integration feels forced — like you're making the pieces fit rather than finding where they naturally connect
- During knowledge system architecture when merging overlapping schemas
- When the "integrated" result is harder to use than the separate schemas were
Common Failure Mode
Mistaking terminological alignment for structural integration. Renaming concepts in Schema B to match Schema A's vocabulary creates the appearance of integration without any structural insight. The schemas now use the same words but the underlying structures remain incompatible — and now you can't even see the incompatibility because the vocabulary masks it.
The Protocol
(1) During any integration attempt, monitor the direction of effort. Are you discovering a natural higher-order structure, or are you editing one schema to fit the other? (2) Signs of Procrustean integration: you're redefining terms, dropping "inconvenient" components of one schema, or forcing categorical matches that feel strained. (3) If Procrustean → stop. You have two options: (a) Maintain the schemas separately. Separate schemas that work well individually are better than a forced integration that works poorly. (b) Search for a genuinely encompassing framework at a higher level of abstraction. This is harder but produces real integration. (4) Test any candidate integration: does each original schema survive intact within the higher-order framework? If either was reshaped → still Procrustean.