HEW-NODE-0153 · How Education Works · master data, school registry, institutional identifiers, reference data, provider directory, code sets, metadata, data stewardship, mergers, closures, longitudinal continuity, interoperability, data lineage, validation, EMIS and education data governance
An education ministry can have millions of accurate records and still be unable to answer a basic question:
Are these records talking about the same school?
The payroll system may call it School 004812. The examination system may call it Centre 7814. Procurement may use a vendor-style organisation number. A district spreadsheet may still contain the school’s old name. A building register may treat two campuses as one institution. A public directory may list a school that closed three years ago. A new merged school may inherit records from both predecessors without a clean relationship among them.
This is not a small database problem. It is a system identity problem.
Master data is the small set of shared identities and reference facts that lets the rest of an education system agree about what entities exist.
This node sits beside the How Education Works hub, Education Management Information Systems, Learner Identity & Education Data Interoperability, Education Statistics Quality Assurance & Data Validation, School Census & Annual Education Data Collection, Education Data Privacy & Student Records Governance, Education Records Retention, Disposition & Archival Continuity and Education Digital Public Infrastructure & Public Digital Learning Platforms.
Those pages keep their jobs. EMIS owns the broader administrative information system. Learner Identity owns student-level identity and interoperability. Statistics Quality Assurance owns validation of statistical outputs. Records Retention owns how evidence persists and leaves. This node owns the shared entity layer: how schools, campuses, providers, programmes, districts and other education entities receive persistent identifiers, authoritative reference attributes and controlled lifecycle histories so that every system can talk about the same things consistently.
The 60-Second Read
- Every education data system depends on stable identities for schools, providers, programmes and locations.
- A school name is not a reliable identifier because names change and can be duplicated.
- A unique institutional identifier should persist through ordinary changes but not erase meaningful organisational history.
- A school registry is more than a public directory; it is an authoritative record of which institutions exist and their status.
- Master data should distinguish institution, campus, building, provider and programme.
- Mergers need relationship records between predecessor and successor entities.
- Closures should change status rather than delete history.
- Reference codes such as district, ownership type, school level and provider category need controlled definitions.
- Code values should not be repurposed after retirement.
- Every major master-data field needs an owner or steward.
- Source-of-truth rules should identify which system can create or change each attribute.
- Other systems should consume authoritative data rather than maintaining independent copies where feasible.
- Effective dates matter because institutional status changes over time.
- Geographic boundary changes should not silently rewrite historical statistics.
- APIs and bulk data feeds can distribute master data more safely than uncontrolled spreadsheets.
- Validation should detect duplicate identities, impossible hierarchies and inactive entities used in live transactions.
- Master-data changes need audit trails.
- Public directories and internal registries may expose different fields while sharing the same institutional identity.
- Interoperability begins with agreement about entities before agreement about transactions.
- The goal is not one database for everything. It is one reliable identity for each thing that matters.
One-Sentence Definition
Education master-data governance is the controlled creation, maintenance and distribution of authoritative identifiers and reference attributes for institutions, providers, programmes, organisational units and other shared entities used across education systems.
The First Distinction: Transaction Data Is Not Master Data
An enrolment record says that a learner enrolled in School A on a date. A payroll record says a teacher was paid by School A. An examination record says a candidate sat at School A.
Those are transactions or events. Master data answers the shared identity question beneath them: what exactly is School A, what is its persistent identifier, where does it sit in the organisation hierarchy, what is its status, and how is it related to predecessor or successor institutions?
The Second Distinction: A Directory Is Not Necessarily a Registry
A public school directory may be designed for families. It may show address, phone number and programme information. A master registry is an authoritative governance object. It decides which institution exists, which identifier is official, which status applies and which changes are valid from which date.
The directory can be generated from the registry. The registry should not be reverse-engineered from whatever the public website happens to display.
The Third Distinction: School Is Not Building
A school can move buildings. Two schools can share a campus. One institution can operate multiple campuses. A building can remain after a school closes and later host another institution.
If one identifier tries to represent institution, campus and physical asset at once, later changes become impossible to model cleanly.
UNESCO UIS Treats Institutional Identifiers as Foundational EMIS Infrastructure
UNESCO Institute for Statistics guidance on Education Management Information Systems treats unique institutional identifiers and a master list of institutions as a core requirement for a well-functioning EMIS. Its operational guidance describes a school ID as a non-duplicated identifier intended to remain with the school through its existence and explains that institutional master files allow data to be linked over time.
That is a deceptively powerful idea. Longitudinal analysis depends on knowing whether a school observed in 2026 is the same institutional object as a school observed in 2022.
Start With the Entity Model
Before assigning codes, define what entities the system needs to distinguish.
- legal education provider;
- school or institution;
- campus;
- physical site;
- building;
- programme;
- examination centre;
- district or administrative office;
- teacher-training institution;
- approved training provider;
- school board or governing organisation;
- service provider where relevant.
The entity model prevents one number from carrying several incompatible meanings.
Institution Identity Should Survive Ordinary Change
A school can change name, principal, address, telephone number, district or ownership details without necessarily becoming a new institution. If every change generates a new school ID, longitudinal data fragment.
The registry needs identity-continuity rules: which changes update attributes, which changes create a successor entity, and which events represent a true institutional merger or split.
Mergers Need Explicit Predecessor–Successor Relationships
Suppose School A and School B merge into School C. Reusing A’s identifier makes B’s history disappear. Reusing B’s identifier makes A’s history disappear. Treating C as entirely unrelated destroys continuity.
A better model creates C as a new institutional entity and stores predecessor relationships to A and B. Historical records remain attached to their original institutions, while analysts can aggregate across the merger when the research question requires it.
Splits Need the Reverse Relationship
If one large institution becomes two schools, neither successor is simply “the same” as the original for every analytic purpose. Store the relationship and effective date rather than forcing one successor to inherit the whole identity.
Closure Is a Status, Not Deletion
Closed schools still appear in historical examination data, payroll, property records and student transcripts. Deleting them from the registry creates broken references.
Use lifecycle states such as planned, active, temporarily inactive, closing and closed where they fit the jurisdiction. Preserve closure reason and effective dates.
Do Not Recycle Retired Identifiers
A school ID that belonged to a closed institution should not later be assigned to a different school. Historical systems, archived reports and external data may continue referencing the old number for decades.
Uniqueness needs to hold across time, not only among currently active schools.
Human-Readable Codes Can Become Traps
Some institutional IDs embed geography, ownership type or school level into digits. This can be convenient until the school moves district, changes type or the administrative hierarchy changes.
Stable opaque identifiers often age better, while geography and type remain separate reference attributes. If semantic codes are used, governance should specify what happens when the meaning changes.
Reference Data Is the Vocabulary of the System
Master entities need shared code lists:
- school ownership type;
- education level;
- programme type;
- provider status;
- urban or rural classification;
- district and region;
- school gender composition;
- boarding status;
- specialisation;
- language of instruction;
- accreditation or recognition status;
- institution lifecycle status.
If payroll, assessment and school census each maintain separate versions of these lists, cross-system joins become ambiguous even when school IDs match.
Reference Codes Need Definitions, Not Just Values
A code “03 = private” is not enough. Does private include faith-based schools? Publicly funded private providers? International schools? Community schools?
Reference-data governance should publish definitions, inclusions, exclusions, effective dates and change history.
Code Changes Should Be Versioned
Suppose a system replaces one “special school” category with several inclusion-support models. Historical records used the old code. New records use new codes.
Do not overwrite history. Store mappings where appropriate and make time-aware analysis possible.
Geography Is Especially Dangerous Master Data
Districts split, merge and change names. Catchment boundaries move. Municipalities are reorganised. If historical school records are dynamically joined to the current district table, last decade’s statistics can silently move into today’s geography.
Geographic reference data needs effective dates and boundary versions.
Location Needs More Than an Address String
Addresses change format. Rural schools may not have conventional street addresses. Geocodes can be wrong. A school can have administrative, postal and physical addresses.
Store coordinates with provenance and quality status where spatial planning depends on them. Keep the human-readable address as a separate attribute.
Source-of-Truth Rules Prevent Attribute Wars
Which system is allowed to change a school’s official name? Which owns the address? Which determines legal status? Which controls capacity?
A master-data governance matrix should assign authoritative ownership by field. Other systems can consume the attribute and report suspected errors but should not silently maintain competing truth.
One Registry Can Have Many Publishers
A ministry may centralise identifiers while local offices update addresses, accreditation bodies update recognition status and capital teams update site relationships. This can work if edit rights, validation and approval are explicit.
Central governance does not require central data entry for every field.
Data Stewardship Is a Real Job
When nobody owns master data, discrepancies become permanent. Assign stewards who can resolve duplicate entities, approve lifecycle events, manage code sets and coordinate changes across systems.
Stewardship is not simply technical administration. It involves policy interpretation because entity identity can have funding, regulatory and statistical consequences.
Institution Creation Should Be Controlled
If every district system can create a new school record without checking the national registry, duplicate institutions appear. If creation is too centralised and slow, local operations invent temporary codes.
Design a controlled creation workflow with duplicate search, minimum evidence, provisional states and eventual authoritative confirmation.
Provisional Identifiers Need a Merge Rule
During emergencies or rapid expansion, a school may need to operate before central registration completes. A provisional identifier can support transactions temporarily.
The system must later reconcile provisional and official identities without losing transactions or creating permanent duplicates.
Duplicate Detection Needs Several Signals
- same or similar name;
- same geographic coordinates;
- same address;
- same principal or governing organisation;
- same phone number;
- same historical ID;
- same examination centre;
- overlapping student records;
- impossible proximity of supposedly separate institutions.
Potential duplicates should be reviewed rather than merged automatically because two real schools can share many attributes.
UNESCO Guidance Emphasises Institution Master Files
UIS guidance on data management and EMIS functionality states that unique school identifiers and a master institutional list are fundamental even in systems that cannot yet maintain learner-level identifiers. The reason is structural: almost every education dataset must be attached to an institution somewhere.
That makes the school registry one of the quietest pieces of national education infrastructure and one of the most consequential when it is wrong.
Master Data Supports Longitudinal Analysis
To compare a school over ten years, analysts need continuity of identity. Name matching is fragile. Location matching fails when schools move. Headteacher names change.
A persistent institutional ID allows longitudinal records to remain linked while descriptive attributes change around it.
Master Data Supports Financial Control
Funding systems should not pay grants to a closed school because a stale finance table still shows it as active. Payroll should not assign staff to a non-existent institution. Procurement should not ship textbooks to a duplicate campus record.
Entity status becomes a control surface across finance and operations.
Master Data Supports Assessment Integrity
Examination centres may differ from schools. Candidates may attend one institution and test at another. The registry should model these relationships rather than force examination systems to create unofficial school variants.
Master Data Supports Public Transparency
A public school directory can provide families with reliable institution status, address and programme information when it draws from an authoritative registry.
Public fields can be a subset. Internal contact details, sensitive facility information or regulatory notes may remain restricted while the identity stays common.
Interoperability Begins Before the API
OECD’s Digital Education Outlook emphasises interoperability because fragmented systems force repeated data entry and leave useful information dormant. Technical exchange matters, but two systems can exchange perfect JSON and still disagree about whether an entity represents a campus or a school.
Semantic agreement about entities and reference values is a precondition for useful interoperability.
APIs Should Publish Authoritative Master Data
Instead of emailing spreadsheets, a registry can expose approved fields through an API or bulk feed. Consuming systems can synchronise names, status, hierarchies and reference codes regularly.
Versioning, authentication, rate limits and change notifications become part of the service contract.
Bulk Files Still Have a Place
Not every district has API capability. Signed or checksum-verified bulk files with clear version dates can distribute reference data reliably.
The important rule is that downstream copies identify which master-data version they used.
Change Notifications Reduce Silent Drift
If a school closes, downstream systems should know. Event feeds can publish lifecycle changes: created, renamed, moved, merged, split, status changed or closed.
Consumers can then update their own processes rather than discovering changes during annual reconciliation.
Data Lineage Should Reach Back to the Registry
An annual report may count schools by district. Analysts should be able to identify which registry version and geographic code set generated the denominator.
Without lineage, a revision to master data can alter statistics with no visible explanation.
Effective Dates Are Not Optional
If a school changes district on 1 January, which district owns its previous year’s expenditure? Which district counts its current students? The answer depends on the analytic question.
Store effective start and end dates so systems can reconstruct the correct historical state.
Future-Dated Changes Need States
A school may be approved to open next year. Capital planning needs it before it is active. Admissions may need it months before enrolment. Payroll may need it only later.
A planned or authorised state allows future institutions to exist in the registry without pretending they are already operating.
Registry Governance Interacts With Regulation
For non-state providers, recognition status can change. A provider may exist legally but not be authorised to offer a particular qualification. A school may be registered but temporarily suspended.
Model organisation existence separately from programme approval and operational status.
Provider and Institution Are Not Always the Same
One organisation may operate several schools. A university group may operate multiple campuses. A training company may offer many programmes across sites.
Separating provider identity from institution identity supports regulation, procurement and financial analysis.
Programme Identity Can Also Require Master Data
Qualifications, curricula and funded programmes change names and versions. A programme identifier can help connect enrolment, completion, finance and labour-market outcomes when the same programme appears across multiple providers.
Programme master data should remain distinct from the credentials actually awarded to individuals.
School-Year and Calendar-Year Views Can Conflict
An institution can change status mid-year. Statistical reporting may use a census date. Finance may use fiscal years. Assessment may use an academic cycle.
Master data should record events once and let consuming systems apply the relevant reference date.
Audit Trails Protect Institutional Memory
- field changed;
- old value;
- new value;
- effective date;
- entered by;
- approved by;
- evidence source;
- reason;
- timestamp;
- related lifecycle event.
This lets the ministry answer a future question that nobody anticipated when the change was made.
Quality Rules Can Run Continuously
- duplicate active IDs;
- duplicate names at same coordinates;
- active school with closure date;
- closed school receiving current enrolment;
- school assigned to inactive district;
- campus with no parent institution;
- programme attached to unrecognised provider;
- future opening date with current payroll;
- coordinates outside declared district;
- missing source for regulatory status.
These rules do not prove the record is correct. They identify states that deserve review.
Master Data Should Have Service-Level Expectations
If a school closure takes three months to reach finance systems, the registry is authoritative in name only. Define how quickly approved changes must propagate to downstream systems.
High-consequence lifecycle events may need faster distribution than cosmetic name corrections.
Manual Overrides Need Expiry
Operational systems sometimes need temporary exceptions. A payroll system may use a provisional institution while master data catches up.
Overrides should carry owner, reason and expiry. Permanent “temporary” codes are a common source of registry fragmentation.
Public APIs Need Privacy Boundaries
School name and public address may be appropriate for open data. Staff personal contacts, security information or sensitive facility details may not be.
One master record can support several publication views with different field-level access.
Do Not Confuse Openness With Authoritativeness
A crowd-sourced school directory may be useful and still not be authoritative for funding or statistics. An official registry may be authoritative and still contain errors.
Authority describes governance. Quality describes evidence. Strong systems need both.
Case Study: The School With Three Identities
Invented example: one secondary school is School 01877 in EMIS, Centre 993 in examinations and Organisation 4412 in finance. The school changes name. Only EMIS updates.
Later analysts cannot reconcile expenditure with examination results reliably. The repair creates a national institution master ID, preserves source-system legacy IDs as aliases and distributes the official name to consuming systems.
Case Study: The Merger That Erased History
Invented example: two rural schools merge. The ministry keeps the ID of the larger school and closes the smaller one. Five years later it appears that the larger school’s enrolment doubled overnight and its historical results include learners from the predecessor only after the merger.
The revised registry treats the merged institution as a successor with explicit predecessor links, allowing analysts to choose whether to compare legal institutions or service areas over time.
Case Study: The Closed School Receiving Textbooks
Invented example: a school closes in June. Procurement’s institution table refreshes annually in January. A September textbook order allocates materials based on prior enrolment and ships them to the closed site.
The repair publishes lifecycle events from the registry within 24 hours to logistics and finance systems.
Case Study: The District Boundary Rewrite
Invented example: a district splits in 2027. Analysts update the school registry to current district codes. Historical dashboards suddenly show the new district existing in 2024.
Time-versioned geography restores the correct historical view while still allowing analysts to restate older data into current boundaries when explicitly requested.
Failure Mode 1: Use Names as Keys
Repair: assign persistent unique identifiers and store names as changeable attributes.
Failure Mode 2: Use One ID for School, Campus and Building
Repair: separate entity classes and model relationships between them.
Failure Mode 3: Delete Closed Entities
Repair: preserve identity and history with lifecycle status and effective dates.
Failure Mode 4: Recycle Codes
Repair: make identifiers unique across time as well as among active entities.
Failure Mode 5: Let Every System Maintain Its Own Truth
Repair: assign source-of-truth ownership by attribute and distribute authoritative reference data.
Failure Mode 6: Overwrite History After Organisational Change
Repair: use effective dates, versioned code sets and predecessor-successor relationships.
Failure Mode 7: Build APIs Before Definitions
Repair: agree entity semantics, code definitions and stewardship before scaling exchange.
Failure Mode 8: Treat Master Data as an IT Side Project
Repair: recognise legal, statistical, regulatory and financial consequences of entity identity.
Failure Mode 9: Publish Everything From the Master Record
Repair: separate authoritative internal fields from public publication views.
Failure Mode 10: Never Measure Propagation Delay
Repair: monitor how quickly lifecycle changes reach finance, assessment, logistics and public directories.
The Education Master-Data Operating Chain
- Define entity classes.
- Define persistent identifier rules.
- Define lifecycle states.
- Define creation evidence.
- Define merger and split logic.
- Define predecessor-successor relationships.
- Define reference code sets.
- Publish reference definitions.
- Assign data stewards.
- Assign source-of-truth ownership by attribute.
- Design controlled creation workflows.
- Design provisional identity rules.
- Implement duplicate detection.
- Store aliases and legacy identifiers.
- Store effective dates.
- Version geography and organisational hierarchies.
- Log every material change.
- Validate impossible states continuously.
- Distribute master data through APIs or controlled bulk feeds.
- Publish lifecycle-change notifications.
- Require downstream version awareness.
- Reconcile consuming systems.
- Measure propagation delay.
- Separate public and restricted fields.
- Preserve closed entities.
- Audit identity continuity.
- Review code sets when policy changes.
- Repair duplicate and orphan records.
- Return lessons to EMIS and digital architecture governance.
A Master-Data Dashboard
- active institutions;
- planned institutions;
- closed institutions;
- entities missing persistent IDs;
- suspected duplicates;
- orphan campuses;
- invalid hierarchy relationships;
- legacy IDs mapped;
- mergers and splits pending reconciliation;
- reference code versions;
- downstream systems subscribed;
- average change propagation time;
- stale downstream copies;
- unapproved attribute changes;
- geocoding quality;
- regulatory status conflicts;
- public-directory mismatches;
- audit-trail completeness.
Canonical Owner Boundaries
- Education Management Information Systems owns the broader administrative information-system architecture.
- Learner Identity & Education Data Interoperability owns student identity and learner-level interoperability.
- Education Statistics Quality Assurance & Data Validation owns validation of statistical data and outputs.
- Education Records Retention, Disposition & Archival Continuity owns records lifecycle and archival continuity.
This node owns the authoritative entity layer: institutional identity, master registries, reference code governance, lifecycle history, data stewardship and controlled distribution of the shared identities on which cross-system education data depends.
The Return Path
Return to one school.
Its students appear in enrolment data. Its teachers appear in payroll. Its exam results appear in assessment systems. Its buildings appear in the asset register. Its grants appear in finance. Its address appears in the public directory.
Those records become one system only if they can agree about what school they are talking about.
Master data is the quiet agreement beneath that entire structure.
Before education data can be integrated, the system must agree on the identity of the things being integrated.
Return to the How Education Works hub.