21 Apr 2026 · Operating model
Owner maps, not wiki gardens
Beautiful documentation dies after the reorg. A living list of humans attached to event families does not, if you actually review it.
For years we asked students to “improve the wiki.” They produced taxonomy trees, colour-coded properties, and a page titled Single Source of Truth. Three months later the page still described a squad that no longer existed. The events, unfortunately, still shipped.
App analytics data governance fails as a publishing project. It works as an assignment of humans. That is the owner map: event family, primary steward (usually analytics), change steward (usually engineering or analytics engineering), downstream steward (warehouse or reverse-ETL), and a review date. Four fields. No garden.
What the map is for
When someone wants to add user_email_raw, the map tells you who is allowed to refuse. When a dashboard breaks after a rename, the map tells you who owed the deprecation window. When PDPA counsel asks who can drop a copy, the map is the first exhibit. None of that requires a pretty tree.
How we review it
Monthly, thirty minutes, camera optional. Read the families that shipped new properties. Confirm the humans still work there. If a steward left, the family is unowned until someone accepts it — we do not silently inherit. Unowned families cannot gain new properties. That rule sounds harsh; it is the only one that stops a wiki from becoming a museum.
In the Rayong Cohort this sits in week two, before consent flags, because flags without owners become orphan columns. Alumni sometimes bring their map to office hour after a reorg. We mark names, not prose.
What a map is not
It is not a RACI chart for the whole company. It is not a data catalog replacement. It does not prove you are compliant. It is a teaching artefact that happens to survive contact with a real analytics team. If you want the template, it ships with Field Notes and with the flagship path.