AI-Powered Data Quality Check Architecture for Inbound Integrations

Introduction

Organizations often receive high volumes of inbound business data from upstream applications, partner ecosystems, and operational platforms. Before that data is loaded into Oracle Fusion, it must be structurally valid, contextually appropriate, and consistent with enterprise governance rules. Traditional validation patterns can either rely on rigid rules that miss contextual anomalies or send too many records to manual review.

This solution blueprint describes a governed, human-in-the-loop architecture for validating inbound data using Oracle Integration, OCI Enterprise AI, and Oracle Autonomous Database. The pattern automates the clean path, directs only exceptions to a business steward, and retains an auditable decision trail throughout the process.

---

The Business Challenge

Inbound data quality is rarely a simple format-validation problem. A record may be structurally valid while still being unsuitable for processing because it conflicts with business context, such as the applicable business unit, supplier, customer, product profile, or policy threshold. Deterministic validation remains appropriate for known constraints such as required attributes, formats, allowed values, and explicit business rules. Context-aware assessment complements these controls by identifying anomalies or inconsistencies that depend on the business profile and may not be captured effectively by static rules alone.

A scalable solution needs to answer three questions for every batch:

1. What business profile and rules apply to this data?
2. Does the batch satisfy the applicable data-quality rules and anomaly thresholds?
3. Should it proceed automatically, be reviewed by a steward, or be returned to the source for correction?

The goal is not to eliminate human involvement. It is to reserve human attention for the records where judgment adds value.

---

Reference Architecture

The reference architecture separates the solution into five logical layers, each with a distinct responsibility:

Layer	Primary responsibility
Source systems	Submit inbound business data and receive correction feedback when required.
Oracle Integration Cloud	Stages data, invokes validation tools, manages human review, and initiates the Fusion import process.
OCI Enterprise AI	Resolves business context and performs profile-aware data quality and anomaly assessment.
Data Governance	Stores business profiles, thresholds, rules, decision outcomes, audit events, and human-review feedback.
Oracle Fusion	Receives approved data through the appropriate import mechanism, such as an FBDI-based load.

Oracle Integration acts as the orchestration layer. It coordinates a small set of focused capabilities rather than embedding every decision in a single integration flow:

• Inbound staging capability retrieves and stages the submitted batch.
• Human-in-the-loop capability creates and tracks stewardship tasks for exception records.
• Fusion import capability prepares and submits approved data to Oracle Fusion.

OCI Enterprise AI provides contextual assessment capabilities that complement, rather than replace, deterministic validation. Oracle Autonomous Database serves as the shared governance layer for business profiles, rules, thresholds, decision evidence, and the traceability required to operate the process responsibly.

---

Technical Architecture

Technical architecture presents a concrete reference implementation while keeping enterprise integration boundaries flexible. Inbound transport may use SFTP, OCI Object Storage, REST/SOAP APIs, messaging, or another approved endpoint. Oracle Fusion loading may use FBDI, supported adapters, REST/SOAP APIs, or another supported import mechanism appropriate to the target object and volume.

1. Inbound Contract and Landing Options

The implementation must not assume a single source transport. All supported channels normalize into the same intake contract before profile resolution or data-quality assessment begins.

Option	Typical use	Concrete intake behavior
SFTP	Partner or scheduled file exchange	OIC FTP Adapter polls or is scheduled, retrieves the file, validates naming/checksum, and archives only after batch registration.
OCI Object Storage	High-volume or durable object landing	OIC receives an object reference/event or retrieves the object; the original payload can remain immutable for evidence.
REST/ SOAP-API	Application-to-application submission	OIC accepts payload plus headers/metadata and returns a batch/correlation identifier.
Messaging / Events	Event-driven ingestion	OIC consumes an event containing a payload or object reference and normalizes it into the batch contract.

Example batch manifest:

{
  "sourceSystem": "PARTNER_MDM",
  "domain": "ITEM",
  "schemaVersion": "3.2",
  "batchId": "ITEM_20260827_001",
  "recordCount": 12500,
  "createdTimestamp": "2026-08-27T10:15:00Z",
  "checksum": "SHA256:<value>",
  "payloadName": "ITEM_20260827_001.zip",
  "correlationId": "CORR-20260827-ITEM-001"
}

For file-based ingestion, a package can contain one or more domain CSV files plus a manifest. PGP encryption/signature can be added where required by enterprise policy. For object storage or API ingestion, the same logical metadata can be supplied as object metadata, request headers, or a companion manifest.

2. Oracle Integration: Orchestration and Control

Oracle Integration is the deterministic control point for the batch lifecycle. A concrete implementation can use four focused integrations/tools plus an optional OIC AI Agent for orchestration. Names below are illustrative and can be aligned with enterprise naming standards.

Component	Role
DQ_Inbound_Intake	Receives/retrieves the payload, validates technical metadata, stages/registers the batch, and starts orchestration.
DQ_Validation_Tool	Runs deterministic structural/reference checks and resolves the applicable profile.
OCI_DQ_Decision_Tool	Invokes the contextual AI assessment and validates/persists the response contract.
Fusion_Import	Runs only for an approved batch and invokes the configured Oracle Fusion import mechanism.
Fusion_Callback	Records callback or polling result, request/job status, errors, and final outcome.
OIC AI Agent	Selects and invokes approved tools; does not approve, mutate governance state directly, or call Fusion outside orchestration controls.

Low-level orchestration will be as follows:

• Receive or retrieve the payload from SFTP, OCI Object Storage, API, messaging, or another approved endpoint.
• Validate manifest/headers, checksum, schema version, file/object identity, and record-count metadata where applicable.
• Register the BATCH_ID and CORRELATION_ID. Enforce idempotency using the source-system identifier, batch identifier, and/or payload checksum. Duplicate submissions must not create duplicate downstream processing.
• Register the batch in Autonomous Database with status RECEIVED before downstream assessment.
• Stage or normalize records, or persist an approved source URI for deferred/segmented processing.
• Invoke the profile-resolution and validation tool with the batch identifier.

Example tool invocation:

{
  "batchId": "ITEM_20260827_001",
  "correlationId": "CORR-20260827-ITEM-001",
  "domain": "ITEM",
  "schemaVersion": "3.2",
  "sourceSystem": "PARTNER_MDM",
  "recordCount": 12500,
  "sourceUri": "sftp://.../ITEM_20260827_001.zip | oci://bucket/path/object"
}

3. Profile Resolver Capability

The Profile Resolver has one responsibility: establish the governed business context that determines which rules, thresholds, tolerances, reference data, and escalation policy apply to the batch or record set. Profile resolution should use deterministic mappings and authoritative reference data wherever the required identifiers are available. AI-assisted interpretation may be used where contextual resolution is necessary, but any inferred context should remain bounded by governed profiles and approved reference data.

• Identify context attributes such as customer, supplier, business unit, source system, item category, country, transaction type, or other domain identifiers.
• Resolve the active DQ profile and profile version.
• Retrieve deterministic rules, anomaly definitions, thresholds, tolerances, and escalation policy from Autonomous Database.
• Enrich the assessment context with approved Oracle Fusion reference data where required.
• Return a bounded context object to the DQ decision capability.

Example resolved profile contract:

{
  "batchId": "ITEM_20260827_001",
  "profile": "ITEM_STANDARD_GLOBAL",
  "profileVersion": "ITEM_V3_2",
  "context": {
    "businessUnit": "US_OPERATIONS",
    "sourceSystem": "PARTNER_MDM",
    "itemCategory": "FINISHED_GOODS"
  },
  "thresholds": {
    "criticalAnomaly": 0.90,
    "reviewThreshold": 0.70
  },
  "ruleSetVersion": "ITEM_RULESET_2026_08",
  "escalationPolicy": "ITEM_DATA_STEWARD"
}

4. Deterministic Data-Quality Validation

Deterministic controls are authoritative for explicit constraints. They should execute before contextual AI assessment so the AI receives known failures as governed evidence rather than being asked to rediscover hard rules.

• Mandatory attributes and schema conformance
• Duplicate source batch and checksum validation
• Data type, date, numeric range, and format validation
• Approved code, unit-of-measure, and reference-data lookup
• Source-to-manifest record-count reconciliation
• Cross-field rules that can be expressed deterministically

Illustrative database procedure sequence

DQ_PKG.RESOLVE_PROFILE(batch_id);
DQ_PKG.RUN_STRUCTURAL_RULES(batch_id);
DQ_PKG.RUN_REFERENCE_RULES(batch_id);
DQ_PKG.COUNT_BLOCKING_ERRORS(batch_id);

The exact implementation may use stored procedures, OIC mappings, APIs, or a rules service. The architectural requirement is that the deterministic result, failed rule IDs, affected record keys, profile/rule versions, and blocking-error count are persisted before contextual assessment.

5. Contextual AI Assessment / DQ Decision Capability

The contextual assessment evaluates anomalies that are difficult to express as static rules: unusual values, duplicates with contextual similarity, invalid attribute combinations, unexpected volume, or deviation from the profile’s expected pattern. It receives only the governed context and minimum data required for assessment. Sensitive or unnecessary source attributes should not be passed to the assessment capability. Prefer bounded attributes, aggregates, deterministic findings, and approved reference context; include record-level source data only when required for the specific assessment.

Required decision prompt

Evaluate only against the ATP-provided profile, thresholds, deterministic findings, and approved domain context. Return JSON only. Return `FAIL` if any deterministic blocking rule failed or if a profile-defined critical anomaly is identified. Never repair source data, alter rules, approve an exception, create an FBDI package, or call Fusion.

Example assessment request

{
  "batchId": "ITEM_20260827_001",
  "profileVersion": "ITEM_V3_2",
  "deterministicResult": {
    "blockingErrorCount": 0,
    "failedRuleIds": []
  },
  "approvedContext": {
    "domain": "ITEM",
    "businessUnit": "US_OPERATIONS",
    "itemCategory": "FINISHED_GOODS"
  },
  "sampleOrAggregate": {
    "recordCount": 12500,
    "uomDistribution": {"EA": 11800, "KG": 700}
  }
}

Required response contract

{
  "batchId": "ITEM_20260827_001",
  "profileVersion": "ITEM_V3_2",
  "decision": "PASS | REVIEW | REJECT",
  "blockingErrorCount": 2,
  "findings": [
    {
      "recordKey": "ITEM-10023",
      "ruleId": "AI-ITEM-012",
      "severity": "ERROR",
      "reasonCode": "UOM_ITEM_CLASS_CONFLICT",
      "explanation": "The unit of measure conflicts with the approved item-class profile."
    }
  ]
}

Oracle Integration validates the returned JSON against the agreed schema and persists the response, model/assessment configuration version, timestamps, and correlation ID. Malformed output, timeout, or an unavailable assessment endpoint must never become an implicit PASS.

6. Autonomous Database Governance Layer

Oracle Autonomous Database (ATP) is the structured governance system of record. It stores configuration and decision evidence; OCI Object Storage is optional for large payloads, rejected-record extracts, reports, or immutable supporting artifacts.

7. Human-in-the-Loop and Failed-Batch Flow

A REVIEW outcome creates a single governed stewardship path. A REJECT or blocking failure returns a controlled correction outcome to the source. For high-control use cases, the original failed batch remains immutable, and corrected data is submitted as a new correlated batch.

1. Persist the finding and update the lifecycle state to REVIEW_REQUIRED or DQ_FAILED.
2. Write large review artifacts to OCI Object Storage when required.
3. Create a DQ_REVIEW task assigned according to the profile escalation policy.
4. Present affected records, failed rules, observed values, expected thresholds, rationale, severity, and recommended remediation.
5. On approval, resume only if policy permits; on rejection/request correction, notify the source through the configured channel.

Do not create an Oracle Fusion import payload for a failed or unapproved batch

Example correction notification payload

{
  "batchId": "ITEM_20260827_001",
  "correlationId": "CORR-20260827-ITEM-001",
  "status": "DQ_FAILED",
  "reasonCode": "BLOCKING_DQ_FINDINGS",
  "findingCount": 2,
  "reviewLocation": "oci://<bucket>/dq-review/ITEM/ITEM_20260827_001/",
  "action": "Correct source data and resubmit as a new batch"
}

8. Controlled Oracle Fusion Processing

Oracle Fusion is reached only after the governance state is explicitly approved. The target mechanism remains use-case dependent; the blueprint must not imply that FBDI is mandatory for every Oracle Fusion integration.

Mechanism	When appropriate	Control requirement
FBDI	Bulk/file-oriented loads supported by the target Oracle Fusion object	Generate package only after DQ_PASSED; capture request/job identifiers and final status.
Oracle Fusion adapter / bulk operation	Supported adapter-driven import patterns	Invoke only after approval; persist callback or polling outcome.
REST / SOAP API	Object/transaction APIs suited to the volume and business operation	Apply the same governance gate and correlation/audit model.
Other supported import mechanisms	Domain-specific supported Oracle Fusion pattern	Must preserve the same approved-state gate and evidence trail.

This implementation creates a concrete but reusable governed inbound path. Transport remains flexible across SFTP, OCI Object Storage, APIs, messaging, and other approved endpoints. Oracle Integration remains the deterministic orchestration and control layer. Autonomous Database holds the authoritative profiles, rules, lifecycle states, and decision evidence. Contextual AI assessment is constrained by governed context and a strict response contract. Human review is reserved for meaningful exceptions, and Oracle Fusion receives data only after an explicit governance gate has been satisfied.

---

Outcome

In practice, this pattern shifts the operating model from “review everything” to “review what matters.” Inbound batches that satisfy the configured controls can clear the automated path without manual intervention, while the exception queue is reserved for records that genuinely require business judgment.

Because every decision automated or human is captured against a correlation identifier in the governance store, the process gains three durable benefits beyond faster throughput:

• A single audit trail spanning staging, AI assessment, human review, and Fusion import, so any batch’s outcome can be explained after the fact.
• Tunable governance thresholds, rules, and profiles can be adjusted as configuration in the governance store, without redesigning the integration.
• A feedback loop for continuous improvement, steward decisions on exceptions provide governed evidence that can inform future rule, threshold, and assessment refinement.

The net effect is a process that gets more precise over time rather than more manual.

---

Why a governed data store matters

The governance data store is more than a technical repository. It is the control point that makes autonomous processing explainable and adaptable.

It should maintain:

• Business profiles and applicability criteria
• Data-quality rules and threshold versions
• Correlation identifiers and batch lifecycle states
• AI assessment results and decision rationale
• Human-review actions and comments
• Fusion import outcomes and error details
• Assessment/model configuration and version metadata

Centralizing these artifacts provides a consistent source of truth for operational support, audit, and continuous improvement. It also enables rule changes to be managed as controlled configuration rather than as repeated integration redesign.

---

Design principles for implementation

Keep orchestration separate from intelligence:

Oracle Integration should coordinate process state and business actions, while profile resolution and data-quality assessment remain independently evolvable capabilities. This separation improves maintainability and allows the assessment approach to evolve without redesigning the end-to-end integration.

Make decisions profile-aware:

Avoid a single global threshold for every source and transaction type. A threshold that is appropriate for one business context may create false positives or missed anomalies in another. Use profiles to apply the right rules to the right data.

Return control to the orchestrator, not the endpoint:

Whatever the outcome—pass, review, or reject—decision authority should flow back through Oracle Integration rather than an AI capability acting directly on the batch. Oracle Integration is what initiates the Fusion import, creates the human review task, or notifies the source system in every case. This keeps AI assessment advisory to the orchestration layer and preserves a single, deterministic control point for actions that affect enterprise data.

Treat correlation as a first-class design concern:

Use a correlation identifier from the moment the batch enters the solution. Carry it through staging, AI assessment, human review, and Fusion import. This creates a complete trace from source submission to final business outcome. This creates complete traceability.

Design the exception route deliberately:

Human review should be concise and actionable. Present the steward with the affected records, the applicable policy, the assessment outcome, and clear actions. Avoid routing every minor issue to a person; use thresholds to focus review on meaningful exceptions.

Persist evidence, not only status:

Record the relevant inputs, rule and assessment versions, assessment outputs, and human decisions that contributed to an outcome. Status alone cannot explain why a batch was approved, reviewed, or rejected.

---

Conclusion

AI-assisted data quality does not need to be an opaque decision layer placed in front of a business application. With Oracle Integration as the deterministic orchestration and control layer, OCI Enterprise AI providing contextual assessment, and Autonomous Database maintaining governed rules and decision evidence, organizations can establish a controlled path from inbound data to Oracle Fusion.

The result is a practical balance of automation and oversight: routine data moves efficiently, meaningful exceptions receive human attention, and every consequential decision remains traceable.

---