Six Fields, Not Sixty: A Metadata Discipline for UK Capture Projects

Most scanning projects in UK organisations are specified in a room where goodwill is abundant and restraint is not. Each department is invited to list what it would like to know about a document, and each department obliges. The resulting index schema — drafted months before anyone has scanned a single page — becomes the load-bearing wall of the whole workflow. When it fails, it rarely fails loudly. It fails as a rising exception rate, a backlog of documents sitting in a review queue because a field nobody can define has been left blank, and a quiet decision by staff to bypass the system entirely.

The uncomfortable truth is that the scanner does not create the information problem. It simply exposes it at speed.

An index is a retrieval tool, not a description

The first distinction worth making is between describing a document and being able to find it again. A description is open-ended: a good archivist could write a page about a single letter. An index is closed and purposeful — it is the small number of keys by which a person under time pressure will look for that letter in three years' time.

Capture software makes description cheap. Add a field, drag it onto the review screen, and it exists. That ease is precisely the danger. Every field added to a scan profile is a small permanent tax on every document that passes through it: an extra glance, an extra keystroke, an extra reason for the item to stop in an exception queue.

Begin with questions, not with fields

A more reliable starting point is a short exercise with the people who will actually search the repository. Ask them to describe, in plain language, the last five occasions on which they needed to retrieve a document. Record the questions rather than the answers:

• "Show me every invoice from this supplier between April and June."
• "Pull everything relating to case reference 44/118."
• "I need the signed version of that contract, not the draft."
• "What did we hold on this property at the point of sale?"

Then apply the harder test: which of these questions has anyone actually asked in the past twelve months? Questions that survive both stages become candidate fields. Questions that do not should be struck out before build, not after go-live.

It is worth including the negative cases too. If a colleague says "it would be useful to know which department raised it", ask how often they have needed to filter on that basis. Instinct is a poor substitute for a search log.

A workable starting set

For most UK business capture workflows, a set of six fields will carry the overwhelming majority of retrieval demand:

1. Document type — drawn from a closed list, not free text.
2. Document date — the date on the face of the document, never the scan date. Confusing the two is one of the most common and most damaging capture errors, particularly where retention periods are calculated from the document's own date.
3. Counterparty or subject — the supplier, customer, employee or property the document concerns, validated against an existing master list wherever one exists.
4. Unique reference — invoice number, case reference, policy number or contract identifier, captured with a pattern rule.
5. Retention class — the label that links the record to a disposal rule, not a free-text retention note.
6. Source — the channel or system the document arrived through, which is often the only reliable way to trace a batch when something goes wrong.

Six is not a magic number, and a regulated process may genuinely need more. The point is that each field should be able to justify itself against a named retrieval question and a named owner.

Controlled vocabularies do the quiet work

Free-text fields degrade. Two years in, a document type list will contain "Invoice", "invoice", "Inv", "Supplier Invoice" and "Supplier invoice (scanned)", and every one of them will be invisible to a search for the others.

Closing the list is a small piece of work with a large payoff. A document type vocabulary of fifteen to twenty-five values, reviewed annually by a named owner, will cover most business estates. Supplier and customer names should be matched against the finance or CRM master list rather than typed. Dates should be captured in a fixed format and checked for plausibility — a document date three years in the future is almost always an OCR misread of a two.

Validation rules are where capture software earns its keep. Make the essential fields mandatory at the point of scanning. Apply pattern checks to references. Route failures to a defined exception queue with a named owner and an agreed turnaround. A field that is optional in practice is optional in effect, and an index that is only partly populated cannot be relied on in an audit or a disclosure exercise.

The cost of the twelfth field

Over-indexing is rarely framed as a cost, so it rarely gets managed as one. Each additional field tends to produce three effects. First, capture time rises and throughput falls, which is visible in the business case almost immediately. Second, exception rates climb, because more fields means more opportunities for a blank or a mismatch, and every exception is a document sitting outside the workflow. Third, and least visibly, the index becomes opaque: staff stop trusting filters because they know the underlying data is patchy, and revert to browsing folders.

There is also a data protection dimension that UK teams should not overlook. Under UK GDPR, indexing personal data that the business has no retrieval need for widens the surface area of any subject access request or breach, without any corresponding operational benefit. A field that is populated for two per cent of documents is not a control; it is a liability with a column heading.

Treat the schema as a governed artefact

A capture index should be versioned and owned, in the same way a database schema would be. Keep a short field register recording, for each field, its purpose, its owner, its validation rule and its link to a retention class. Require a change request before a field is added. Require a migration plan before one is retired — historical documents will otherwise carry a value that no current screen explains.

Review the register annually against actual search behaviour. Fields that nobody has filtered on for a year are candidates for retirement. New questions that recur are candidates for promotion. That rhythm keeps the index aligned with the business rather than with the ambitions of the original project meeting.

Indexing is unglamorous work, and it is usually squeezed between scanner procurement and go-live. But it is the part of a capture project that determines whether the archive remains usable at year five. A small set of fields, closed lists, real validation and a named owner will outperform an elaborate schema every time — and will still be legible to whoever inherits it.