boundary-between-customization-and-compatibility
freedom to customize and personalize is valuable, but creates flux and instability
some things should natively support change and some things should enforce stability and resist change
when constructing, things -> components and subcomponents
how can we build so that some components can be fluid to meet user preferences while others in the same product have a rigid strcuture to provide consistent functionality (including cooperation with other components)
what if the key lies in defining a boundary between these?
ultimately all things can physically change, the distinction is that some should accept change and some should resist it
but given all thing are made up of physical components subject to change - what divides in terms of incorporating the purpose?
proposal : rigid kernels wrapped in fluid adaptable layers. We build functional components with stable interfaces and adaptable internals
in software this is classic cohestion and decoupling, but with the injection of great change, it seems the change is infringing beyond stable interfaces into our 'kernels' of core functionality
it seems we need to offset with stronger boundaries enforcing stable functionality
we need stronger enforcement of behavior. to some extent that entails greater specificity of core vs. adaptable functionality
causes.html idris
in terms of fluidity, let's keep an eye on a2ui for agentic customization
and also open-spec