Inspiration

Regulatory changes rarely affect only one rule. A threshold or rate may flow through source registries, transformation logic, projections, decision-support products, and user-facing reports. In many organizations, understanding that impact is still a manual search across code, documentation, and individual knowledge.

TaxGraph Sentinel was inspired by a simple question: what if an agent could use the metadata graph as reliable context, find every downstream dependency, and help a human take safe, auditable action without inventing assets or silently changing the catalog?

What it does

TaxGraph Sentinel is a metadata-driven regulatory-impact agent built on DataHub Open Source and the official DataHub MCP Server.

It:

• loads one of three synthetic regulatory-change scenarios;
• searches DataHub through the official MCP Server;
• accepts only entity URNs actually returned by DataHub;
• retrieves metadata and verifies expected schema fields;
• traverses downstream lineage up to ten hops;
• produces a structured impact report with a plain-language explanation, risk level, recommended actions, and raw MCP evidence;
• requires explicit human confirmation before write-back;
• adds a regulatory-impact tag and an impact notice to affected assets;
• saves a persistent DataHub Analysis document linked to those assets;
• re-reads the affected entities to verify every modification.

All tax rules and assets are synthetic demonstration data. TaxGraph Sentinel does not ingest live legislation and does not provide tax or legal advice.

How we built it

We created a seven-asset synthetic graph in DataHub Core v1.6.0 with six lineage links, from regulatory sources to a user-facing taxpayer report.

A deterministic Python orchestrator starts the official DataHub MCP Server v0.6.0 over stdio through FastMCP. The read-only phase calls search, get_entities, list_schema_fields, and get_lineage. The analyzer validates the selected source URN, checks schema evidence, extracts the downstream graph, and produces auditable JSON output.

The write phase is intentionally separate. Only after a human confirms the plan does the application enable mutation tools and call add_tags, update_description, and save_document. It then calls get_entities again to verify the results.

Streamlit provides the review and approval interface, while automated tests cover scenario validation, URN and schema extraction, cancellation safety, mutation order, and live DataHub MCP integration.

Challenges

The main challenge was making the workflow demonstrably real without allowing the agent to invent metadata. Search responses can be nested, lineage results can contain multiple URNs, and mutation tools must never be available during read-only analysis.

We therefore made DataHub-returned URNs the trust boundary, separated MCP read and write sessions, and recorded raw tool evidence in every report.

A second challenge was preventing accidental duplicate write-backs in a local prototype. The Streamlit workflow records a local scenario marker and disables a second write-back for the same scenario.

Accomplishments that we're proud of

• A working end-to-end DataHub workflow, not a slide-only concept.
• Real MCP calls for search, metadata, schema, lineage, mutation, and verification.
• Seven synthetic assets and six lineage links that clearly demonstrate impact propagation.
• An explicit human-in-the-loop boundary before every mutation.
• Persistent knowledge written back to DataHub for the next person or agent.
• JSON and Markdown sample outputs that judges can inspect without running the stack.
• A reproducible Windows launcher with pinned dependencies and automated tests.

What we learned

Agent reliability depends less on fluent output than on trustworthy context and clear action boundaries.

DataHub lineage makes impact analysis useful, while MCP makes each read and mutation explicit and auditable. We also learned that a small deterministic orchestration layer is valuable for safety-critical steps: an agent must not invent URNs, bypass human approval, or claim that a mutation succeeded without a positive tool response.

What's next

• Add a constrained model-based explanation layer grounded only in MCP evidence.
• Ingest and version real regulatory publications with legal review.
• Add stable DataHub document identifiers for cross-device idempotence.
• Notify asset owners and route approvals by domain.
• Add structured impact properties, release gates, and regression-test generation.
• Extend the workflow to privacy, accounting, and financial-reporting changes.
• Deploy a secured multi-user architecture instead of the local demonstration stack.

Built With

• datahub
• datahubmcpserver
• docker
• fastmcp
• powershell
• pytest
• python
• streamlit