Paracelsus

The problem

A wall of red is the same as no alerts at all

Point a modern data-quality tool at a catalog and it will find hundreds of things wrong. It ranks them by severity multiplied by the number of things downstream — often called blast radius. Everything important-looking floats to the top, all of it marked critical, all of it equally loud.

Teams stop reading. That is not a side effect of the design; it is the design. A ranking where the top forty items are indistinguishable has not prioritised anything.

The missing distinction is old and well understood outside software. Hazard is not risk. A hazard is what a thing can do in principle. Risk is what it can do to whoever is actually exposed to it, in the amount they are actually exposed to. Toxicology has separated these two since the sixteenth century, which is where this project takes its name and its method.

The method

Four factors, multiplied, every one of them sourced

Paracelsus scores each finding the way a regulatory risk assessment scores an exposure. The score is computed in plain Python, deterministically. No number in the output comes from a language model.

H

Hazard. How bad this class of break is in principle, scaled by dose — the share of the asset's columns the defect actually touches. A change to two columns of nine is a different dose from seven of twenty-two, even when the defect class is identical. source · schema comparison against a recorded baseline

E

Exposure. Not how many things sit downstream, but how much they are actually used. Each successor contributes according to its own query volume over the last thirty days, decaying with each additional hop. A successor nobody queries contributes almost nothing, no matter how many further things hang off it. source · lineage traversal + usage statistics

R

Receptor sensitivity. What kind of consumer is on the other end. A production model or a customer-facing report is a sensitive receptor; a scratch table is not. source · tags, domains, platform of the consuming asset

UF

Uncertainty. The counterintuitive one. Where evidence is missing, the score goes up. No column-level lineage adds 3. No usage data at all adds 3, because unused and unmeasured are not the same thing and we cannot tell them apart. Stale metadata adds 2. source · absence of metadata, not presence

The postgres table has twenty-four downstream assets. A blast-radius ranker puts it second in the entire catalog on that count alone. Almost none of those successors are queried, so its real exposure is 0.89 against the Snowflake table's 5.34.

And note which way uncertainty ran. The postgres table scored double the uncertainty surcharge, because we have neither column-level lineage nor any usage data for it. We raised its score twice for missing evidence — and it still does not need action, because nothing is drinking from it. That is the dose making the poison.

The action threshold is not a tuned number. It is derived from a written reference case — a confirmed defect of at least moderate class, touching a non-trivial share of an asset, reaching a sensitive receptor, with one uncertainty factor triggered — which computes to 67.5. Critical is twice that.

The whole catalog

Twenty-two of twenty-seven findings score exactly zero

Run against DataHub's showcase-ecommerce catalog, the naive detector raises alerts on twenty-six assets. Paracelsus scores twenty-seven and returns this:

The two assets a naive ranker puts first and second land fourth and third. The asset it ranks fifteenth is the one that matters most.

Those twenty-two zeros are the point, not a gap. Nothing has actually changed on them — they carry static schema properties that a hazard ranker reports as defects. The correct answer to a healthy catalog is silence, and silence is exactly what a severity ranker cannot produce.

What it does with the answer

The judgment goes back into the graph

An assessment that lives in a dashboard dies there. Paracelsus writes each result back into DataHub through its MCP server, so the next person and the next agent inherit the reasoning rather than the alarm:

• Five structured properties per asset — paracelsus.risk, .hazard, .exposure, .receptor, .uncertainty
• A risk-band tag, so the band is filterable in DataHub's own search
• A written assessment attached to the asset, in plain language, naming every factor and where it came from

Every write is read back and verified, because the API can report success on a write that silently did nothing.

The agent orchestrates the tool calls against DataHub. It is deliberately forbidden from producing any number — every figure comes from the deterministic engine, and the model only puts them into sentences.

Running it

One machine, one catalog, no account anywhere

The repository brings up its own DataHub, loads a real catalog, and runs end to end. There is no hosted instance to depend on and nothing to sign up for.

1. make preflightChecks Docker, Python 3.11, the DataHub CLI and uv. Names anything missing instead of failing later with an unrelated error.
2. make venvCreates the project's own environment.
3. make upStarts DataHub with token auth on, loads the showcase catalog, imports usage statistics, mints an access token.
4. make statusVerifies the catalog actually finished indexing and the metadata the model needs is readable.
5. make riskDetect, expose, assess. Produces the assessment for every finding.
6. make writeWrites properties, tags and assessments back into DataHub, then reads them back to confirm.
7. make boardServes the triage board: naive ranking against real ranking, with the factor breakdown behind every score.

Honest boundaries

What is measured, and what is staged

Real: the catalog, its lineage, its column-level lineage with confidence scores, its usage statistics, its tags and domains. Every exposure figure, receptor classification and uncertainty surcharge is computed from metadata that shipped with the catalog.

Staged: the schema changes themselves. A static demonstration catalog contains no incidents — nothing has broken, nothing has drifted. Five changes were planted across it so there is something to triage, on assets chosen by a rule written down before any score was computed, and disclosed in the repository, on the board and in the write-up.

The distinction that matters: what is staged is the defect. What separates the scores is not. The seed decides that something broke. The catalog decides whether it matters.

Known limits

• Receptor sensitivity does not vary on this catalog. No asset carries a finance, customer-facing or production-model signal, so that factor sits at its default almost everywhere and exposure is the axis doing the demonstrable work. The factor is implemented and dormant, not faked.
• Usage data has a thirty-day window and is only present on part of the catalog. Where it is absent, the uncertainty surcharge rises rather than the exposure falling — which is the intended behaviour, not a workaround.
• Deep lineage is truncated. Successors beyond four hops do not contribute to exposure, and real chains in this catalog run to seven. Some reporting-layer consumers are therefore under-counted. Known, deliberately left as it was set.

Why it is worth having

What changes on Monday

A data platform team opens their quality tool and sees forty red items. They read the first three, recognise two as known noise, and close the tab. Nothing about that improves by detecting more defects.

What changes it is a ranking that can say no with a reason. Paracelsus produces, for every downgraded finding, a sentence a person can check: this touches two of nine columns, its consumers have not been queried in thirty days, and we have no column-level lineage into it so we have tripled the surcharge anyway. That sentence is worth more than the alert it replaces, and it is why the ranking that says nothing needs attention today is a result rather than a failure.