I would also suggest we add fields to the `settingsApplied` event to output the description and title that goes in the configuration title. 

Michael Reuter?

I agree it would be nice to have some means of identifying why a configuration file exists. I am less convinced that a title is useful; I would rather use the name of the file as the title. It is more likely to be correct and avoids duplicating information.

Enforcing the presence of a description field is tricky because every CSC's configuration schema is independent of every other. One possibility is to have a unit test that tests all config files against the schema. I think this is a good idea in any case, as otherwise we may have broken config files that only show up when we try to use them. Such a test could demand the presence of a non-empty description field.

Note: it will probably be common to create a new config file by copying and modifying an existing file. If the user forgets to change the description it will be wrong. Incorrect information can be worse than no information. However, the unit test I just mentioned could check that the description field is different for each file.

We have agreed to support a metadata item in configuration files and will put this information there.

In DM-29621 I have updated ts_salobj to ignore the metadata entry. In other tickets that we run in the ts_config packages we will test for the presence of metadata. (The code for those tests may well end up in ts_salobj, but not on either of these tickets).