-
-
Sibling Asset Reconciliation
-
Conflicts Preserved as Evidence for reference
-
Recommendation + Human Approval
-
Architecture & Human-Governance Loop of TrustGate
Inspiration
Before starting my current Master’s in Business Analytics at the University of Rochester, I worked with PwC India’s Central Markets team, where I supported leadership-facing proposals, presentations, and decision-making. A recurring challenge was that the underlying business data often came from multiple systems and was not always consistent. Dates could be outdated, revenue figures could conflict across sources, ownership information could be unclear, and important context sometimes lived outside the dataset itself. Before those numbers could be used in leadership decks, I had to rely on analytics teams to manually investigate which source was reliable, and explain what could or could not be trusted. That experience stayed with me. The hackathon prompt gave me the opportunity to bring together concepts I’ve been learning through my Master’s program and through self-learning, and apply them to a problem I had experienced firsthand. To maximize my learning, I chose to take this project on solo. I wanted to understand the entire workflow end to end myself, from setting up DataHub and working with MCP, to designing the governance logic, building the remediation loop, testing it, and presenting it clearly. That became TrustGate.
What it does
TrustGate is a purpose-aware governance agent for DataHub. It reads metadata from DataHub through MCP, reconciles multiple representations of the same logical asset into a canonical profile, preserves conflicting and missing evidence, and evaluates whether the asset is fit for a specific purpose. In the current demo, TrustGate evaluates whether order_history is suitable for production_ml. The dbt representation states that the asset does not contain PII, while DataHub also carries a PII glossary classification. Rather than guessing which source is correct, TrustGate identifies this as a blocking contradiction. It then separates the assessment into confirmed facts, conditional findings, missing evidence, remediation recommendations, evidence coverage, and confidence. For the blocking PII conflict, TrustGate recommends aligning the dbt property with the confirmed DataHub classification. But the agent does not make that change automatically. I believe intelligent automation is most useful when it introduces human intervention at the right point, rather than simply removing people from the process. TrustGate therefore requires explicit approval before a governance mutation is written back to DataHub. After approval, TrustGate writes the change, re-fetches the metadata, rebuilds the canonical profile, and reassesses the asset. In the demonstrated workflow, the result moves from blocked to 'approved_with_conditions' , while unresolved issues remain visible.
How I built it
TrustGate is built in Python around DataHub OSS.
The live workflow uses the DataHub MCP Server to investigate metadata including schema, glossary terms, structured properties, sibling relationships, and lineage. The core pipeline is: DataHub → MCP investigation → canonical reconciliation → purpose-aware policy evaluation → remediation recommendation → human approval → DataHub writeback → re-fetch → reassessment The governance logic is intentionally deterministic and auditable. Confirmed evidence, missing evidence, assumptions, and conflicts are kept separate rather than being collapsed into a single opaque score. The project also produces JSON and Markdown assessment artifacts so the reasoning and evidence can be inspected independently of the interface.
Challenges I ran into
The biggest challenge was handling data preparation when the same logical asset had conflicting metadata across sources. Instead of choosing one source and moving on, I had to preserve discrepancies, separate confirmed facts from missing evidence, and build a canonical view that could actually support a decision. There was also a steep learning curve in connecting DataHub, MCP, writeback, and the approval loop, but that made the project especially valuable because it showed me how much of good automation depends on preparing and contextualizing the data correctly before acting on it.
Accomplishments that I am proud of
What I am most proud of is not just that TrustGate works, but how much I learned while building it. I started this hackathon relatively new to MCP-based development and to building this kind of agentic workflow end to end. A lot of the stack initially felt intimidating — DataHub OSS, Docker, MCP, writeback, metadata reconciliation, testing, and the approval loop — but working through it hands-on made those concepts feel much more approachable. By the end, TrustGate was able to complete the full governance loop rather than stopping at detection. It can investigate real DataHub metadata, reconcile sibling assets, make a purpose-specific decision, recommend remediation, require human approval, write an approved change back, and then re-fetch and reassess the updated state. The demonstrated flow moves through: blocked → human-approved remediation → DataHub writeback → re-fetch → approved_with_conditions I am also proud that I pushed myself beyond building only a prototype interface. The project includes a tested Python implementation, live DataHub/MCP integration, before-and-after assessment artifacts, writeback logic, human-controlled remediation, and reproducibility documentation. The final test suite passes: 41 passed, 1 SDK warning More than anything, this hackathon gave me a new way of thinking about data governance and agentic workflows. It made technologies that initially felt unfamiliar much less intimidating, and it left me genuinely excited to keep building with them.
What I learned
This project changed how I think about data quality and governance.
The challenge is not always that data is missing. Often, the harder problem is that multiple sources contain plausible but conflicting versions of the truth. I also learned that agentic workflows become more useful when they are designed around evidence, accountability, and appropriate human intervention. An agent does not need unlimited autonomy to create value. In governance workflows, knowing when to stop and ask for approval can be just as important as knowing what action to recommend. On a technical level, I learned a significant amount about DataHub, MCP, Dockerized infrastructure, Python packaging, metadata reconciliation, testing, and the mechanics of building an agent that does more than just generate an answer.
What's next for TrustGate :
In the current implementation, I intentionally focus on one purpose, production_ml, and one deeply demonstrated remediation flow. The next step would be to expand the policy layer to support additional purposes such as customer analytics, external reporting, and GenAI workloads. I would also like to extend TrustGate to support more remediation types, richer policy configuration, organization-specific governance rules, and broader evidence sources while preserving the same core principle: reconcile the evidence, explain the decision, and keep humans in control of consequential actions.
Log in or sign up for Devpost to join the conversation.