Immutable releases and comparable results
Evolve visuals and behavior without silently changing what historical evidence means.
Every package release is immutable. An active run pins the exact release and
capability versions it began with. Publishing 1.2.1 never mutates 1.2.0 and
never changes the code used to replay its Attempts.
Three compatibility questions
- Presentation: can the UI or overlay change without changing results?
- Result contract: do identical inputs still produce comparable primary evidence?
- Progression: does the same evidence map through the same aggregation and threshold policy?
A visual polish release may preserve both result and progression lanes. Fixing a scoring bug may deliberately create a new result lane. Changing rank thresholds may preserve the result lane while creating a new progression definition.
Prove evolution
Do not declare compatibility in prose. Run the package-local evolution command against the exact prior archive. It performs structural checks and differential fixture execution, then reports which lanes may remain comparable.
npm run cm -- evolution --from ./releases/my-package-1.2.0.cmpkgThe old archive remains untouched. Rollback changes which immutable release is selected; it never rewrites installation or Attempt history.