The page was wrong. So was I.

The page was wrong

DataHub documents which kinds of things can have an incident raised against them. A table can. A dashboard can. The published list had drifted from the code and had been wrong for a while, quietly, the way documentation goes wrong.

So was I

My first correction was also wrong. I wrote that one file was the gate that blocks a write, and that machine learning models get rejected. Neither is true. The maintainer asked for changes and he was right to. I went back and posted the correction myself, twice, once for an input shape I had copied wrong and once for a readback claim I had simply invented.

This is the part I would keep if I had to delete the rest of the page.

Stop checking by hand

Reading six files by eye is how the list went wrong in the first place. So I stopped reading and wrote the check. It parses the write allowlist, the registry, the schema and the resolver wiring, then prints the table. It runs inside the build, so the docs cannot drift again without the build noticing.

Gave half of it away

Someone else had scoped the machine learning half before I filed anything. I found his thread after mine was open. So I handed him those entities and kept the column level one, which nobody was looking at. He shipped his in two pull requests. Mine was one. All three are on master now.

They made it the rule

The maintainer opened a tracker and made it the single place this work gets planned from. It runs on gates: every layer a thing has to clear before anyone can honestly say it supports incidents. He had named three when we started. The tracker has seven. The truth table inside it is the one my script prints, and the rule at the top of it, do not ship a write path without a read path, is the failure I filed.

GATES 5 AND 6 WERE BUILT AFTER THIS TABLE WAS WRITTEN. SEE §07 FOR WHY THEY ARE NOT ON MASTER.

Merged

Approved, taken out of draft and queued by the maintainer himself, then squashed onto master by a bot while I was asleep.

Then they handed back the rest

Gates 5 and 6, the tab you would actually click, were out of scope on purpose. After the merge the maintainer agreed a plan on the tracker: the permission check first, with tests, then the tab. That first half is now on master too, four days after the other one.

The check was asking the wrong question. Editing an incident on a column was authorized against the column, and nobody holds permissions on a column, so a dataset policy never matched and only platform admins got through. Ship the tab on top of that and it renders for everybody, the count is right, and the button is dead for everyone who is not an admin. That is worse than no tab.

It now asks about the parent instead, which is where permissions already live and what the frontend had been assuming all along. Fixing it turned up two private copies of the same check sitting in two different resolvers, byte for byte identical. Patch the shared one and the button would still have disagreed with the mutation behind it. Both go through one check now.

Then I built the tab, got it green, and asked before opening it. The answer was no, for now. An incident on a column but not on its table is a strange thing to show people, and the product team has not decided what it should look like. That is a product call, not a code one. The branch sits on my fork, unopened, and nobody spent review time on a pull request they did not want.