Data entry + migration automation.

Extracted fields mapped to target system schema. Source 'cust_name' becomes target 'customer_full_name'; source 'addr_line_1' becomes target 'shipping_address.street'. Transformations applied per field — phone numbers normalized to E.164, addresses verified against postal databases, currency converted at transaction-date FX, enum values translated (source 'Active'/'Inactive' to target 'A'/'I'). Mapping table version-controlled and reviewed; schema changes propagate without re-instrumenting extraction.

Records that extracted cleanly with all required fields populated and confidence above threshold (typically 0.95+ per field). Schema validation passed. Required field presence checked. Type validation confirmed (dates parse, numbers within expected ranges). 60-75% of typical records route here when source data quality is decent. These records skip enrichment and exception handling and flow directly to the load step.

Daily 5% random audit sample reviewed by data ops for false-positive 'clean' classifications. Without sampling, AI errors that pass confidence thresholds compound silently. Quarterly review of sample-audit results identifies extraction patterns to tune. Confidence threshold adjusted based on actual accuracy data — if 5% sample shows 99%+ accuracy, threshold can loosen; if accuracy is 92%, threshold tightens. The threshold is calibrated, not assumed.

Records missing optional fields that can be filled from external sources. Email missing? Look up from people-data API. Address incomplete? Address-verification service fills missing components. Company size unknown? Enrich from D&B or Clearbit. Phone format invalid? Normalization + validation. Enrichment is opt-in per field — always document where each enriched field came from for audit. Some required fields can be enriched (postal codes, country codes); others must come from source (legal name, identifier).

Every enriched field tagged with its source (which API filled it, when, at what confidence). Lineage tracking enables audit trail and downstream debugging — when a customer record has the wrong industry classification, lineage tells you whether it came from source data, Clearbit lookup at extraction, or D&B lookup at enrichment. Per-record enrichment cost capped to control spend (a $0.50 enrichment per record × 100K records = $50K). Some records skip enrichment when cost-benefit doesn't justify.

Records with low extraction confidence on required fields, ambiguous values (date could be 5/12/24 or 12/5/24 — US vs EU format), conflicting values across source records (same customer with two different addresses), or duplicate detection (record might be a duplicate of existing target record). Specific exception detail captured for human reviewer. Each exception type has documented resolution path; junior data ops handle routine exceptions, senior staff handle ambiguous-source disputes.

Reviewer sees the source document/record alongside AI's extraction with confidence scores per field. AI suggests likely value with reasoning ('date format ambiguous; based on US-source pattern in this batch, likely May 12'). Reviewer accepts AI's suggestion (most common — 6 seconds per record), corrects field (15-30 seconds), or marks as unresolvable (rare). 50-200 records per hour per reviewer vs 10-15 records per hour pure manual. The AI suggestion converts review from data-entry-from-scratch to AI-validation.

Loaded records validated post-write — read-back from target system confirms write succeeded with the right values. Source-to-target reconciliation: count of source records vs count of target records; aggregate field totals where applicable (sum of order amounts source vs target). Any drift surfaces specific records for investigation. The reconciliation step is what catches silent failures — write returned 200 OK but the value didn't actually persist (rare, but happens during target-system maintenance windows).

Target system rejected the write. Specific reason captured: validation rule violated (e.g. customer email format invalid in target's stricter validation), uniqueness constraint hit (record with same identifier already exists in target — duplicate detection failed earlier), foreign-key constraint (target requires linked record that doesn't exist), business-rule rejection (e.g. customer must have valid contract before being created). Each rejection routed to data ops for resolution.

Data ops repairs the specific record (manual fix) or escalates to source-system owner. Pattern aggregation: if 50+ records reject for the same reason, the upstream extraction or mapping needs fixing — repair the pattern, not just the records. Quarterly review of rejection patterns identifies systemic gaps. Migration completeness metric tracked: percentage of source records successfully loaded vs rejected; goal is 99%+ for production-quality migrations.