FileHold & Records: Part 1 – What is a Record?

FileHold can store files as either a document or a record, which are meaningful terms in the world of information and records management. A document is a source of information of use to an organization, without limit in size, format, or priority. A document can be any file. A record, on the other hand, relates to evidential information of a transaction the organization needs to retain for reference or as evidence. Documents are often the origin of the record, but not necessarily: a ledger or database can also act as a record of transactions, but these may not be a document as we understand them.

In FileHold, documents and records are classifications given to files that are uploaded to the repository. When creating a schema, the default format can be set to documents or records; documents are the default. The file can also be designated as a record when it arrives in FileHold, or a document can be reclassified as a record by an administrator or through an Event.

On the surface, the only difference between them is that users cannot check out and modify records. But since FileHold already preserves content with version control to make sure originals are not overwritten, can apply retention policies as needed, and ensures all content is fully searchable and indexed in the repository, there does not appear to be any need for a record designation – the user could simply move the document to the archive, where further editing is not permitted. What value is the “record” classification?

In information management, there are specific properties to records. The International Council on Archives (https://www.jisc.ac.uk/guides/records-management/what-is-a-record) identifies content, context, and structure as required properties and authenticity, completeness, reliability, and fixity as important traits.

Content

This is the information that the record contains that relates to the transaction in question. This information needs to be sufficient to understand the transaction and capture any decisions made or what was communicated. Content is the “how” and “why”.

Context

Context is the place the record(s) holds not only in the transaction but also in the organization to which it pertains. Consider a contract: it needs to identify the parties, when it was agreed, the area of domain, etc. This is the “who”, “when”, and “where” and establishes the circumstances for the record. It also places the record in a chronology. Combined with context, it establishes scope.

Structure

What makes an invoice an invoice? Each organization lays them out differently, but certain elements are required – the invoice number, the date of issue, who the company is, who the invoice is being issued to, etc. This could be done as text on a page in random order, but an invoice has structure, an inherently logical layout that, when a human eye sees it, makes sense. Structure can include layout, format, medium, symbols, etc. An agreement could be a formal contract, or an email exchange: the format is essential to understand the nature of the agreement. This defines the “what” of the record.

Together, content, context, and structure frames the record and allow the user to place this into the organizational construct. Records are related to a transaction by definition, which is an event – documents do not have such a restriction. Records, therefore, need to have some traits to ensure their caliber; the extent of these traits depends on the need for quality in the organization for the use-case of the records.

• Authenticity – this is related to the process, not necessarily the person, which created the record: can it be identified and proven? This is the provenance of the record.
• Completeness – in its own terms, the record should contain all the content related as evidence of the transaction. An invoice does not capture all the elements of a financial transaction, it captures the details of the invoice, and is therefore complete.
• Reliability – in a paper-based office, this might mean original – but digital files are more complex, so if the record’s content can be depended on as an accurate representation of the transaction, it can be a reliable record.
• Fixity – once declared a record, the content, context, and structure should not change.

An important detail – these are records of transactions, not records of truth. A file full of incorrect information may be a terrible document, but it can be an excellent record from an evidentiary perspective: consider a proposal with misinformation; this is not something you want to use for purchasing but would be very useful in court.

This is why FileHold allows the organization to convert documents to records or vice versa – how that file will be used by the organization depends on the use case in question, and the system needs to be flexible enough to adapt to those situations. Out-of-the-box, FileHold can help with all the other areas of import. Content can be defended with workflow by routing a document for review or approval, or through a drafting process, before preservation as a record if additional levels of sign-off are needed; context can be established with defined metadata to ensure transparent ownership or timestamps; the structure is quickly indicated by the schema. The traits, too, can be enhanced by FileHold: authenticity is part of the administrative metadata once the document/record is added to the repository; linking or common metadata allows for more than one document to make the complete record of the transaction; reliability is more process related, so FileHold can show similar processes with other records; fixity is established by preserving the version as the final.

What FileHold cannot do – what no software can do – is establish whether the record is worth keeping or not, if the contents are true, if they should be kept for more than seven years, etc. In the next part, we will look at some of the specific tools FileHold offers to make records a part of a fully considered document and record management program.