Legal Data Quality Framework

Definitions

Practical workflow

1. Set the decision and population scope

   List the legal decisions, workflows, reports, controls, and deadlines that depend on data. Declare the in-scope populations, such as active matters, closed matters under retention, contracts with renewal rights, regulatory obligations, entities, parties, or access entitlements. Separate launch scope from later populations and name the accountable sponsor.

2. Identify critical data elements

   Prioritize elements whose failure could cause missed deadlines, incorrect legal advice, misrouted work, unauthorized access, inaccurate obligations, flawed reporting, client harm, financial loss, or regulatory exposure. Typical elements include matter ID, client and party identity, matter status, responsible lawyer, jurisdiction, court or docket reference, limitation date, obligation due date, contract status, source record ID, access group, retention state, and review status.

3. Publish the data dictionary

   For each critical element, record the stable field name, business definition, type, unit, requiredness, allowed values, validation rules, source of truth, lineage reference, owner, steward, consumer, freshness requirement, access classification, evidence requirement, and change history. Distinguish display labels from semantic definitions and distinguish unknown, not applicable, pending review, and genuinely missing states.

4. Assign owners and stewards

   Give every critical element one accountable owner and at least one operational steward, with deputies for continuity. Document who can approve definitions, change thresholds, correct values, resolve conflicts, accept exceptions, close issues, authorize access, and escalate unresolved risk. Keep ownership separate from the person who enters or extracts a value.

5. Design source and lineage controls

   For each element, designate the authoritative source for each relevant context and define precedence when sources disagree. Capture source record ID, extraction or event time, transformation steps, mapping version, validation result, correction actor, evidence citation, and downstream destination. Preserve a link from a displayed value back to the source evidence when the value is material or interpreted.

6. Implement quality rules

   Apply type, format, range, controlled-vocabulary, referential, temporal, cross-field, duplicate, and source-reconciliation rules. Test validity, completeness, uniqueness, consistency, and timeliness separately. Treat failed records as visible exceptions or issue candidates; do not silently coerce, overwrite, or discard them to improve a percentage.

7. Protect access and evidence

   Classify legal data by sensitivity, privilege, client restriction, personal information, matter authorization, and retention need. Enforce least privilege across records, search, indexes, exports, reports, integrations, backups, and administration. Review access using a declared population and retain recertification evidence, removal actions, emergency access, and approved exceptions.

8. Set organization-designed thresholds

   Set a target, warning band, breach condition, measurement cadence, sample or census method, owner, and response for each dimension and risk tier. Thresholds should reflect the decision, jurisdiction, data criticality, operating capacity, and acceptable residual risk. Label them as organization-designed examples or approved policy values rather than universal legal or industry requirements.

9. Monitor and triage issues

   Publish dimension-level results by meaningful segment, source, owner, matter type, jurisdiction, system, and severity. Give each issue a stable ID, failed rule, affected population, evidence, severity, owner, due date, containment action, root-cause hypothesis, status, and next review. Trend recurring failures and distinguish data defects from process, integration, identity, access, or definition defects.

10. Remediate, approve exceptions, and control change

    Correct the source where possible, reconcile downstream copies, retest the failed rule, and preserve before-and-after evidence. Record temporary workarounds and approved exceptions with scope, reason, compensating control, owner, expiry or review date, and residual risk. Route changes to definitions, sources, mappings, thresholds, access, retention, or workflows through impact assessment, approval, versioning, migration, communication, and post-change validation.

Comparison

Limitations and exceptions

• There is no universal legal data quality score or universal threshold. A value can be fit for one decision and unfit for another, so dimensions, populations, risk tiers, and approved thresholds must remain visible.
• A high completeness or validity rate does not prove that the underlying value is legally correct. A field can be populated and well formatted while its source document, interpretation, jurisdiction, or current business context is wrong.
• Lineage and source-of-truth design can expose conflicts but cannot resolve every conflict automatically. Material dates, privilege, party identity, obligations, and legal interpretations may require qualified human review.
• Census metrics can inherit systematic source or rule bias, while samples can miss rare high-risk defects. Publish the sampling frame, strata, sample size, review method, and uncertainty or limitations when a census is not practical.
• Access quality is not only an entitlement count. Permission inheritance, search indexes, exports, notifications, integrations, backups, emergency access, and administrative views can create exposure outside the primary record.
• Automated remediation can improve repeatable defects but can also propagate an incorrect mapping or erase evidence. Preserve prior values, source citations, approvals, and rollback or reconciliation steps for material changes.
• A framework needs sustained stewardship, training, budget, issue ownership, and governance. Publishing a dictionary or dashboard once does not make a legal data estate reliable.

Primary sources

Methodology

Use a versioned data dictionary and a metric contract for every critical data element. The metric contract names the element, rule version, population, observation window, source, owner, steward, computation time, unit, and exclusions. Report dimensions separately; do not average them into a universal score. Validity rate = valid eligible values / eligible values tested x 100. The numerator contains values passing the declared type, format, allowed-value, range, relationship, and business-rule tests. The denominator is every in-scope value expected to be evaluated in the declared population. Exclude only approved not-applicable values, records outside the declared scope, and test records formally withdrawn before measurement; retain failed values and unknowns in the denominator. Completeness rate = required usable values present / required values expected x 100. The population is the declared record and field set for the decision. A usable value must be present, not an unsupported stand-in, not an unreviewed unknown where a value is required, and acceptable under the field rule. Exclude only fields formally classified not applicable for that record type and records outside scope. Uniqueness rate = canonical records with no conflicting duplicate in the identity population / eligible records x 100. Define the identity key, match rules, survivorship rule, and duplicate review status before measurement. Exclude only intentionally repeated records that the data model explicitly permits, such as a valid one-to-many relationship; do not exclude unresolved suspected duplicates. Consistency rate = records passing all applicable cross-field and cross-source rules / eligible records tested x 100. The population is the tested record set and named rule set, including date ordering, matter-to-client relationship, status-to-closure logic, source precedence, and code mappings. Exclude only rules marked not applicable by the dictionary and records outside scope; malformed records remain failures. Timeliness rate = eligible values available within the declared freshness or event-time requirement / eligible values due in the period x 100. The population includes values with a known due event or freshness deadline, using one time zone and business-calendar rule. Exclude approved source outage windows, legal holds on change, and formally approved freeze periods only when they are recorded and reported separately; do not hide late values. Lineage coverage = eligible material values with source identifier, source timestamp, transformation or mapping version, and correction history when applicable / eligible material values tested x 100. Access recertification coverage = eligible entitlements recertified within the review window with evidence / eligible entitlements due for review x 100; critical populations should not be silently excluded because a manager is unavailable. Issue remediation SLA attainment = issues closed with a valid retest on or before their approved due date / issues due in the observation period x 100. Count an issue once by stable issue ID, retain reopened issues, and exclude only approved false positives or canceled records with documented authorization. For sampling, publish the frame and strata. Let raw_allocation_j = target_sample_size x stratum_population_j / total_eligible_population, assign floor(raw_allocation_j) to each stratum, then distribute the remaining units one at a time to the largest fractional remainders, breaking ties by stable stratum ID. Cap the requested target at the eligible population and do not allocate more than a stratum contains. Example: populations 10, 20, and 70 with target 26 produce raw allocations 2.6, 5.2, and 18.2; floors 2, 5, and 18 leave one unit, so the largest remainder receives it and the final allocation is 3, 5, and 18, totaling 26. These formulas are measurement contracts, not guarantees of legal correctness. Example organization-designed starting thresholds, to be approved and calibrated locally, are validity >= 99.0% for critical fields, completeness >= 98.0% for active matter and obligation records, uniqueness >= 99.5% for canonical matter and party identities, consistency >= 98.0% for tested cross-field rules, timeliness >= 95.0% for routine updates and 100% for defined hard-deadline controls, lineage coverage >= 98.0% for material values, and access recertification = 100% for critical entitlements. For a local sampling quality gate, an example acceptable defect rate is defect_rate <= 1.0%, with an alert when defect_rate > 1.0%; these are organization-designed examples, not universal requirements. Treat a missed critical deadline, unauthorized access, corrupted lineage for a material decision, or materially wrong party or matter identity as Critical; a repeated defect affecting a material workflow or a missed High-risk freshness rule as High; a contained defect with limited scope or an approaching remediation breach as Medium; and an isolated low-impact defect with an owner and due date as Low. These example severity bands and remediation targets are organization-designed: a possible starting policy is Critical containment immediately and correction or accepted-risk decision within one business day, High within five business days, Medium within twenty business days, and Low within forty-five business days. Set warning and breach bands by population and risk, show counts as well as rates, preserve exclusions and exceptions, trend the results, and review definitions, sources, rules, thresholds, and ownership after material legal, process, system, integration, access, retention, or regulatory change.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Case management
• Compliance management
• Playbooks
• Contract lifecycle management