This is really great stuff, as usual from Ink & Switch. One initial thought that I'd offer is that in a simple running system, these 'lenses' are arranged into

This is really great stuff, as usual from Ink & Switch. One initial thought that I'd offer is that in a simple running system, these 'lenses' are arranged into a series[1] that can take a datastructure from an origin 'base' version all the way through to the latest-known representation. This may be more familiar to most developers as an analogy to database migration scripts, as mentioned in the post. When a new lens is created, the developers may want to distribute it to a subset of users, ensure that it works correctly, and potentially adjust it based on feedback before issuing the final lens to the application's population[2]. If this is the intended release workflow, then the arrangement of lenses becomes a graph or chain rather than a simple series. There may be times where it's necessary to backtrack briefly. It's possible (although hacky, I will admit) to create an NPM JavaScript module that has another version of itself as a dependency. I mention that because this provides a way to distribute some code -- a lens, for example -- alongside a dependency graph using an ecosystem that is relatively well-evolved (in terms of release management, client upgrade support, etc) for versioned code distribution. [1] It's nice the that analogy with light passing through a series of lenses fits [2] Think of an optician testing your eyesight and asking questions about various sample lenses