Guide · August 6, 2026
Your warehouse scored 52/100. Here is the order to fix it in.
By the MortarIQ Founder · 6 minute read
The first readiness scan of a real warehouse almost never flatters. Our own first live assessments scored a BigQuery estate at 50 and a Snowflake account at 49, and those were warehouses being actively cared for. A low score is the normal starting point. What separates teams is not the number; it is what they do the week after, because a readiness report is a to-do list in disguise, and to-do lists get executed in an order.
The instinct is to fix what is easy. Documentation is easy: no approvals, no risk, visible progress. So teams announce a documentation sprint, describe two hundred columns, feel productive, and leave the unmasked customer emails in staging untouched for a quarter, because masking involves the security team and nobody wanted the meeting. That order is exactly backwards. Here is the one that works.
1. Exposure first, always
Every finding in the report costs you something if ignored, but only one class costs you an incident: personal data without protection. Unmasked PII in a table an AI pipeline can read is not a readiness gap; it is a countdown. Fix it before anything else, even though it is the least fun item on the list, because it is the only one where “we knew and did other things first” is a sentence you might one day say to a regulator. The PII exposure inventory gives you the list, ordered by severity, with the masking policy SQL to start from. Batch it: one policy, applied everywhere the inventory points, one security review instead of ten.
2. Then freshness, because stale poisons everything
A stale table does not look broken. It looks like data, and an AI workload will treat it as truth with a timestamp nobody checks. Every freshness failure in the report is really a broken or missing load job, so this step is pipeline repair: fix the job, or make the honest call that the table is dead and mark it so nothing builds on it. Do this before documenting anything, because there is no point writing descriptions for tables whose contents stopped being true in March.
3. Documentation, scoped to the workload
Now the sprint, but with a boundary: document what the AI project will read, not the estate. The report scores against the workload profile you picked, so the gap list is already scoped; a RAG corpus needs its forty source tables described completely and does not care that the finance schema is mute. Complete documentation of the corpus beats partial documentation of everything, because the machine reading your catalog does not average; it hits the one undocumented column it needed and guesses.
4. Then structure: keys, relationships, one table per entity
Declared keys and foreign keys are cheap to add on every platform MortarIQ scans, even where the warehouse does not enforce them, and they are the one statement of how your tables join that outlives the team that wrote them. While you are in there, settle the duplicates: if the scan found four customer tables, pick the canonical one and mark the rest deprecated. Every consumer after you, human or machine, inherits that decision instead of remaking it.
5. Consumability last, unless the bill arrives first
Partitioning, clustering, naming conventions: real money at scale, but they optimize a workload that the earlier steps make possible at all. The exception is an unpartitioned event table a retrieval job will scan repeatedly; that one moves up the list the moment you see the projected bytes billed.
Get your readiness score.
Connect read-only credentials and see your score and biggest blocker in minutes. Metadata only. Starts free.
Run the free scanThe re-scan is the receipt
After each batch of fixes, re-scan. Not for the dopamine, though watching 52 become 68 has its uses in a steering meeting, but because the re-scan is what makes the work durable. It confirms the fix actually landed in metadata, catches the migration that silently dropped your new constraints, and produces the dated evidence trail that Article 10 reviews ask for. On the Team plan the remediation board does the bookkeeping: findings stay assigned until a scan confirms them closed, and reopen on the same owner if they regress.
The honest boundary
This sequence raises a readiness score because the score measures structure and governance, and structure and governance are what these steps repair. What it does not do is validate your values; a documented, masked, fresh table can still hold wrong data, and proving otherwise is row-level work for row-level tools. Readiness gets a machine safely to the table and tells it what it is looking at. Whether the numbers in the table are right is the next fight, and it is much easier to win on a warehouse that has been through this one.
Frequently asked questions
What should I fix first after a low AI readiness score?
Unprotected personal data, always. It is the only finding class where the cost of delay is an incident rather than inconvenience. Then broken freshness on tables your workload will read, because stale inputs corrupt everything downstream. Documentation, relationships, and consumability come after, scoped to the tables the AI project actually touches.
Do I need to document the whole warehouse?
No, and trying is how documentation sprints die. Document the tables and columns your workload reads, completely, and let the rest of the estate wait for its own project. A RAG corpus built on forty documented tables beats one built on four hundred half-documented ones.
How much can a readiness score realistically improve?
The structural findings that dominate most low scores are cheap to fix individually: a masking policy, a COMMENT clause, a declared key. The movement tends to be fast, because the score was low from accumulated neglect, not from hard problems. The re-scan after each batch of fixes is what proves the movement, and prevents regressions from erasing it silently.
Does MortarIQ generate the fixes or just find the problems?
Both. Every finding comes with prioritized recommendations, and the structural ones ship remediation SQL for your platform: the masking policy to create, the comment to add, the constraint to declare. On the Team plan, findings persist on a remediation board across re-scans, so fixes stay assigned until a scan confirms them and reopen if they regress.
Want to see what the fix plan looks like before connecting? The sample report includes the full prioritized recommendations section.