DataGuardian-AI

An autonomous AI agent for DataHub that monitors metadata, detects governance and lineage issues, explains downstream impact, and recommends or performs corrective actions.

Comment

🛡️ DataGuardian AI

Autonomous Metadata Governance Engineer for DataHub

Modern organizations manage thousands of datasets across analytics, applications, pipelines, dashboards, and machine-learning systems.

DataHub gives organizations visibility into that metadata. But visibility alone does not answer the harder questions:

  • Which datasets are actually risky?
  • Why are they risky?
  • Who owns them?
  • What downstream systems could be affected?
  • Which governance checks should run for a particular question?
  • Can an AI explain its conclusions without inventing evidence?

That is the problem we wanted to solve.

💡 Inspiration

We were inspired by a simple observation:

Data teams don't just need another chatbot. They need an engineer that can investigate their metadata.

Traditional metadata platforms are excellent at cataloguing data, but governance teams can still spend significant time manually searching catalogues, checking ownership, examining documentation, tracing lineage, and determining which issues deserve attention first.

At the same time, simply asking an LLM to "find risky datasets" creates another problem: AI can produce convincing answers that are not actually supported by the catalogue.

For governance, that is unacceptable.

So we designed DataGuardian AI around a different principle:

DataHub provides the evidence. Deterministic rules decide what is wrong. AI explains why it matters.

🚀 What is DataGuardian AI?

DataGuardian AI is an autonomous metadata governance engineer built on top of DataHub.

It connects directly to DataHub metadata, investigates governance issues, evaluates deterministic risk rules, analyzes lineage impact, and generates actionable explanations and documentation.

Instead of returning only an AI-generated answer, DataGuardian exposes the investigation itself.

The system can show:

Question → Plan → Tools → DataHub Evidence → Rule Evaluation → Risk → Impact → Recommendation

This makes the system understandable, auditable, and reproducible.

🧠 What makes it different?

The most important design decision is the separation between deterministic governance logic and generative AI.

Deterministic layer

The rule engine evaluates the actual metadata.

For example:

  • Missing owner
  • Missing description
  • Classification gaps
  • Metadata coverage problems
  • Governance violations
  • Risk contributions

Every finding has an explicit rule and point contribution.

The final score is calculated from those findings rather than being invented by an LLM.

Generative layer

The LLM is used where language models are strongest:

  • Understanding natural-language questions
  • Selecting investigation paths
  • Explaining findings
  • Summarizing evidence
  • Generating documentation
  • Communicating business impact

This creates a strong separation:

The AI explains the evidence. It does not manufacture the evidence.

🔌 DataHub Integration

DataHub is the foundation of DataGuardian AI.

The application connects to a running DataHub instance through its metadata APIs and retrieves catalogue information such as:

  • Datasets
  • Owners
  • Domains
  • Platforms
  • Descriptions
  • Tags
  • Schema metadata
  • Lineage
  • Governance-related metadata

The DataHub page inside DataGuardian makes this integration visible instead of hiding it behind the backend.

It shows:

  • DataHub connection status
  • GMS version
  • Response latency
  • Dataset counts
  • Owner counts
  • Domain counts
  • Platform counts
  • Metadata coverage
  • GraphQL documents used by the integration

This allows a judge or data-platform engineer to immediately see that the application is actually using DataHub as its metadata source.

🤖 Autonomous AI Investigator

DataGuardian includes an AI Investigator that allows users to ask questions such as:

"Which datasets have no owners?"

"Which datasets are highest risk?"

"Explain the downstream impact."

"Find untagged PII."

"Generate documentation for this dataset."

Instead of treating every question the same way, the agent determines which investigation tools are actually required.

For example:

Missing owners

→ Ownership tool
→ DataHub evidence
→ Deterministic findings
→ Explanation

while:

Highest-risk datasets

→ Governance metadata
→ Risk engine
→ Evidence aggregation
→ Risk explanation

The execution path changes depending on the question.

That is what makes DataGuardian an agentic system rather than a traditional chatbot.

🔍 Judge Demo

To make the agent behavior immediately understandable, DataGuardian includes a dedicated Judge Demo.

With one click, the system executes a sequence of real agent investigations without requiring the judge to type anything.

The demo deliberately exercises different planner branches.

The execution timeline shows:

  • Which stage ran
  • Which tool was selected
  • Which stages were skipped
  • Which evidence sources were required
  • Where deterministic rules were applied
  • Where the language model was used

This makes the agent's behavior observable instead of hiding everything behind a final answer.

⚖️ Explainable Risk Engine

Governance risk should never be a black box.

DataGuardian therefore calculates risk using deterministic rules.

Each finding contains:

  • The affected asset
  • The violated rule
  • The point contribution
  • The metadata evidence
  • The resulting consequence

For example, a dataset can accumulate several rule violations:

40 + 30 + 20 + 20 = 110

The risk engine caps the final score at:

100 → CRITICAL

The frontend exposes this arithmetic directly.

This means a user can inspect a finding and understand exactly why the dataset received its severity.

The risk calculation is also cross-checked between the backend Python engine and the frontend TypeScript implementation.

Same evidence → same rules → same score.

📊 Governance Dashboard

The Governance view provides an operational overview of the catalogue.

Users can inspect assets by:

  • Risk
  • Metadata health
  • Documentation
  • Ownership
  • Coverage
  • Lineage
  • Tags

Assets can be filtered and searched to quickly identify the areas requiring attention.

Instead of asking a governance engineer to manually inspect hundreds of catalogue entries, DataGuardian turns the metadata into a prioritized investigation surface.

🕸️ Lineage Explorer

A governance problem rarely ends with one dataset.

A poorly governed dataset can feed:

Source → Dataset → Transformation → Dashboard → ML Model

DataGuardian's Lineage Explorer makes this impact visible.

Users can trace relationships between datasets, pipelines, dashboards, and machine-learning assets.

This helps answer a critical governance question:

"If this dataset has a problem, what else could be affected?"

The system combines DataHub lineage evidence with governance findings to provide context around downstream impact.

📝 AI-Powered Documentation

Metadata quality is not only about finding problems.

DataGuardian can also help improve understanding of the catalogue.

The Documentation workspace can generate:

  • Dataset READMEs
  • Data dictionaries
  • Dataset documentation
  • Business glossary explanations
  • SQL explanations

The generated content is grounded in catalogue metadata rather than being presented as unsupported facts.

For example, a dataset README can explain:

  • Purpose
  • Grain
  • Refresh cadence
  • Important fields
  • Caveats
  • Business context

Human review remains part of the workflow before generated documentation becomes authoritative.

🧪 Evidence Completeness

We deliberately avoided inventing an AI "confidence score."

Instead, DataGuardian reports Evidence Completeness.

For every investigation, evidence sources can be classified as:

  • Collected
  • Not required
  • Unavailable

This distinction matters.

If lineage was not needed for a question, it is not treated as a failure.

If lineage was required but DataHub was unavailable, that is explicitly reported as unavailable.

This gives users a more honest view of what the agent actually knew when making its assessment.

🏗️ Architecture

The system is built as a layered architecture:

React + TypeScript

↓

FastAPI Backend

↓

LangGraph Agent

↓

Investigation Tools

↓

Deterministic Risk Engine

↓

DataHub GraphQL Metadata

The LLM does not directly control DataHub or determine governance scores.

Instead, the agent operates through controlled tools and evidence collection.

This architectural boundary is intentional:

The language model can reason about evidence, but deterministic governance logic remains the source of truth for risk.

🔐 Responsible AI Design

DataGuardian is designed around an important governance principle:

Never invent a finding.

The system distinguishes between:

Observed evidence

and

AI-generated explanation.

The risk engine operates on structured metadata.

The LLM receives metadata context rather than raw business data.

This makes the system suitable for metadata governance workflows where trust, reproducibility, and explainability matter more than generating an impressive-sounding answer.

🛠️ Technology Stack

Frontend

  • React
  • TypeScript
  • Vite
  • Tailwind CSS
  • React Flow
  • Recharts

Backend

  • Python
  • FastAPI
  • Pydantic
  • GraphQL

AI / Agent

  • LangGraph
  • Groq
  • Gemini

Metadata

  • DataHub

Infrastructure

  • Docker
  • Render-compatible production configuration

🧩 Challenges We Faced

One of the biggest challenges was making the DataHub integration reliable enough for real investigations.

DataHub metadata can be incomplete, and individual evidence sources can fail independently.

We therefore designed the system to degrade honestly.

For example, if DataHub cannot provide a particular evidence source, DataGuardian does not silently replace it with invented information.

The investigation records that the evidence was unavailable.

Another challenge was keeping the risk engine reproducible while still using AI.

The solution was to keep governance scoring deterministic and use the LLM for planning, explanation, and communication.

We also had to make the agent's behavior visible.

Instead of hiding tool selection inside the backend, we built the Execution Timeline so users can see how the investigation actually happened.

🧪 Testing & Verification

The project was continuously verified during development.

The final verification included:

  • 293 backend tests
  • Ruff
  • Mypy
  • TypeScript type checking
  • Oxlint
  • Production frontend build
  • DataHub integration verification
  • Risk-engine reconciliation
  • Production configuration testing

The deterministic risk calculation was cross-checked between the backend and frontend implementation to ensure that the same findings produce the same final severity.

🏆 Why This Matters

Data governance teams need more than dashboards.

They need to know:

What is wrong?

Why is it wrong?

How serious is it?

What evidence supports that conclusion?

What could be affected?

What should we investigate next?

DataGuardian AI brings those questions into a single investigation workflow.

Instead of turning metadata into another static dashboard, we turn it into an active governance investigation.

🎯 What We Are Proud Of

The feature we are most proud of is the Execution Timeline.

Most AI applications show:

Question → AI Answer

DataGuardian shows:

Question → Agent Plan → Tool Selection → Evidence → Deterministic Rules → Risk → Explanation

That difference makes the system much easier to trust and audit.

We are also proud that the system does not need to pretend that AI knows everything.

When evidence is unavailable, it says so.

When a stage is not required, it says so.

When a risk score is calculated, the arithmetic can be inspected.

🚀 What's Next

DataGuardian AI is currently focused on investigation and human-reviewed governance workflows.

Future directions include:

  • Persistent governance scan history
  • Trend analysis across scans
  • Scheduled metadata scans
  • Human-approved remediation workflows
  • Governance issue tracking
  • More DataHub entity types
  • Enterprise authentication and authorization
  • Expanded governance policies
  • Additional metadata platforms

The long-term goal is to evolve DataGuardian from an investigation assistant into a continuously operating metadata governance engineer.

🌐 Try DataGuardian AI

GitHub:
https://github.com/anjaneyulu-01/DataGuardian-AI

LIve Link: https://dataguardian-ai-8hne.onrender.com/

Video Link: https://youtu.be/CCHPhKyGT6c

Explore the repository, run the application locally, connect it to DataHub, and watch the agent investigate the catalogue.

Final Thought

DataHub provides the evidence.

DataGuardian investigates it.

Deterministic rules make the decision.

AI explains it.

Governance teams act on it.

DataGuardian AI — turning metadata into actionable governance intelligence.

Built With

Share this project:

Updates