A record the portal cannot read is no longer a record it overwrites

Reading is deliberately forgiving. If a stored record cannot be understood — because it was written by a different version, or arrives in a shape the reader does not recognise — the portal shows a safe default rather than an error page. A settings tab that shows defaults is better than one that will not open at all.

That forgiveness is exactly wrong when the next thing that happens is a write. Five places read a record, silently got the blank default because they could not read it, changed one field on that blank, and saved it back. Everything the record used to hold was gone — and nothing was logged, because from the inside it looked like saving a change to an empty record.

Where it could happen

What changes

A record that cannot be read is refused, loudly, and left exactly as it was. The write does not happen, and the refusal names the record, what it was trying to do, and what it declined to overwrite — so it is something you can act on instead of a field that quietly goes missing weeks later.

A record that genuinely is not there yet still gets created, exactly as before. "There is nothing here" and "I could not read what is here" were the same answer; they are now two different answers, and only the first one leads to a write.

Why it will not come back

A build check now scans the whole codebase for the shape that caused it and fails if a single one reappears — with no exemption list, because the correction is mechanical and changes nothing about how the code behaves when the record is readable.

Reconnecting…
The server was updated. Reloading the page to pick up the latest version.