Fixity & Declaring Records

We now live in an age where we expect information to be fluid. Database content is continually changing, web pages are updated by the minute and our news programmes now come as constant 24 hour rolling broadcasts. Yet from the records management perspective it is vital that at set points in the process we draw a metaphorical line in the sand and fix the content of a record as it stands at that point. Once fixed it is equally important that it stays fixed - preserved as an accurate, unaltered record of the event in question.

Why Is This Important?

The importance of this concept of fixity stems again from the fact that records have an importance and purpose above and beyond simply the information they contain. In order to function as evidence, it is vital that records are an accurate and contemporary record of how things were at the time of the record's creation. Obvious examples of when this might be important include the terms of a contract agreed with a 3rd party which must stand for the duration of the contract or procedures introduced to govern how research projects must be conducted. Without agreement as to when these key records have reached their final, approved state and subsequent assurances that their content has not been altered it is easy to predict the potential disputes and challenges which may arise.

Things do, of course, change over time and the records we created must reflect that. The concept of Version Control is covered in the next section of this infoKit. For now we are focusing on the initial point at which the content of the record is fixed, a process commonly known as declaration. All records will have a life before they are declared as a record and their contents fixed. They will be drafted, edited and redrafted as draft documents many times before their contents are agreed, finalised and ready for any formal sign-off procedure. It is at this point that the process of declaration should occur and a record be created.

How To Declare Records

• However, the act of declaration is achieved the result should be the same. That is that the contents of the record are frozen at this point and should remain un-editable from thereon. Also that any associated metadata is likewise fixed to reflect their state at the point of declaration. Particular attention may need to be paid to ensure dates do not alter (e.g. not updating the date last edited every time the record is subsequently viewed after declaration).
• It is important that the principles of provenance are also considered . For example, that the name of the creating department as stated in the metadata remains as it was at the time the record was created, even if subsequently changed during a re-structuring process.
• Care should be taken to consider the entirety of the record at the point of declaration. For example, ensuring that any OLE embedded files are also declared at the same time, or that external information on which that record is reliant (such as a page on the intranet) is also captured.
• For reasons relating to version control (which will be discussed in full later on - ) it is useful to amend file names or other unique identifier codes to reflect the declared status of the record.
• Once declared it should still provide the user with the ability to create a new record based on that declared which will then be treated as a separate entity.