Quality Control Auditing

A coding protocol defines the standard. Quality control auditing is what ensures the standard is actually followed: consistently, across every coder, across the life of the project.

Why QA Matters

Coding errors in document databases compound over time. A naming inconsistency, a date format variation, or a misapplied document-type classification introduced early in the project will be replicated hundreds or thousands of times if it is not caught. By the time the team discovers the problem, it has spread through the database and may be too costly to correct retroactively.

Quality control auditing exists to catch those errors early, before they compound, and to ensure that the coding protocol is being applied consistently by every person entering data into the collection.

Rolling QA Review

Quality assurance is not a single event at the end of the project. Effective QA is rolling: it happens continuously as records are coded, so that errors are caught and corrected while they are still isolated rather than systemic.

Rolling QA review means regularly sampling coded records, checking them against the coding manual, identifying deviations, and correcting them. It also means tracking which types of errors recur, so the coding manual or training can be updated to prevent them.

New-Coder Auditing

New coders (whether new team members, new contractors, or coders moving to a new section of the collection) are the highest-risk period for coding inconsistency. They may interpret coding conventions differently, miss standards that are implied rather than explicit, or apply habits from previous projects.

New-coder auditing means reviewing a higher proportion of their initial work, providing specific feedback, and confirming that they are applying the project coding protocol before their work is accepted into the database without review.

Audit Trail

Every quality control review should be documented: what was reviewed, when, by whom, what errors were found, and what corrections were made. This audit trail is part of the collection's defensibility. It shows that the team had a quality control process and applied it.

Without an audit trail, the team may have conducted QA reviews but cannot prove it. The audit trail is the documentation that turns quality control from an internal practice into a defensible process.

Inherited Database QA

When a team inherits a database built by a previous team or contractor, the first step is usually a QA review. The review assesses the consistency of the existing coding, identifies systemic problems, and determines whether the database can be corrected or needs to be substantially reworked.

This salvage-versus-redo decision is critical. Reworking a database is expensive, but relying on a database with systemic coding problems is a production risk that may be more expensive to address later.