DataHub says the column exists. PostgreSQL says it doesn’t.

01 The claim

A catalog can agree with itself—and still be wrong.

Catalog-only checks can expose contradictions inside metadata. They cannot detect a catalog that is internally consistent but no longer matches the source. Sidq crosses that boundary before an agent plans or writes.

BLOCK — on the context, before the agent plans against a column that no longer exists.

One context. Three independent comparisons.

• 5 claim types
• 6 catalog contradiction families
• 38 explicit policy rules
• 3 read-only MCP tools

The public claims run is the non-mutating live-source proof: DataHub prose becomes bounded SELECT-only SQL, and only returned row counts determine the verdict. The schema-rename demonstration remains in the local runbook because it deliberately changes PostgreSQL. Any missing comparison is reported as unverifiable, never clean.

285 contradictions.
In DataHub’s own showcase catalog.

A read-only audit found 285 instances of one contradiction family: stored lineage pointing to fields the destination datasets’ own schemas say do not exist — in showcase-ecommerce, the sample catalog DataHub itself ships. Here is one, whole.

Both statements live inside the catalog. No source system was consulted. They cannot both be true.

And the same read says who wrote them. Attributing each side to its ingestion run — one query parameter, no extra calls — shows that the run which wrote the lineage is the run that wrote the schema, in all five affected assets and every stored version: ten out of ten. So this is not two sources disagreeing; one writer produced both halves in the same run. A later run reproduced the shape exactly rather than repairing it, which is why the finding names a job to fix rather than a state to refresh. How that was measured ↗

That is one of six catalog-self-checks. Sidq also checks for protection markers lost across field lineage, documentation naming absent columns, orphan edges, deprecated assets feeding live BI, and consumed assets with no owner. A bounded or incomplete read is reported as unverifiable, not clean.

It also decides what to look at. The audit ranks every asset by how much damage a lie about it would do and spends its budget on the worst first — then lets what it finds change the order: an asset caught in a contradiction promotes its neighbours ahead of their static score, because contradictions cluster. Same catalog, same sequence every time; a different catalog, a different one.

285

internal contradictions

67

datasets examined

5

assets they cluster in

29

consumed assets with no owner

02 The gate

No LLM decides whether the agent may act.

Five evidence gates feed one deterministic policy. A model may propose a bounded read-only test; only returned evidence can move the verdict.

Same agent. Same goal. Same catalog.
Only one of them is allowed to check.

select region_id, count(cust_email)
from order_entry.customers
group by region_id

-- No SQL proposed.
--   not checked: schema_drift (no live source configured)
--   not checked: lineage_rot ×22 (no target-side column lineage)
--   not checked: constraint_reconciliation

Read that refusal precisely. Offline, the agent did not catch the catalog lying — it produced zero findings. It stopped because three checks could not run at all, and it names each one instead of dropping it. That is the exact substitution this project exists to refuse: “we did not check” is not “we checked and it passed.” Both transcripts ↗

• Adaptive auditor
• Sidq MCP
• Agent Skill
• CLI
• GitHub Action
• PR bot

03 The refusal

Column-level lineage, followed hop by hop from the changed field to the thing that breaks:

1. dbtorder_entry.customers / cust_email
2. Snowflakeanalytics.order_details
3. Lookerexplore.order_details
4. Dashboarddashboards.53owned by another team

The same refusal, on real pull requests.

Four public pull requests on this repository carry the PR bot’s own verdicts, each read against a live DataHub, not a fixture. Two pass, two are refused with the rules named. One sticky comment per PR, rewritten in place rather than repeated.

1. #1 harmless column ↗PASSno blocking or warning rule fired · verdict.json ↗
2. #2 remove cust_email ↗BLOCKEDpii_exposure · critical_downstream · verdict.json ↗
3. #3 stale catalog context ↗BLOCKEDunknown_field · catalog_reality_mismatch · verdict.json ↗
4. #4 compatible migration ↗PASSproven against the live graph, with a receipt · verdict.json ↗

04 The repair

Sidq rejects fixes that only move the failure.

A proposal is not a repair until the same deterministic engine re-runs against the catalog it would create.

05 The receipt

The next agent verifies for itself.

A receipt is not authority. A separate reader re-reads semantic metadata and complete one-hop lineage, then checks policy hash and age. Applicability, verdict, authorization, and coverage stay separate: a current BLOCK means “checked and refused” and still authorizes only STOP; absent, stale, or unreadable means RECHECK.

The verdict lands in DataHub’s own Quality tab.

Not a dashboard of Sidq's own. Each policy rule becomes a native DataHub Assertion through the documented custom-assertion API, reported by that rule's own severity, sitting beside the dataset's real owners and glossary terms — with sidq as the assertion platform.

One loop, through DataHub, end to end.

1. 1Readgraph context through the official DataHub MCP server.
2. 2Decideone deterministic policy returns PASS, WARN, or BLOCK. No model participates.
3. 3Writeeach rule mirrors into DataHub’s own Quality tab as a native Assertion; a Receipt is persisted through official MCP only when asked.
4. 4Read it backthe exact structured body, or the write stays write_unconfirmed.
5. 5Re-verifya separate process re-reads the current context and judges again. An asset nobody examined stays NOT VERIFIED.

A mutation acknowledgement is not success. Sidq trusts a Receipt only after a direct read returns its exact structured body; a mismatch remains write_unconfirmed and triggers bounded compensation instead of becoming trusted state.

How the decision is reached — one picture

Gates collect evidence. One engine decides. No model participates in a blocking decision. Open full size ↗ · ARCHITECTURE.md ↗

06 The swarm

Four agents. No coordinator.
DataHub is the shared state.

Four concurrent auditors coordinate only through DataHub-native receipts—no IPC, message bus, lock service, or shared filesystem. Kill one mid-run; the others keep working, because nothing was ever assigned to it. A fifth, independent process reconstructs the ledger from DataHub alone.

The same receipts are also how Sidq remembers across time. An audit runs on a bounded budget, so a catalog larger than one budget used to re-examine its worst assets forever and defer the tail forever. sidq audit --resume re-reads the receipts earlier runs wrote back, re-derives whether each still holds under the current policy hash, and spends the budget on assets no run has reached — so repeated runs converge on coverage instead of circling. The memory lives in the catalog, not in a file beside the agent.

Recorded, not runnable here — and that is the point. Every proof button on this page runs a command that cannot write to a catalog. The swarm coordinates by writing, so it can never be one of them; a read-only swarm would demonstrate nothing. This is the verbatim output of make swarm-demo against a DataHub OSS v1.5.0.6 quickstart, run swarm-1786323944. Run it yourself with the five-command runbook.

• 4 workers
• 1 killed mid-run
• 14 distinct assets in 18 examinations
• 9 Receipts read by a process that examined nothing

== four workers start together — no coordinator, no IPC ==

Swarm worker alpha
  examined          6
  receipts written  6
  vouched by peers  1 (beta) — their receipts held, so this worker moved on
Swarm worker beta
  examined          6
  receipts written  5
  vouched by peers  1 (alpha) — their receipts held, so this worker moved on
  write failures    1
Swarm worker gamma
  examined          6
  receipts written  3
  vouched by peers  4 (alpha, beta) — their receipts held, so this worker moved on

  >> killed delta mid-run — its unfinished assets were never assigned to it

== overlap, from the surviving workers' own reports ==
  worker reports found     3 of 4 expected
  total examinations       18
  distinct assets examined 14
  duplicated examinations  4

== the ledger, read from DataHub by a process that audited nothing ==
  current valid receipts   9 of 50
  alpha 4 · beta 2 · gamma 3

The overlap and ledger answer different questions. Each worker records a digest for every examination; when two workers touch the same asset, Sidq checks whether their independent conclusions agree and surfaces divergence without choosing a winner. That overlap comes from worker reports — DataHub stores only the latest receipt and cannot count collisions after the fact. The ledger comes from a fifth process that trusts no worker and reads current receipts from DataHub alone. The first measurement of this run failed, at 6 distinct assets of 18 examinations, and two defects were found and fixed because the number existed.