In our current design, the model details, fit settings and fit results are put together in the Model class. This brings some complexity with it:

• We always have to think about what happens when a model is "refit", especially if a different redshift is specified, and features that were deactivated due to the wavelength range have to be reactivated.
• Storing the uncertainties is an issue. They are only meaningful for a fit result, not a fit setup.
• The bounds are stored alongside the result. They are only meaningful for a fitting setup, not the result (although they are still informative to the user, i.e. they can see if a bound has been hit).

Alternative design

1. Model: stores the features table provided at construction, but does not change afterwards. Every call to fit returns a new Results object. Model objects can not be saved.
2. Result: Contains the fitted features table, the uncertainties, maybe even a copy of the user-supplied spectrum? This would be the new home of the "plot" function, and various extraction / analysis tools. Results can be saved and loaded.

Possible issues with this:

• What does "guess" do then? Change Model or return a Result?
• Don't we want to be able to plot unfitted models / initial guesses too?
• How to use a result as initial conditions for another fit (Answer: pass it to the guess function).
• Maybe Model doesn't even need to be a class, but just a fit-function that takes yaml pack spectrum, or a Result spectrum (for re-fitting).
• The user has to learn two classes instead of one.

We're not going to change this now, since we really need to get PAHFIT running. But I really wanted to write this down, and we should keep this type of redesign in mind if we run into more symptoms of the same underlying conceptual problem.