ARIADNE
ARIADNE
That is not a compliment paid to a sponsor, it is the architecture. Every claim Ariadne makes is a claim about the DataHub graph, read through DataHub's own agent surfaces and written back through DataHub's own APIs. Point it at an instance with the lineage removed and every check returns nothing at all, because there is nothing else for it to read.
Nothing in the lineage was hand emitted. Three of the seven judges built these connectors, so a graph written by hand would be spotted immediately and would prove nothing anyway.
The same traversal runs twice: once through the Agent Context Kit in process, once through the official MCP server as a child process over stdio. They share no code path inside Ariadne.
If the answers came from anywhere other than the catalog, the two would drift. They do not. That is the check, and it runs live.
python tools/agree.py
== do the two DataHub surfaces agree ==
kit datahub-agent-context, in process
mcp datahub 3.4.5 over stdio, 6 tools
agree 7 nodes upstream of workforce_features on public_coverage_flag
agree 7 nodes downstream of workforce_features
agree 5 nodes upstream of dim_person on disability_code
3/3 walks identical through both| surface | what Ariadne does with it | what it returned |
|---|---|---|
| Context graph | Column level traversal, both directions, across dbt, postgres and mlflow siblings | 7 hops, raw column to deployed model |
| MCP server | The official server as a child process over stdio, tools discovered at the handshake | 6 tools discovered |
| Agent Context Kit | The runtime both agents run on, over either transport | in process, 3 of 3 walks agree with MCP |
| DataHub Skills | Registry installed, plus an ML impact skill contributed back | datahub-skills#66, 4 failure modes encoded |
| Incidents API | Findings filed on the entity they concern, regime named in the title | 12 open on income_features alone |
| Ingestion sources | postgres, dbt and mlflow recipes, run in a specific order | 3 connectors, no hand emitted edges |
| Analytics Agent | Its context patterns, for the query half that computes the figure | pattern adopted, app not embedded |
Each one fails silently, which is why they were worth writing up rather than working around quietly. A loud failure teaches you something the first time. These teach you nothing until much later.
| what | why it matters | where |
|---|---|---|
The self-hosted MCP server stalls before answering initialize |
Its usage ping is sent before the handshake, so on a restricted host the client sees no error and no response at all | datahub#18684 |
| Incident support is decided in three places that disagree | Ten entity types accept a write, seven carry the summary aspect, five can be read back. The docs said "dataset, dashboard, chart, dataFlow, etc" and that "etc" is not open ended. It is why findings are filed on the feature table rather than the model | datahub#18685 |
| A finding about a model has nowhere correct to live | It lands on a dataset that is not the thing that broke. Scoped by a DataHub maintainer after two other contributors reproduced it, and I am implementing the fix for mlModel and mlFeature |
datahub#18999 |
| An ML impact skill for the registry | The existing five do not cover whether a warehouse change reaches something that is serving | datahub-skills#66 |
| The Agent Context Kit cannot import its own registration module | It fails against the dependency version it pins, so the LangChain path breaks on a clean install | datahub#18686 |
Every number here can be checked against the instance it came from.