AI 驱动的元数据纠正与统一

随着数据采集和数据生成不断加速，我们生产原始数据的能力与标准化这些数据的能力之间的差距仍在扩大。缺少自动化时，这一差距会成为关键瓶颈，延迟分析、增加解释难度，并限制共享数据集在全球范围内的价值。

元数据统一（即对标签、标识符和格式进行标准化，使来自不同来源的数据集能够协同工作）仍主要依赖人工完成。AI 驱动的元数据纠正与统一提供了一条前进路径：它将元数据管理从耗时的职责，转变为可随数据量扩展的流程，并支持而非阻碍开放科学。

本文将演示 AI 驱动的元数据纠正在实践中如何运作，探讨两种实现方法（从人机协同验证到完全自主的 Agent 驱动工作流），并为组织部署这些解决方案提供治理方面的考量。

为应对这一挑战，我们构建了一个基于 AWS 的集中式元数据纠正与统一工作流，旨在支持不同元数据来源之间的一致性、互操作性和准确性。该系统使用 Amazon Bedrock 提供由大语言模型（LLM）驱动的模式对齐和纠正建议，使用 Amazon Simple Storage Service (Amazon S3) 存储模式和结果，使用 Amazon DynamoDB 跟踪作业，使用 Amazon Cognito 进行身份验证，并使用 Amazon Elastic Container Service (Amazon ECS) 提供计算能力。该工作流包含一个统一软件包，用于对齐元数据模式、验证数据完整性并生成纠正建议。

元数据纠正与统一系统以循环式工作流运行：引导数据经过验证、生成建议，并将最终批准权交还给用户。下图展示了这一高层流程：

图 1：元数据纠正与统一工作流

如图所示，流程从用户上传元数据文件开始。随后，系统并行执行两类验证：模式对齐用于验证列结构是否符合预期格式；元数据字段验证则检查各个字段值是否合规。检测到问题后，系统会生成有针对性的纠正建议并呈现给用户，用户仍对变更保有最终决策权。这种人机协同方法既能通过自动化加快流程，又能保留研究人员的控制权和领域专业知识。

模式对齐

元数据纠正的第一步，是比较源数据模式和目标数据模式：确认正确的列是否存在，并且是否得到了恰当对齐。常见问题包括命名约定不一致（同义词、拼写错误、缩写）、缺失或冗余列，以及需要拆分或合并列的情况。模糊字符串匹配可以处理基础的命名差异，但更复杂的对齐挑战需要不同的方法。Amazon Bedrock 上可用的 LLM 为这一问题带来了语义理解能力。与仅依赖字符串相似度不同，LLM 驱动的方法能够识别行业特定同义词、从周边列中推断含义，并检测源列何时应拆分为多个目标列，或多个源列何时应合并为一个目标列。这种语义匹配能够处理基于规则的系统遗漏的情况。

元数据字段验证组件会检查各个字段值是否符合模式要求。系统会依据预定义规则评估每个字段，并将失败情形分为三类。

必填字段验证用于识别缺失、为空或仅包含空白字符的必填字段。例如，缺少必填样本标识符的行会在进一步处理之前被标记。

枚举值验证将字段内容与模式中定义的受控词表进行比较。如果某字段只接受特定仪器类型（例如测序系统），列表之外的值将触发验证错误。这有助于防止自由文本在标准化字段中引入不一致。

模式验证应用正则表达式匹配来验证格式约定。日期字段可能要求采用 YYYY-MM-DD 格式，而标识符字段可能需要符合特定的字母数字模式。偏离预期格式的值将被标记。

每项验证失败都会被分类和记录，并附带足够的上下文信息，使建议系统能够生成恰当的纠正方案。结构化错误报告会明确每个问题的位置、类型和性质。

当元数据字段验证检测到错误时，系统会采用自然语言处理（NLP）与 AI 技术的分层组合生成建议，以在成本效率、性能和可解释性之间取得平衡。通过在调用 LLM 前优先使用传统 NLP 和基于嵌入的相似度方法，该工作流能够在保持推理成本可预测的同时，提供准确且可扩展的建议。

这些技术既可以单独运行，也可以在 bagging 或 boosting 架构中按顺序运行，并根据置信度阈值动态选择。这种自适应分层让较简单的方法能够高效处理常规纠正，而高级模型则只处理需要上下文推理的模糊或新颖情形。

1. 通过嵌入实现语义相似度

向量嵌入使系统能够从语义层面比较元数据值，并根据相似度阈值识别接近的匹配项。这支持对同义词、缩写或首字母缩略词等常见变体进行精确纠正。例如，系统可以将“Human”映射为“Homo sapiens”，或将“NYC”映射为“New York City”。

该方法依赖更小、更高效的嵌入模型（可通过 Amazon Bedrock 使用），其输出可被缓存，因此在保持准确性的同时，能够提供比 LLM 驱动推理更具成本效益的替代方案。

我们评估了多个嵌入模型，包括领域专用的生物医学模型和 Amazon Titan，以确定最适合该工作负载的方案。我们选择了 Amazon Titan，因为它在通用及生物医学元数据任务中表现强劲，具备商业可用性，并兼容 Amazon Bedrock 模型推理。这使其特别适合需要受支持、可扩展的嵌入解决方案，同时不希望承担自主管理领域专用模型运维开销的组织。

2. 上下文推理

上下文推理通过识别元数据自身内部的关系和共享模式，为系统提供纠正建议。许多数据集具有内部一致性，即相似行会共享结构特征，或在列之间出现重复值。通过分析这些局部相似性，模型可以仅利用当前上传数据中存在的信息，推断缺失或不一致的元数据值，而无需大型外部训练数据集。

在该实现中，上下文推理采用混合方法，将距离加权 k 近邻与词频-逆文档频率（TF-IDF）特征表示及共现统计相结合。数据集中的每一行都会被转换为由文本、类别和数值字段构成的复合向量。文本字段被转换为 TF-IDF 表示，类别值通过独热编码或紧凑的学习型表示进行编码，数值字段则被缩放到可比较的范围。系统随后使用余弦距离或欧氏距离衡量行之间的相似度，并通过对最相似示例进行加权投票来预测缺失值，其中更近的邻居具有更大的影响力。

系统还通过使用逐点互信息（PMI）进行共现分析来进一步优化，该方法识别数据集中自然共同出现的值组合。PMI 衡量超越原始频率的统计关联，可捕捉诸如“当 A 列包含 X 时，B 列通常包含 Y”这样的模式。最终建议会以可配置的权重结合相似度和共现信号。该方法基于内部数据结构而非外部训练生成稳定、可解释的建议，即使面对小型或专业化数据集，也能实现高效性和可靠性。

3. 模糊匹配

Levenshtein 距离等模糊搜索算法可检测并纠正拼写或格式不一致问题。它们尤其适合解决人工录入元数据中的错误，例如拼写错误、空格差异或标点差异。模糊匹配通常在纠正工作流的早期应用，在语义或上下文推理层介入前捕获低层级的不一致。

4. 基于 LLM 的解决方案（回退层）

当包括基于规则的 NLP 和嵌入相似度模型在内的前序验证方法无法达到足够的置信度时，通过 Amazon Bedrock 实现的基于 LLM 的解决方案将作为回退层。这些模型可以跨复杂元数据结构进行推理，以解读模糊或此前未见的模式。LLM 推理仅会被选择性调用，即只有在更简单的算法无法以高置信度解决字段问题时，才会使用计算密集型推理。随后，结果将提交人工审核，以维持后续数据统一过程中的准确性和可追溯性。

总结

元数据纠正与统一工作流结合了三个阶段：通过 LLM 驱动的语义分析实现模式对齐；通过分层的基于规则方法完成字段验证；以及由嵌入、模糊匹配和上下文推理驱动的建议生成。较简单的方法处理常规纠正，而基于 LLM 的解决方案则作为回退机制，处理传统方法无法解决的边缘情况。

前提条件

部署应用程序前，请确认已安装以下工具：

node -v          # 18 或更高版本
python --version # 3.11 或更高版本
aws --version    # 已使用凭证配置 AWS CLI

快速开始

第 1 步：克隆并安装依赖项

克隆仓库并安装所有 Python 和 TypeScript 依赖项：

git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# 创建并激活 Python 虚拟环境
make createPythonEnvironment
source .venv/bin/activate

# 安装所有依赖项（Python 包、TypeScript 包、CDK、前端）
make install

make install 命令使用 uv 将 processor、API、agent 和 evaluation 软件包安装为可编辑的 Python 包，并为基础设施和前端项目运行 npm install。

第 2 步：配置部署

复制配置模板，并根据 AWS 账户详情进行编辑：

cp config.yaml.example config.yaml

编辑 config.yaml：

appName: "metadata-harmonization-app"
env: "dev"

dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012"     # 你的 12 位 AWS 账户号码
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

验证配置：

第 3 步：部署基础设施

引导 AWS CDK（仅首次需要），然后部署：

# 首次设置：为 CDK 准备 AWS 账户
make bootstrap

# 部署所有 AWS 资源
make deploy

make deploy 将构建 API 容器镜像、将其推送至 Amazon ECR，并部署 AWS CDK 堆栈。这会创建 Amazon DynamoDB 表、Amazon S3 存储桶、Amazon Cognito 用户池和 Amazon ECS Fargate 服务。

部署完成后，使用已部署资源的标识符生成本地 .env 文件：

make createLocalDotEnvFile

第 4 步：创建 Amazon Cognito 用户

部署后，在 Amazon Cognito 用户池中创建用户，使其能够登录应用程序：

1. 打开 Amazon Cognito 控制台。
2. 选择部署所创建的用户池（例如 metadata-harmonization-users）。
3. 前往 Users，然后选择 Create user。
4. 输入用户的电子邮件地址和临时密码。
5. 选择 Create user。

用户将在首次登录时被提示设置永久密码。

第 5 步：在本地运行 Web 应用程序

同时启动 API 服务器和 Next.js 前端：

# 同时运行 API 和前端（推荐）
make runLocal

或者在不同终端中分别运行：

# 终端 1：API 服务器
make runApiLocal

# 终端 2：前端
make runUiLocal

通过以下地址访问系统：

• Web 界面：http://localhost:3000。
• API 文档：http://localhost:8080/api/docs。

API 服务器运行后，打开第二个终端并运行 Agent：

uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

该 Agent 通过模型上下文协议（MCP）连接 API，验证数据集、获取失败报告，并自主应用纠正。

人机协同

人工监督仍是维护元数据质量和可信度的核心。元数据纠正与统一系统被设计为协作式工作流，使数据贡献者能够继续控制其提交的数据。该交互

As data collection and data generation accelerate, the gap between our ability to produce raw data and our capacity to standardize it continues to widen. Without automation, this gap becomes a critical bottleneck that delays analysis, complicates interpretation, and limits the global value of shared datasets.

Metadata harmonization (standardizing labels, identifiers, and formats so datasets from different sources can work together) remains largely manual. AI-powered metadata correction and harmonization offers a way forward, transforming metadata management from a time-consuming responsibility into a process that scales with your data volume and supports open science rather than obstructing it.

In this post, we demonstrate how AI-powered metadata correction works in practice, explore two implementation approaches (from human-in-the-loop validation to fully autonomous agent-driven workflows), and provide governance considerations for deploying these solutions in your organization.

To address this challenge, we developed a centralized metadata correction and harmonization workflow built on AWS, designed to support consistency, interoperability, and accuracy across disparate metadata sources. The system uses Amazon Bedrock for large language model (LLM)-powered schema alignment and correction recommendations, Amazon Simple Storage Service (Amazon S3) for schema and result storage, Amazon DynamoDB for job tracking, Amazon Cognito for authentication, and Amazon Elastic Container Service (Amazon ECS) for compute. The workflow includes a harmonization package that aligns metadata schemas, validates data integrity, and generates correction recommendations.

The metadata correction and harmonization system operates as a cyclical workflow that guides data through validation, generates recommendations, and returns control to the user for final approval. The following diagram illustrates this high-level flow:

Figure 1: Metadata correction and harmonization workflow

As shown in the diagram, the process begins when users upload their metadata files. The system then performs two parallel validation streams: schema alignment verifies that column structures match expected formats, while metadata field validation examines individual field values for compliance. When issues are detected, the system generates targeted correction recommendations and presents them to the user, who maintains final decision authority over changes. This human-in-the-loop approach lets automation accelerate the process while preserving researcher control and domain expertise.

Schema alignment

The first step in metadata correction is comparing source and target data schemas: verifying that the right columns exist and are properly aligned. Common issues include inconsistent naming conventions (synonyms, misspellings, abbreviations), missing or extra columns, and cases where columns need to be split or combined. Fuzzy string matching can handle basic naming discrepancies, but more complex alignment challenges require a different approach. LLMs available on Amazon Bedrock bring semantic understanding to this problem. Rather than relying on string similarity alone, an LLM-driven approach can recognize industry-specific synonyms, infer meaning from surrounding columns, and detect when a source column should be split into multiple target columns or vice versa. This semantic matching handles the cases that rule-based systems miss.

The metadata field validation component checks whether individual field values comply with schema requirements. The system evaluates each field against predefined rules and categorizes failures into three types.

Required field validation identifies mandatory fields that are missing, empty, or whitespace-only. A row missing a required sample identifier, for example, is flagged before further processing occurs.

Enumerated value validation compares field contents against controlled vocabularies defined in the schema. If a field accepts only specific instrument types (such as sequencing systems), values outside that list trigger a validation error. This helps prevent free-form text from introducing inconsistencies in standardized fields.

Pattern validation applies regular expression matching to verify formatting conventions. Date fields might require YYYY-MM-DD format, while identifier fields might need specific alphanumeric patterns. Values that deviate from the expected format are flagged.

Each validation failure is classified and documented with enough context for the recommendation system to generate appropriate corrections. The structured error reports specify the location, type, and nature of each issue.

When validation errors are detected during metadata field validation, the system generates recommendations using a layered combination of natural language processing (NLP) and AI-based techniques designed to balance cost efficiency, performance, and interpretability. By prioritizing classical NLP and embedding-based similarity before invoking LLMs, the workflow achieves accurate, scalable recommendations while keeping inference costs predictable.

These techniques can operate individually or in sequence within bagging or boosting architectures, dynamically chosen based on confidence thresholds. This adaptive layering lets simpler methods handle routine corrections efficiently, while advanced models resolve only the ambiguous or novel cases that require contextual reasoning.

1. Semantic similarity through embeddings

Vector embeddings let the system compare metadata values semantically, identifying close matches based on similarity thresholds. This supports precise correction of common variations such as synonyms, abbreviations, or acronyms. For example, the system can map “Human” to “Homo sapiens” or “NYC” to “New York City.”

This approach relies on smaller, efficient embedding models (available on Amazon Bedrock) whose outputs can be cached, providing a cost-effective alternative to LLM-driven reasoning while maintaining accuracy.

We evaluated multiple embedding models, including domain-specific biomedical models and Amazon Titan, to identify the most appropriate fit for this workload. We selected Amazon Titan for its strong performance on general and biomedical metadata tasks, commercial availability, and compatibility with Amazon Bedrock model inference. This makes it well suited for organizations that require a supported, scalable embedding solution without the operational overhead of self-managed domain-specific models.

2. Contextual inference

Contextual inference lets the system recommend corrections by identifying relationships and shared patterns within the metadata itself. Many datasets exhibit internal consistency where similar rows share structural traits or repeated values across columns. By analyzing these local similarities, the model can infer missing or inconsistent metadata values using only the information present in the current upload, avoiding the need for large external training datasets.

In this implementation, contextual inference operates through a hybrid approach that combines distance-weighted k-nearest neighbors with Term Frequency-Inverse Document Frequency (TF-IDF) feature representations and co-occurrence statistics. Each row in the dataset is converted into a composite vector built from its text, categorical, and numeric fields. Text fields are transformed into TF-IDF representations, categorical values are encoded through one-hot or compact learned representations, and numeric fields are scaled to comparable ranges. The system then measures the similarity between rows using cosine or Euclidean distance and predicts the missing value by performing a weighted vote among the most similar examples, where closer neighbors contribute more influence.

Further refinement is achieved through co-occurrence analysis using Pointwise Mutual Information (PMI), which identifies value combinations that naturally appear together within the dataset. PMI measures statistical association beyond raw frequency, capturing patterns like “when column A contains X, column B typically contains Y.” The final recommendation combines both similarity and co-occurrence signals with configurable weights. This produces stable and explainable recommendations grounded in internal data structure rather than external training, resulting in efficiency and reliability even in small or specialized datasets.

3. Fuzzy matching

Fuzzy search algorithms such as Levenshtein distance detect and correct typographical or formatting inconsistencies. They are especially effective for resolving errors in manually entered metadata, such as misspellings, spacing, or punctuation differences. Fuzzy matching is typically applied early in the correction workflow to capture low-level inconsistencies before semantic or contextual inference layers are applied.

4. LLM-based resolution (fallback layer)

When earlier validation methods, including rule-based NLP and embedding similarity models, fail to reach a sufficient confidence level, LLM-based resolution through Amazon Bedrock acts as a fallback layer. These models can reason across complex metadata structures to interpret ambiguous or previously unseen patterns. LLM-based inference is invoked selectively, meaning computationally intensive reasoning is used only when simpler algorithms cannot resolve a field with high confidence. The results are then surfaced for human review to maintain accuracy and traceability in downstream data harmonization.

Summary

The metadata correction and harmonization workflow combines three stages: schema alignment through LLM-powered semantic analysis, field validation using a tiered rule-based approach, and recommendations driven by embeddings, fuzzy matching, and contextual inference. Simpler methods handle routine corrections, while LLM-based resolution serves as a fallback for edge cases that traditional methods cannot resolve.

Prerequisites

Before deploying the application, confirm the following tools are installed:

node -v          # 18 or higher
python --version # 3.11 or higher
aws --version    # AWS CLI configured with credentials

Getting started

Step 1: Clone and install dependencies

Clone the repository and install all Python and TypeScript dependencies:

git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# Create and activate Python virtual environment
make createPythonEnvironment
source .venv/bin/activate

# Install all dependencies (Python packages, TypeScript packages, CDK, frontend)
make install

The make install command installs the processor, API, agent, and evaluation packages as editable Python packages using uv, and runs npm install for the infrastructure and frontend projects.

Step 2: Configure the deployment

Copy the configuration template and edit it with your AWS account details:

cp config.yaml.example config.yaml

Edit config.yaml:

appName: "metadata-harmonization-app"
env: "dev"

dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012"     # Your 12-digit AWS account number
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

Validate the configuration:

Step 3: Deploy infrastructure

Bootstrap AWS CDK (first time only), then deploy:

# First-time setup: prepare your AWS account for CDK
make bootstrap

# Deploy all AWS resources
make deploy

make deploy builds the API container image, pushes it to Amazon ECR, and deploys the AWS CDK stack. This creates Amazon DynamoDB tables, Amazon S3 buckets, an Amazon Cognito user pool, and an Amazon ECS Fargate service.

After deployment, generate a local .env file with the deployed resource identifiers:

make createLocalDotEnvFile

Step 4: Create Amazon Cognito users

After deployment, create users in the Amazon Cognito user pool so they can log in to the application:

1. Open the Amazon Cognito console.
2. Select the user pool created by the deployment (for example, metadata-harmonization-users).
3. Go to Users and choose Create user.
4. Enter the user’s email address and a temporary password.
5. Choose Create user.

The user will be prompted to set a permanent password on first login.

Step 5: Run the web application locally

Start both the API server and the Next.js frontend:

# Run both API and frontend together (recommended)
make runLocal

Or run them in separate terminals:

# Terminal 1: API server
make runApiLocal

# Terminal 2: Frontend
make runUiLocal

Access the system at:

• Web interface: http://localhost:3000.
• API documentation: http://localhost:8080/api/docs.

With the API server running, open a second terminal and run the agent:

uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

The agent connects to the API through the Model Context Protocol (MCP), validates the dataset, retrieves failure reports, and autonomously applies corrections.

Human-in-the-loop

Human oversight remains central to maintaining metadata quality and trust. The metadata correction and harmonization system is designed as a collaborative workflow that keeps data contributors in control of their submissions. The interface provides immediate feedback, recommendations, and actionable corrections, so contributors can validate and approve metadata efficiently while preserving data integrity.

UI flow and interaction

The human-in-the-loop process begins when a data contributor selects and uploads their metadata file through the browser interface. Contributors can inspect and modify metadata locally before initiating validation, allowing pre-submission adjustments using lightweight, client-side tools. When ready, they trigger metadata processing, which sends the dataset to the cloud for automated validation and harmonization. When the workflow executes, one of two outcomes occurs:

1. A validation pass, where metadata aligns fully with the schema and is emitted downstream for integration.
2. A validation failure, which generates detailed recommendations for missing or inconsistent fields.

These recommendations surface directly in the interface for review and correction. Contributors can inspect flagged entries, review AI-generated suggestions, and either accept, edit, or reject them. Once satisfied, they resubmit the corrected metadata for revalidation. Successful submissions are automatically confirmed and propagated downstream, completing the harmonization cycle.

Figure 2: Human-in-the-loop metadata correction workflow

Each cycle reduces manual effort while preserving contributor ownership of the final output.

The following video demonstrates how automation and human review coexist in a single streamlined process. Rather than relying on researchers spending days performing manual metadata alignment, the system acts as a collaborative assistant, accelerating corrections while helping validate that records reflect contributor intent and domain expertise.

Title: “Metadata Upload and Validation Workflow” A 90-second demonstration showing the full end-to-end process of metadata upload, validation, and correction through the browser interface.

The human-in-the-loop approach gives researchers the speed of automation without giving up control. AI-generated recommendations surface through the interface, but researchers decide what gets applied. This collaborative model builds trust in the system while keeping domain-specific knowledge central to the correction process.

Agent-driven workflows

While the human-in-the-loop system greatly accelerates metadata harmonization, it still requires active contributor participation in reviewing recommendations, accepting corrections, and resubmitting updates. For datasets involving hundreds or thousands of records, this human effort remains substantial. To reduce that burden and allow contributors to focus on research instead of repetitive metadata correction, the workflow can be extended through agent-driven automation.

In this model, a metadata agent operates as an autonomous or semi-autonomous system capable of analyzing, correcting, and validating metadata records. It uses both deterministic and nondeterministic reasoning systems, ranging from rule-based logic to Amazon Bedrock LLM inference, to identify, resolve, and resubmit corrected metadata. Through MCP, the agent can access a set of specialized tools, including the remote metadata processing service, schema validators, and embedding-based similarity modules. When invoked, the agent can trigger validation, retrieve failure reports and AI-generated recommendations, and decide how to apply corrections based on contextual cues.

Operational flow

The following process illustrates the agent-driven loop, mirroring the same structure as the human workflow but replacing direct user actions with autonomous reasoning.

Figure 3: Agent-driven operational flow

This configuration allows the system to scale metadata curation across large datasets with minimal human intervention while maintaining an auditable correction log.

Contextual awareness and organizational agents

For high-value or domain-specific data, a single general-purpose agent may lack the necessary context. To improve accuracy, organization-specific agents can be deployed, each with access to that group’s private data stores, experiment logs, and research publications. By embedding global context such as ontology usage, experimental methods, and internal naming conventions into the agent’s reasoning prompt, metadata correction becomes both more precise and more consistent with local data standards.

This architecture supports two levels of adaptation:

1. Local reasoning, where the agent infers missing or ambiguous fields using the immediate dataset and prior submissions.
2. Contextual enrichment, where the agent draws from broader organizational knowledge such as papers, protocols, and controlled vocabularies to validate and fill metadata fields automatically.

The following demonstration shows an agent executing this workflow in a terminal interface. The agent interacts programmatically with the metadata validation system, using MCP tools to validate a dataset, interpret errors, and autonomously apply corrections before resubmitting.

Terminal 1: Start the API server

# From the project root
make runApiLocal

Terminal 2: Run the agent

# Validation demo (runs a predefined workflow)
uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

Title: “Autonomous metadata validation through an agent” A 1 minute 38 second demo showing a ReAct-based agent performing end-to-end metadata correction using command line interactions.

Agent-driven workflows move metadata correction beyond human review cycles toward scalable, context-aware automation. By combining deterministic schema validation with LLM-based reasoning and controlled tool access, these agents reduce the repetitive workload on contributors while preserving transparency and accountability. The result is a system that adapts as data standards change and supports large-scale, multi-organization data sharing.

Governance and compliance considerations

Moving from proof-of-concept to production requires governance integrated throughout the development lifecycle. Four areas deserve particular attention.

Data Integrity and Change Tracking: Organizations should establish clear control frameworks for how metadata changes are documented and preserved. Scientific reproducibility depends on maintaining data provenance. As demonstrated in the human-in-the-loop workflow, the system provides change summaries categorized by type and source, supporting review and approval during metadata submission. Institutions should define retention policies, audit trail requirements, and integrity controls appropriate to their regulatory environment.

Architecture Governance: Organizations need to determine how AI recommendations integrate into their data workflows, specifically whether corrections require approval before being applied or can be applied automatically with post-hoc review. This decision affects data integrity, reversal capabilities, and alignment with institutional data policies. Architecture choices should be documented with clear rationale and designed to accommodate evolving standards and growing data volumes.

Responsible AI and Content Safety: Production deployments that use LLM inference should incorporate Amazon Bedrock Guardrails to establish boundaries on model behavior and protect against prompt injection attacks, particularly when metadata values from external sources are passed directly into model prompts. Guardrails can be configured to filter harmful content, enforce topic boundaries, and apply grounding validation. This keeps LLM-generated correction recommendations anchored to the schema definitions and controlled vocabularies defined for the workflow. For agent-driven deployments, Guardrails can also validate against each agent’s autonomous operation boundaries to help prevent unintended corrections from being applied without appropriate oversight.

Security: AI systems handling sensitive genomic data must meet the same security standards as traditional research data systems. Role-based access control, data protection throughout the validation pipeline, and (for agent-driven workflows) boundaries on autonomous operations should all be assessed against the organization’s risk profile.

Cleanup

To avoid ongoing charges, destroy all deployed AWS resources when you are done:

This tears down the AWS CDK stack, including Amazon ECS services, Amazon DynamoDB tables, Amazon S3 buckets, and the Amazon Cognito user pool. The command prompts for confirmation before proceeding.

If you set removalPolicy to "retain" in config.yaml (recommended for production), some resources will survive stack deletion. Delete retained Amazon S3 buckets and Amazon DynamoDB tables manually through the AWS Management Console or AWS CLI.

To remove local build artifacts:

Conclusion

The AI-powered metadata correction and harmonization system presented here addresses a persistent challenge in biomedical research: the time spent on data standardization instead of scientific work. The two implementation approaches, human-in-the-loop validation and agent-driven workflows, provide flexibility for organizations at different stages of AI adoption. Teams can begin with supervised corrections that build confidence in the system, then gradually transition to more automated approaches as trust grows.

This system helps reduce the friction that slows collaboration across organizations. The cloud-native architecture scales with your organization, and the modular design allows customization to meet specific institutional needs. As data volumes continue to grow, automated metadata harmonization becomes increasingly important as organizations scale. Check out our GitHub repo to get started with the solution.

---

About the authors

Joseph Cottingham

Joseph is a member of the AWS Generative AI Innovation Center, where he designs and delivers AI systems that move organizations from idea to production. His technical background spans firmware, software, and machine learning, with deep expertise in high-throughput, event-driven architectures that keep AI workloads performant at scale. Joseph focuses on the intersection of state-of-the-art research and operational reality, delivering solutions that materially transform organizations and the systems they operate.

Haley Tien

Haley is a Deep Learning Architect at the AWS Generative AI Innovation Center, where she designs and implements solutions spanning cloud architecture, data science, and generative AI. Her work focuses on building practical systems that address a wide range of customer challenges. She is passionate about finding creative ways to apply new technologies to long-standing problems.