--- 格式版本: 2 标题: "AI-Powered Data Quality Check Architecture for Inbound Integrations | ai-data-science" 原文链接: "https://blogs.oracle.com/ai-and-datascience/ai-powered-dq-check-using-oic" 发布日期: "2026-09-04" 发布时间校准状态: "found" 发布时间需复核: "否" 发布时间来源: "rule:configured_publication_date_rule" 发布时间证据: "doc-fixed-49fb23095330-publication-date html:original: September 4, 2026" 发布时间校准原因: "信源发布日期识别规则直接确认发布时间" 发布时间校准置信度: "high" 发布时间候选数量: 1 发布时间严格候选数量: 1 发布时间原页读取状态: "source template page reused from URL open" 发布时间未找到原因: "" 发布时间校准时间: "2026-09-06T09:33:53+08:00" 发布时间仲裁状态: "skipped" 发布时间仲裁尝试次数: 0 发布时间仲裁耗时毫秒: 0 发现时间: "2026-09-06T09:31:30+08:00" 入库时间: "2026-09-06T01:33:53.947Z" 来源平台: "固定入口" 搜索渠道: "fixed_url" 搜索词: "https://blogs.oracle.com/?page=news" 匹配关键词: - "AI" - "throughput" 相关厂家: - "Oracle" 相关专家: [] 内容类型: "网页" 抓取工具: "CDP Render" 清洗工具: "CDP Text + Defuddle/Readability 正文提取" 原始附件: [] AI优质: "否" AI打分: 28 AI分档: "非优质" AI质检状态: "不通过" AI打分理由: "正文主线是利用Oracle Integration、OCI Enterprise AI和Autonomous Database进行入站业务数据质检与人工复核的解决方案蓝图，并非超节点、AI机架或机架级基础设施。来源为Oracle官方博客，正文完整且有详细流程和示例契约，但内容以参考架构和实施指导为主，未披露正式新产品、标准、生产级基准、客户部署、量产或商业里程碑；发布日期亦缺失。固定知识库未显示同主题历史事件，但不能据此认定首次发布。命中“教程与运维选型/应用集成方案”硬否决，当前页面本身不适合作为超节点业务情报源。" AI质检模型: "gpt-5.6-sol" AI质检时间: "2026-09-07T07:41:26+08:00" AI主题相关性: 0 AI来源权威性: 13 AI新颖性: 2 AI技术细节: 3 AI商业部署信号: 0 AI完整性: 10 AI评分提示词版本: "v17-精简生产版" AI评分提示词SHA256: "48fb9777f386026761b4873eaff30807694fb11e9b352d7c69bf2dfde750cc7d" AI评分知识库版本: "knowledge_base_v1-20260819+runtime.83" AI评分知识库SHA256: "99e157a294119176942ea3afe850c1212d561028e12ce0b35798ec5ecd3e2e24" AI评分知识库检索词: "[\"Oracle\",\"https://blogs.oracle.com/?page=news\",\"NPO\",\"NPU\",\"Meta\",\"Intel\",\"AI-Powered\",\"EA\",\"ID\",\"OCI\",\"FBDI-based\",\"SFTP\"]" AI评分知识库命中: "[{\"id\":\"runtime-dccd09f98e2ca028070793f0\",\"title\":\"OCI Achieves NVIDIA Exemplar Cloud Validation for NVIDIA GB300 NVL72 and HGX B300 | cloud-infrastructure\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-22\",\"matchedTerms\":[\"Oracle\",\"EA\",\"ID\",\"OCI\"],\"rank\":-12.620619306532062},{\"id\":\"july-correct-0001\",\"title\":\"全球首颗2nm GPU来了！苏姿丰甩出“最强AI机架”，CPU性能干翻英伟达 - 智东西\",\"sourceType\":\"labeled_article\",\"time\":\"2026-07\",\"matchedTerms\":[\"Oracle\",\"NPU\",\"Meta\",\"EA\",\"ID\"],\"rank\":-9.498731592222377},{\"id\":\"july-correct-0015\",\"title\":\"AMD to join the optical interconnect party with 2027 Instinct GPUs\",\"sourceType\":\"labeled_article\",\"time\":\"2026-07\",\"matchedTerms\":[\"Meta\",\"EA\",\"ID\",\"OCI\"],\"rank\":-8.737553909427866},{\"id\":\"runtime-3dcabc270e938e0c3b6d5245\",\"title\":\"Nvidia wants to bypass the CPU with an open-source AI storage overhaul\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-06\",\"matchedTerms\":[\"Meta\",\"Intel\",\"AI-Powered\",\"EA\",\"ID\"],\"rank\":-8.539805503788832},{\"id\":\"july-correct-0018\",\"title\":\"AMD, Cerebras partner on joint Helios rack-scale AI inference platform\",\"sourceType\":\"labeled_article\",\"time\":\"2026-07\",\"matchedTerms\":[\"Oracle\",\"Meta\",\"EA\",\"ID\"],\"rank\":-7.900957882139949}]" AI摘要: "Oracle提出一种AI驱动的入站数据质量检查架构，使用Oracle Integration Cloud编排、OCI Enterprise AI进行上下文异常评估、Oracle Autonomous Database作为治理与审计存储。" AI摘要模型: "ali-deepseek-v4-flash" AI摘要时间: "2026-09-06T23:45:05.005Z" 采集批次: "2026年9月6日9点29分24秒" 采集批次ID: "20260906-092924-951" 去重键: "https://blogs.oracle.com/ai-and-datascience/ai-powered-dq-check-using-oic" --- ## 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. Sample Architecture for Inbound Data Quality and Anomaly Detection --- ## 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. Technical Architecture: Agent Orchestration Workflow ### 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:", "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:///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.