When two systems disagree, asking an AI to choose the "most likely" value hides the problem. A safer workflow names which record owns each critical fact, compares source versions under declared rules and stops downstream action when the evidence cannot resolve a conflict.
The UK Government Data Quality Framework argues for proactive, evidence-based and targeted data-quality work.[1] It also treats quality as purpose-specific: its six dimensions are not a prescriptive list for every dataset or user need.[1] MAJLS adapts those ideas into a field-level operating contract. This contract is a MAJLS framework, not a government or NIST standard.
The MAJLS field-level reconciliation framework
Use this contract before an AI-assisted step changes a status, sends a message, creates a financial consequence or passes a record to another workflow.
1. Define the scope
Record:
- the business event being checked;
- the comparison cutoff time;
- every participating record and its owner;
- the downstream action that depends on the result;
- the person who may resolve policy exceptions.
Keep the scope narrow. "Reconcile customer data" is not testable. "Compare the order state, packing scan and carrier-acceptance event before marking one shipment dispatched" is.
2. Write the match specification
State how records join before comparing their values:
- stable identifiers and composite keys;
- normalization rules for case, whitespace, dates and time zones;
- transformations that are allowed and prohibited;
- duplicate-handling rules;
- evidence retained for every join or failed join.
Normalization must not become silent correction. Converting a timestamp to one time zone is inspectable. Inventing a missing carrier event is not.
3. Assign authority by field
Do not declare one whole system authoritative for everything. Name the owner of each fact.
| Critical fact | Authoritative record | Why it owns the field | Freshness rule | Conflict owner |
|---|---|---|---|---|
| Order release state | Order-management record | The approved release decision is recorded there | Version current at the comparison cutoff | Order operations owner |
| Package sealed time | Packing scan | The event is created at the packing station | Event timestamp must precede carrier acceptance | Warehouse owner |
| Carrier acceptance | Carrier event record | The carrier produces the acceptance event | Event must be present in the approved integration feed | Customer-operations owner |
Authority is decided in advance by process owners. The AI-assisted step may point to a conflict; it may not appoint a winner.
4. Choose purpose-specific quality rules
The government framework describes completeness, uniqueness, consistency, timeliness, validity and accuracy as core dimensions while warning that the list should vary with data and user needs.[1] Translate only the relevant dimensions into observable checks.
| Rule | Operational test | Failure evidence |
|---|---|---|
| Completeness | All required event records and critical fields are present | Missing record ID or empty required field |
| Uniqueness | One active record exists for the declared business key | Duplicate IDs and their source versions |
| Consistency | Values agree after approved normalization | Both original values plus the applied rule |
| Timeliness | Events fall inside the declared cutoff and delay window | Source timestamp, receipt timestamp and allowed window |
| Validity | Identifier, status and timestamp formats match the agreed schema | Invalid value and schema version |
| Accuracy | A named owner can verify the value against the evidence-producing event | Verification record or unresolved accuracy question |
A rule without a source, threshold and owner is only a preference.
5. Return one of four outcomes
- Reconciled: required records match under the approved rules. The workflow may continue only to its pre-authorized next step.
- Explainable timing difference: values differ because an event is still inside a declared delay window. The workflow may wait or continue only if policy already permits that exact condition.
- Unresolved conflict: source values disagree after approved checks. Block dependent status changes, messages and financial actions.
- Missing record: a required record or field is absent. Block the dependent action and route the evidence to its named owner.
Do not collapse the last two outcomes into a generic warning. They tell the resolver whether to investigate a contradiction or recover missing evidence.
6. Preserve an exception row
| Field | Required content |
|---|---|
| Conflict | Field name and both original values |
| Source state | Record IDs, versions and timestamps |
| Checks performed | Match, normalization and quality-rule results |
| Business impact | Exact downstream actions held |
| Resolver | Named role with authority for this conflict |
| Due time | Policy-defined response time |
| Closure evidence | Owner decision, correction or recovered record |
NIST's AI Risk Management Framework calls for documenting an AI system's knowledge limits, human oversight and enough information to support later decisions and actions.[2] It also says AI systems should be tested before deployment and regularly in operation.[2] For this workflow, test the match rules with synthetic records before use, then monitor failed joins, unexpected duplicates and blocked outcomes. These are observable conditions; a model confidence score is not a reconciliation rule.
Filled example: warehouse dispatch
This is an illustrative example with synthetic identifiers. It is not a client workflow, deployment, operational result or logistics advice.
A fictional warehouse compares three records before changing shipment SYN-4827 to dispatched:
| Contract item | Filled value |
|---|---|
| Business event | Confirm carrier acceptance for shipment SYN-4827 |
| Cutoff | 30 September 2026, 09:15 GST |
| Match key | Synthetic shipment ID plus package token |
| Downstream actions | Change dispatch status; prepare customer notification |
| Human conflict owner | Customer-operations manager |
The order record says packed at 08:42. The packing scan records the same package token at 08:41. The carrier feed contains no acceptance event by the cutoff. Format and identity checks pass, but completeness fails.
The result is missing record, not reconciled and not an explainable timing difference. The workflow creates this exception:
| Field | Filled value |
|---|---|
| Conflict | Carrier acceptance event absent |
| Source state | Order v12; packing scan event PK-SYN-4827; carrier query at 09:15 |
| Checks performed | Identifier match passed; timestamp normalization passed; required-event check failed |
| Business impact | Dispatch status change and customer message blocked |
| Resolver | Customer-operations manager |
| Due time | 09:30 GST under the illustrative policy |
| Closure evidence | Carrier event arrives, or the named owner records an authorized exception decision |
The AI-assisted step may summarize the discrepancy and prepare the packet. It may not invent the event, select another value, mark the shipment dispatched, contact the customer or waive a service condition.
Consequential approval remains with the named human operations owner. If customer, financial or contractual consequences are involved, the person authorized by the organization's policy decides what happens next. Escalation depends on missing evidence, contradictory versions, failed rules, expired timing windows and authority boundaries, never model confidence alone.
First implementation checklist
Before connecting a live workflow:
- select one business event and one dependent action;
- name record owners and field authority;
- freeze match, normalization and cutoff rules;
- test all four outcomes with synthetic records;
- confirm that unresolved and missing records block the right actions;
- give exceptions a named human resolver and due time;
- retain source versions, checks and closure evidence;
- review failure patterns and rule changes with the process owners.
A reconciliation contract does not promise perfect data. It makes disagreement visible before the workflow turns it into an action.