Archon for DataHub

An evidence-first agent that audits your DataHub catalog against itself: it finds where two sources disagree, traces what breaks downstream, and hands a steward one exact governed fix.

Comment

Track: Agents That Do Real Work

Proof strip: 1 live OSS DataHub Core · 4 evidence-linked findings on a live catalog, 5 in the fixture preview · 1 governed fix · verified read-back and rollback · upstream PR #183

The wedge: other agents trust the catalog. Archon proves the catalog can be trusted before allowing one reversible action.

Judge shortcuts: run the live audit · watch the exact-release 2:41 demo · follow the judge route · inspect sample outputs · verify the exact release · review upstream PR #183

Real DataHub write-back: live MCP reads power the public audit. Protected CI performs a human-approved add_tags, verifies read-back, requires a separate rollback approval and verifies exact restoration. The anonymous app never receives a write credential.

Inspiration

A data catalog is where an organisation agrees on what its data means. The problem is that it can quietly stop agreeing with itself: two ingestion sources declare different owners, lineage references an asset that no longer exists, or a sensitive field has no classification. Every individual record can look valid while the catalog as a whole tells conflicting stories.

Most assistants make metadata easier to retrieve. We asked a harder question: is the context internally consistent, what is actually exposed when it is not, and can one safe correction be made without giving an agent open-ended authority?

What it does

Archon runs a bounded evidence, reason and propose loop over DataHub.

  • Cross-source contradictions: it reconciles current metadata with retained aspect history and ingestion-registry provenance, so it can recover a disagreement even when DataHub's pipelineName field remains sticky across runs.
  • Lineage gaps and blast radius: it checks declared upstreams against the resolved graph and expands a missing asset into a bounded, cycle-safe downstream impact path.
  • Governance controls G1–G6: deterministic checks cover ownership, domain, documentation, typing and classification. Unknown evidence stays unknown; an unrelated tag cannot satisfy G6.
  • Portable evidence: JSON, Markdown and SARIF exports carry provenance and content digests, so a platform team can review a catalog finding in an existing code-scanning workflow.
  • One governed action: only an unclassified sensitive field can become a typed add_tags plan. The anonymous app cannot write. Protected CI binds a human approval to the exact plan, verifies read-after-write, requires a separate rollback approval and verifies restoration.

The public demo is not a mock. One click executes a read-only audit against a private DataHub Core 1.6 catalog and returns four live findings: G6, a retained-history owner contradiction, G2 and a dangling lineage edge. A visibly labelled deterministic preview keeps the story available if the live dependency is temporarily unavailable.

How we built it

The core is TypeScript with deterministic domain rules and narrow ports. React, Tailwind and Vite provide the steward interface. Firebase serves the immutable SPA; a scale-to-zero, maximum-one Cloud Run adapter exposes only health, readiness and one allowlisted read audit to a private DataHub Core host. No Kubernetes or EKS is required.

All four DataHub agent components have separate responsibilities:

Component Material use
DataHub MCP Server bounded live search/entity/schema/lineage/quality reads and the protected exact tag mutation; retained history uses bounded direct GMS until upstream PR #183 lands
Agent Context Kit provenance-bearing context envelope with explicit unknown preservation
DataHub Skills pinned search → lineage → quality → audit → enrich workflow with receipts
Analytics Agent grounded SQL/chart trace, context-quality output and proposal-only context improvement

Upstream review. A DataHub maintainer reviewed PR #183 and asked for four changes: reuse the OpenAPI client seam instead of hand-rolled transport, reshape the tool to batch over a cross-product of URNs and aspects, gate it behind a minimum server version, and document the retention bound. All four are in the current head. The review and our reply are public on the pull request. It is not merged yet.

Security and quality evidence is pipeline-only: unit, integration, functional, authorization, prompt-injection, component and Playwright user-journey tests; measured combined coverage ≥85%; Gitleaks, CodeQL, dependency review, npm/Python SCA, OpenVEX, CycloneDX SBOM, container and IaC scans; and strict OWASP ZAP DAST against the final Firebase origin. The final application release, hosted proof, governed receipts and public 2:41 demo are bound to exact deployed SHA 7cf2ab063312c2bf06fd2d65c798e802f7070a37. The video's CI receipt verifies duration, dimensions, scene count and SHA-256.

Challenges we ran into

Our first live integration failed even though the fixture suite was green. Search incorrectly assumed DataHub's count was the number of returned results, entity reads missed an official response shape, and the headline contradiction could not fire because retained versions carried the first ingestion source's sticky pipelineName.

Running against DataHub Core revealed the better source of truth: the ingestion registry maps each aspect run ID to its actual ingestion source. Archon now prefers that provenance and fails closed when identity cannot be resolved. Contract tests are pinned to observed live response shapes rather than convenient assumptions.

The governed proof also exposed two transport-lifecycle defects: successful read and write stdio MCP children could outlive a bounded CI action. Both adapters now release authority explicitly; the mutation transport is deliberately one-shot.

Accomplishments we are proud of

  • A no-login judge can run a real DataHub audit and inspect evidence-linked findings.
  • Public reads and privileged writes have different code paths, identities and authority.
  • The G6 correction is content-bound, human-approved, read-back verified and separately reversible rather than an autonomous catalog-admin tool.
  • We contributed the missing bounded read-only get_aspect_history capability upstream in acryldata/mcp-server-datahub#183. The PR is openly represented as under review, not as accepted.
  • The active hosted design costs only the temporary DataHub demo host plus bounded serverless use, rather than an always-on Kubernetes estate.

What we learned

A passing suite is not evidence that an integration works when tests encode an assumption about someone else's API. Provenance is also a product feature, not an implementation detail: the catalog's operational registry was more trustworthy than the field that appeared designed to name a source. Finally, human approval is meaningful only when it is bound to exact content, identity, state and an independently verified recovery path.

What is next

Customer-specific SLOs, authenticated edge controls and backup/restore rehearsals come before a production claim. After that, the same narrow engine can schedule posture reports and add new remediation actions one at a time, each with its own policy, evidence and rollback contract.

Built With

Share this project:

Updates