The platform lead says cost is under control. The engineers say the jobs are fine, it is the cluster policy. Finance says the bill doubled in April and nobody could explain it. Three people describing one account, none of whom has run a query.
The audit converts those statements into evidence before you propose anything. Five areas, one question each, a recorded decision per finding. Not a code review and not a health score — a measurement of the account as it is today, taken before you touch it, and therefore a baseline. Sweep on day three, re-run the identical queries at handover. 'Untagged spend went from 38% to 4%' is a sentence you can only write if you measured on day three.
Why
This prevents the correct recommendation that gets rejected. Liquid clustering on gold.fct_order_line, serverless for the nightly load, a tag taxonomy — all right, and all indistinguishable from the deck the last vendor left. It also prevents the opposite: a team says the loads are slow, and the sweep shows the nightly job sharing an all-purpose cluster with four notebooks, its duration tracking contention rather than data volume.
Doing it
Run it in their workspace with them watchingThe questions they ask while it runs are half the value.
Save the exact SQL per finding, so the handover sweep is a re-run and not a re-derivation
Record every result the same day, healthy ones includedAn unrecorded green area gets re-litigated in month three.
Embedding it
Ask them to predict each number before you run the queryBeing wrong about your own account is memorable in a way a slide is not.
Put a client engineer on the keyboard while you read the queries outThey keep the muscle memory; you keep the day.
When a result is disputed, open the query with them rather than defending itA number they can reproduce stops being your number.
Defaults
One day, five areas, one question each. Depth only where the sweep pointed
Baseline before any change; identical SQL at handover
Measurement and proposal are separate documents and separate sessions
Gotchas
Sweeping and recommending in one breathThe client argues about the fix and stops reading the number, and the number was the hard part to get.
Sweeping from your laptop against an exportNothing is reproducible, so the first challenged figure becomes a credibility problem instead of a re-run.
Letting the sweep grow to 100 queries because the library has 100You notice it in the findings sheet: forty rows, no Owner column filled, because forty findings compete with each other and none of them is anybody's. Week one answers five questions; the rest are for whatever week one flagged.
Every query is a SELECT against the system catalog — billing, compute, lakeflow, query, storage, access and information_schema. No agent, no collector, no scheduled notebook, no data leaving the account. The commercial consequence: the sweep needs a grant, not a security review, and a grant takes an afternoon.
Why
This prevents reporting an absence as a finding. 'No PII columns are tagged' and 'I cannot read system.information_schema.column_tags' produce the same empty result, and only one of them is true. The same trap sits under lineage: both lineage tables are a subset, emitted only where lineage could be inferred, so a missing edge means not captured — never not happening.
How
sqlQuery zero — which schemas can this identity actually see?
SELECT table_schema, COUNT(*) AS tables
FROM system.information_schema.tables
WHERE table_catalog = 'system'
GROUP BY table_schema
ORDER BY table_schema;
Three limits bound what the sweep can claim:
Latency
Usage and query-history rows arrive hours late, so a sweep run at 09:00 about yesterday reads a partial day.
Restatement
system.billing.usage corrects the past by appending RETRACTION and RESTATEMENT rows rather than editing history, so recent dollars are still moving.
Retention
The lineage system tables keep a rolling one-year window, while Catalog Explorer and the lineage API retain lineage captured after 01.09.2024 indefinitely — a question reaching further back is answerable in the UI, not in SQL.
Doing it
Ask for SELECT on the system schemas in the kickoff mailIt is the only access the sweep needs and the only thing that can delay it.
Run query zero first; record the missing schemas alongside the findings
Anchor cost findings on a complete 30-day window ending two days backRun the library's restatement trust query before any of them — a window whose restated share is large makes every dollar figure computed over it provisional, and you want to know that before the readout, not after.
Embedding it
Tell them up front where your own queries appear, and show themThey land under your identity in system.query.history and system.access.audit. Volunteering your own audit trail buys more trust than any assurance about being read-only.
Have them run query zero on their own identitiesAnalysts and engineers see different schemas, and discovering that beats being told.
Give the missing-schema list to the account owner and let an employee raise it internally, not you
Defaults
SELECT on system schemas, nothing else. A sweep query needing write access is not a sweep query
Query zero before every sweep, including the handover re-run — enablement changes
State the retention boundary rather than silently answering a shorter question than the one asked
Gotchas
A disabled system schema returning zero rows, read as a healthy answerIt is the easiest way to hand a client a confidently wrong governance finding in week one.
Quoting a saving from a period that later restatesThe correction lands after your readout, and the first number you ever gave them turns out to be wrong.
Treating a missing lineage edge as proof a table is unusedDropping it takes down a report nobody could see.
Comparing a partial day to a full oneIngestion latency puts a phantom cliff at the right edge of every chart you make today.