There is a practical question that rarely gets asked at the right level of seriousness.
When an organisation builds or configures an information system — a CRM, a project management tool, a risk register, a performance review framework — who decides what fields to include?
The answer, in most organisations, is: someone in IT, or a project manager, or a consultant who spent six weeks on the implementation. People with technical expertise and a reasonable understanding of what similar organisations have done. People who are solving a configuration problem, not an epistemological one.
The trouble is that the configuration problem and the epistemological one are the same problem.
The fields you build into a system determine what the organisation is able to know about itself. If a customer record has no field for the quality of the relationship, the organisation cannot track relationship quality. If a project template has no field for the reasoning behind a scope decision, that reasoning evaporates when the person who made the decision leaves. If a performance framework captures output metrics but has no space for contextual factors — market conditions, resourcing constraints, timing — then context is systematically excluded from the record of how people performed.
These are not oversights in a technical sense. The system works. The fields are populated. The data flows where it is supposed to flow.
But the system is impoverished in ways that will not become visible until someone tries to use the historical record to answer a question that the architects of the system never anticipated — and discovers that the record is not there, because no one ever built a place for it.
This is the invisible authority of the person who holds the stylus. Not that they are doing anything wrong. Not that their choices are made in bad faith. But that the choices they make — about what to include, what to omit, what categories to use, how to structure the archive — will shape what the organisation can think about itself for as long as the system is in use.
These decisions require ownership at the right level. Not because the technical implementation is a leadership function, but because the questions being answered by the implementation are institutional ones.
What does this organisation need to know about its own behaviour? What should be knowable in five years? What will the next generation of people in this institution need access to in order to govern it intelligently?
These are not IT questions. They are questions about what kind of institution you intend to build.
The person who designs the template is answering them, one field at a time, whether anyone has asked them to or not.