Coverage without headcount

Detection is bought with two currencies. One is money, and it is the smaller of the two: a metadata check on a table costs a fraction of a cent to run and the invoice only becomes interesting when checks start reading rows. The other currency is human attention, and it does not scale at all. A rota of two people can hold a few dozen tables in their heads and answer a page about them at 07:00 with some idea of what to do. It cannot hold 340.

So the real constraint on coverage is not the tooling budget. It is the number of tables about which somebody can be woken and still be useful. Every tiering decision below is an argument about how to spend that number.

• Tier - a promise about a table, not a description of it. Two tables with identical schemas can sit in different tiers because different things happen when they are wrong.
• Service level - what a tier gets: which signals are watched, in which hours, and how fast detection is expected to be. Written down, dated, and reviewed.
• Detection target - the honest promise. Minutes, hours or days. A tier with no stated target is a tier nobody can hold you to and nobody can plan around.
• Downstream reader count - how many models, dashboards, exports and jobs read this table. A good first proxy for damage and a bad last word on it.
• Blast radius - everything that breaks when this table is wrong, including the paths nobody documented. Builder session 7 builds the graph that answers this properly.
• Rota capacity - the number of tier 1 tables your named humans can actually carry. The hard ceiling on the whole plan.

Two separate costs, and the second one is the one that kills the practice.

• It is unaffordable in attention, even when it is affordable in money. Every monitored table needs a threshold that somebody set, a threshold that somebody re-tunes when the table changes shape, and a human who knows what to do when it fires. Multiply that by 340 and you have described a team you do not have. The monitors that nobody maintains do not sit still: they drift into noise, because tables change and guessed thresholds do not.
• It spends the false-page budget on tables nobody reads. A team tolerates a small number of false alarms a week before it stops treating the channel as real. That tolerance is a fixed, shared resource across the whole estate. Spend it on a staging table that three people have ever queried and it is gone by the time the payments table needs it. This is the mechanism behind every muted alert channel you have inherited: not too few monitors, too many on the wrong tables.

Which gives the operating principle for the rest of the session. You are not trying to watch everything. You are trying to spend a fixed and rather small amount of human attention where being wrong actually costs something.

Tiering conversations go wrong when they are run on importance, because everybody's table is important and the loudest stakeholder wins. Run them on damage instead, and damage is answerable with four questions that anybody can answer about their own table in a minute.

• Does a decision or a payment depend on it? Money moving, prices changing, a supplier being paid, a shift being staffed. If being wrong here changes what somebody does with money, it is a candidate for the top tier regardless of how few readers it has.
• Does an external party see it? A customer, a partner, a regulator, an auditor. External visibility converts a data problem into a trust problem, and trust problems cost far more than the fix.
• How many downstream assets read it? Models, dashboards, exports, reverse-ETL jobs. This is the cheapest of the four to compute because your warehouse or catalogue can usually tell you, and it is a proxy rather than an answer: high reader count means wide blast radius, low reader count means nothing at all.
• How fast would anybody notice on their own? The honest one. A table feeding a dashboard that three people open every morning has a human monitor already. A table feeding a quarterly regulatory extract has nobody, and a defect there sits undisturbed for weeks.

Two of those four questions are about damage and two are about detection. Both halves matter: a table where the damage is large and somebody would notice in ten minutes anyway is a worse investment than a table where the damage is moderate and nobody would notice until the quarter closed.

The pattern is consistent enough to plan around and worth stating honestly rather than as a statistic. In most warehouses, a small minority of tables sits underneath almost all of the decisions, the money and the external reporting. The rest is intermediate models, staging copies, abandoned experiments and one-off extracts that somebody built for a project that ended.

The exact share varies by estate and anybody quoting you a precise percentage for your warehouse has not looked at it. What does not vary is the shape: the distribution of damage across tables is steep, not flat. That is the whole reason tiering works. If damage were evenly spread, equal coverage would be the right answer and this session would not exist.

The good news is the cost of finding out. This is a morning of work, not a project, and it does not need a catalogue purchase:

• Reader counts come from your transform project's dependency graph or from the warehouse's query history. One query, sorted descending.
• Money and external paths come from asking finance and whoever owns customer-facing reporting which tables they depend on. Two conversations, twenty minutes each, and they will name the same handful.
• The noticing question comes from the incident history you already have, even if it lives in a chat channel rather than a tracker. Which tables have ever generated a complaint, and how long did it take.

What takes a project is maintaining the list once it exists, which is why the approval rule in part 2 matters more than the first pass does.

Every estate already has a tier 3. The difference between a good practice and a bad one is whether it was chosen or whether it happened. An accidental tier 3 is the set of tables nobody got round to, and it is indefensible in an incident review because the honest answer is "we did not think about it". A deliberate tier 3 is a decision with a name and a date on it, and it survives the review.

The wording matters, because the two versions below get different reactions in the same room.

The second version buys you three things. It tells stakeholders what to expect so they stop assuming a level of protection that does not exist. It makes promotion a normal request rather than an escalation. And when a tier 3 table does cause an incident, the conversation is about whether the tier was right, which is a productive conversation, rather than about who forgot, which is not.

A tier list with no approval rule inflates. Every incident produces a request to promote the table involved, every request sounds reasonable in isolation, and within two quarters the top tier holds 80 tables and the rota is meaningless. The rule that prevents it is not strictness, it is arithmetic made visible.

• Promotion into tier 1 is capped by the rota, not by the merits. Decide the ceiling first, out loud: this rota can carry twelve tier 1 tables. After that, a promotion requires a demotion, and the person requesting it gets to argue about which table leaves. That conversation is where the real priorities surface.
• One named approver, not a committee. Whoever owns the rota approves tier changes, because they are the person who absorbs the cost. A committee approves everything.
• Requests are logged with the reason. Six months of promotion requests is the best evidence you will ever have for a headcount case, because it is a list of things the business said mattered, in its own words, with dates.
• Demotion is a normal event and needs its own habit. Nobody ever asks to be demoted, so it has to be scheduled: at each quarterly review, look for tier 1 tables that have not fired a real alert in two quarters and no longer feed anything important. Moving one down is not an admission of error.

This is the finding that reorders most tier lists, and it is why reader count is a proxy and not an answer. A table can look like the quietest thing in the warehouse - two readers, no dashboards, nobody has queried it interactively in months - and feed a job that pushes values into a CRM, a partner SFTP drop, a pricing file or a customer-facing portal. Downstream of that job is an external party, which means question two of the four is a yes, which means the table belongs a tier up.

These paths are hard to see for a structural reason. Reader counts are usually computed inside the warehouse, and a reverse-ETL job or a scheduled export is the point at which data leaves the warehouse. The graph you are looking at stops exactly where the risk starts.

Tier 3 is not zero, and the difference between zero and nearly-zero is worth understanding before you sign the promise. A nightly heartbeat asks one question of every table in the estate: did anything load. It is one aggregate query per table, it costs almost nothing, and it catches the loudest failure class - a table that has silently stopped updating - across 300 tables for less attention than a single well-tuned tier 1 monitor.

• It reports, it does not page. The output is a daily list of tables that did not load, read by whoever is on triage with a coffee. No out-of-hours anything. A list is not an alert and does not spend the false-page budget.
• It is how tables get discovered, not just checked. The first run of a heartbeat across a whole estate typically finds tables that stopped loading months ago and nobody noticed. Those are candidates for deletion, which is a better outcome than monitoring them.
• It gives you the promotion signal. If a tier 3 table shows up on the daily list and somebody in the business complains the same day, that table has told you it is not tier 3. Two occurrences is enough evidence to promote it.

What tier 3 explicitly does not catch is a table that loads on time with wrong data in it. That is the sentence to say out loud when you present the tier list, because it is the assumption stakeholders make by default.