I came to technology through law before I came to it through engineering. That order has shaped how I think about what an education platform is actually for.
A legal training teaches you to ask a specific question about any system: if this were challenged, what could be shown? Who decided, on what basis, at what time, and what record exists of it? Those questions sound bureaucratic until something goes wrong — and in education, the things that go wrong tend to concern people’s qualifications, and therefore their livelihoods.
This is why I do not treat governance as a feature that sits alongside the product. In enterprise education technology, governance is a substantial part of what the product is.
What institutions are actually buying
An institution adopting a platform for learning, administration, assessment and student management is not primarily buying screens. It is transferring responsibility.
It is asking a system to hold the authoritative record of who studied what, who assessed them, what the outcome was and whether it can be substantiated. It is asking that system to be correct not just today but in three years, when a graduate needs verification, or during an accreditation review, or when a regulator asks how a result was reached.
That is a significant thing to hand over. Institutions know it, which is why enterprise education software is evaluated more cautiously than its consumer equivalents, and why the questions that decide a deployment are so often not about features.
They are questions like: Who can change a result, and is that change recorded? How long is data retained, and on what basis? Where is it processed? What happens if a member of staff leaves? Can we produce evidence of a decision made two years ago?
A platform that cannot answer those questions is not incomplete. For an institution carrying regulatory obligations, it is unusable.
Trust is an adoption mechanism, not a marketing claim
Trust in this context is often discussed as brand perception. In practice it behaves much more like an operational property, and it shows up directly in adoption.
When staff are not confident that a system holds the authoritative record, they keep a second one. A spreadsheet. A folder. A printed register in a drawer. Each of those shadow records is a rational response to uncertainty, and each one quietly defeats the purpose of the platform: the data fragments again, the numbers stop agreeing, and the institution ends up paying for a system while still operating without one.
I have come to read the presence of shadow records as a diagnostic. They rarely indicate resistance to technology. They usually indicate that the system has not yet earned the right to be the single source of truth — because it is unreliable, because its permissions are unclear, or because when it was wrong once, nobody could establish why.
Designing for trust means designing so those shadow records become unnecessary. Correct data. Clear authority. Visible history. Predictable behaviour.
What “designed in” means concretely
Governance is easy to endorse in principle and easy to defer in practice. In product terms, I think it means at least the following.
Authority is explicit. Who may create, change, approve and reverse a record should be a first-class part of the model, not an access-control layer bolted on afterwards. Roles in an institution are real and specific; a system that flattens them will be worked around by the people whose authority it fails to represent.
Change is recorded. For records that carry consequence — results, qualifications, compliance submissions — it should be possible to establish what changed, when and by whom. Not as a debugging convenience, but as an institutional obligation.
Process is enforced where it matters and flexible where it does not. Institutions differ enormously in how they operate, and a system that dictates everything will not be adopted. But the steps that carry regulatory or academic weight should be difficult to bypass accidentally.
Data collection is disciplined. Every additional field is an additional obligation: to secure it, to justify it, to retain it appropriately and to be able to explain why it was collected. Collecting less is not a limitation; it is a reduction in risk for the institution and for the people in its records.
Retention and residency are answerable. Institutions increasingly need to state where their data lives and how long it is kept. A platform that cannot give a clear answer transfers that problem to the customer.
None of this is glamorous. All of it is load-bearing.
The cost of adding it later
The argument for deferring governance is always the same: move quickly now, formalise later. It is a reasonable-sounding trade and, in this category, an expensive one.
Permissions, audit history and retention are not surface features. They reach into the data model, the process model and the assumptions the system makes about who is acting and why. Adding them to a platform that already holds live institutional records means changing the shape of the thing while it is in production, in an environment where the records cannot simply be discarded and rebuilt.
More importantly, the deferral happens at exactly the wrong point commercially. The institutions with the most demanding governance requirements — professional bodies, accredited colleges, regulated skills-development providers — are also the ones whose adoption most validates a platform. A product that cannot meet those requirements is structurally limited to the least demanding end of its own market.
Governance as a growth constraint, and an advantage
There is a version of this argument that treats compliance as a brake on growth. I would frame it differently, because the evidence in enterprise sales points the other way.
The requirements are going to be asked either way. The only question is whether they are answered during a deployment — quickly, from a system that was built to answer them — or negotiated afterwards through workarounds, manual assurances and undertakings that someone will have to honour.
The first path shortens sales cycles and produces deployments that hold. The second produces deployments that stall.
Growth without governance is not really growth. It is deferred exposure, and in a sector where the records concern people’s qualifications, that exposure is not only commercial.
The obligation underneath
I return often to what an education record actually represents. It is not a row in a database. It is the evidence a person offers when they say what they are qualified to do. It follows them into employment, into further study, into the opportunities available to them.
Building the systems that hold those records is a technical undertaking. It is also a custodial one. Treating governance, compliance and reliable record-keeping as core product concerns rather than back-office administration is, I think, the minimum that responsibility requires.
It is also, not coincidentally, what makes institutions willing to rely on you.