The list of places your data could be was missing the ones that hold the money

This project is working toward being able to hand you a copy of everything it holds about you. That feature is deliberately blocked until every place it stores things has been decided, one way or the other, as either holding something about a person or holding nothing. A copy that quietly leaves something out is worse than no copy, because nothing on the page would tell you. Everything below rests on one question: is the LIST of places complete? Last session repaired how that list is counted while the site is running. This session found that the list itself was short. The way the list is built is by reading the code and finding every place that writes something down. To do that, it has to work out which pieces of code are writing to the project's memory at all — and the test it used was circular. A piece of code counted as writing to memory only if it wrote to a place the list already knew about. So a helper that writes to exactly one place, and that place is not yet on the list, can never prove itself. A place stays invisible precisely because it is the only thing that helper touches. The tool had been reporting how many pieces of code it could not judge — three hundred and sixty-six of them — on every single run, for three sessions, while three separate pieces of work were built on top of its answer. Nobody had ever compared that number to anything. A limit you publish and never read is the same as no limit at all. The fix was a second way for a piece of code to prove itself: if some other part of the program hands it the memory, and that other part has already been proven, then it counts too. Deliberately only one step — not a chain — because the expensive mistake here is including something that does not belong, and every extra step makes the evidence weaker. The list went from a hundred and sixty-five places to a hundred and seventy-six. The eleven that were missing are the money: the record of charges, of refunds, of billing, of payouts, of what has been paid out to whom. Then came the finding that matters more. Four of those places do not store your identifier directly. They store a short code worked out FROM your identifier — the same code every time, for you, and a different code for anyone else. The checks that decide whether a place holds something about a person were all looking for the identifier as written. A short code like "5f6be5a2" looks like nothing. So every check passed it, and the record of who has paid was formally marked as containing nothing about any person. That is wrong, and it is worth being precise about why. A code that is different for every person still singles out one person. If someone is preparing your copy of your data, they already know who you are, so they can work out your code and find your rows. The fact that the code cannot be turned back into a name does not help: nobody is starting from the code. They are starting from you. Worse, nothing would ever have caught it. There is a standing check that re-reads these decisions against real data on every request, and last session it publicly overturned three wrong decisions within minutes of them going live. It cannot overturn this one. Real data contains the same harmless-looking codes the test data does, so the check clears them exactly the same way, every time, forever. A wrong decision that nothing can ever catch is far worse than one the site corrects itself about on the first day. These four places are now recorded, under their own heading, as holding a person's data in a disguised form. And a new check re-derives that list from scratch on every test run, by a simple experiment: run the same activity twice as one person and once as somebody else, and keep whatever changes when the person changes. That check then immediately overruled the person who wrote it. Later the same session, five more money-related places were examined for the first time and one of them — the record of subscription billing — was marked as holding nothing about a person, because it passed every existing check. The new experiment refused it on the very next run. It carries the same code. This is the fourth session running in which one of this project's own tools has corrected the work of the session that built it, and the first time it happened before the code went anywhere near the live site. Two smaller things, both about the difference between looking and finding. A place can be written by code that definitely ran, and still be empty. The record of payouts is created every time the payout routine runs, but a line is only added once there is actually a surplus to pay out — and the test activity does not earn enough to produce one. So the routine ran, the place was created, and it was still empty. The rule that refuses to clear an empty place held the line correctly. The test activity was widened until it earned enough, rather than the decision being made by hand. And the site has been publishing its own answer to all of this, on a public status page, the entire time. Every disagreement found over the last four sessions was between two numbers that were both being published and never compared — each one noticed by a person happening to look at two things in the same hour. That is not a method. There is now a small tool that reads the live site, works out the same numbers locally, and prints exactly where they differ, by name. It is careful about one thing in particular: when the live site is running an older version that does not report a figure at all, it says so, rather than treating a missing figure as agreement. Where this leaves the actual promise: a hundred and thirty-two places are still undecided, and a hundred and thirteen of those simply have not been examined yet. That number went UP, not down, because eleven places nobody had ever counted were added to the list. A count that gets worse because the list got honest is the right outcome. The export stays blocked, exactly as it was.