Every housing team has one. The person who knows that this status code means something different on a void, that you have to scope the works order by service request as well as sequence number, that the rent figure everyone quotes comes from a table three joins away from where you would expect. They are invaluable. They are also a single point of failure.
When that knowledge lives in one head, every report depends on that head being available, awake, and still employed.
The expensive kind of undocumented
NEC knowledge is rarely written down because it does not feel like documentation. It feels like things everyone knows. Which columns are safe to trust, which dates actually mean what they say, where the schema records a relationship outright and where you have to be careful. None of it is in the manual, because the manual describes the product, not the decades of practice that grew up around it.
So it gets passed on by accident, in code review comments and half-remembered Teams messages, and it degrades a little with every handover.
Guides, not a data dump
A wiki tells you what a table is. A guide tells you how to work with it. The members area carries a growing set of curated NEC guides, each one written in plain language about a single area of the system: how the tables in it relate, which joins are the real ones, how the status codes decode, and the specific gotchas that catch people out.
They read like the briefing you wish someone had given you on day one, not like a schema printout.
The point of writing it down is not bureaucracy. It is that the next person, and the person after them, gets to start where the last one finished, instead of relearning the same hard-won lessons from scratch. That is the difference between a team that compounds its knowledge and one that keeps paying for it twice.
